Support for custom repackaging to change loader classes #7263

dsyer · 2016-11-01T11:36:25Z

A layout can also optionally change the loader jar that is unpacked in the
root of the repackaged archive by implementing a new method in Layout.

dsyer · 2016-11-09T10:52:49Z

Latest commit reverts "layout" in Maven and Gradle config to be an enum again. Users have to provide a LayoutFactory explicitly now.

Instead of a fixed enum of layout types, user can provide custom layouts via implementations of LayoutFactory in spring.factories.

A layout can also optionally change the loader jar that is unpacked in the root of the repackaged archive by implementing a new method in Layout.

This makes the autocompletion for pom.xml and (maybe) build.gradle easier for most users, but at the cost of a slightly odd API for deriving Layout from LayoutType.

As a courtesy to the user, if there is only one LayoutFactory defined in spring.factories, then there is no need to explicitly configure it.

It's simpler if the build tools just use a factory if one is provided otherwise derive the layout from its type.

Allow support for custom Repackager implementations with both the Maven and Gradle plugin. Subclasses of `Repackager` can now be specified to allow customization of the layout and loader classes. See spring-projectsgh-7263

Add Maven and Gradle documentation for the updated Repackager support. See spring-projectsgh-7263

Add a sample that shows how a custom Repackager can be used with both Maven and Gradle. Closes spring-projectsgh-7263

philwebb · 2016-11-18T23:35:12Z

@dsyer I'd like to change this a little so that instead of a custom Layout you can use a custom Repackager. I think it will give a little bit more flexibility.

Can you take a look at this branch and let me know if it will work for you? If so I'll merge it next week.

dsyer · 2016-11-21T09:44:52Z

I suppose that is a more liberal approach than what I proposed (something I wasn't trying to achieve). It works, but I'm not sold yet because the Layout is still quite a nice abstraction, and I'd like to provide one, so that I don't have to re-write all or most of the Repackager. But in the new implementation the layout (if provided by the user) is always injected into the custom Repackager. That means I have to override the setter for the Layout to prevent it from being overridden by the user-specified value, which feels a bit clunky. Don't you think that the launcher class archive should be part of the "layout" (if it was, as in my proposal, then I probably wouldn't have any complaint about the factory layer)?

dsyer · 2016-11-21T14:10:02Z

Another comment: it's probably good insurance to have a default RepackagerFactory that users can choose explicitly if they need it, so they can switch off a custom one that is activated by default.

philwebb · 2016-11-21T17:00:21Z

OK, let me have another go.

Pull up common timeout code into Repackager and remove the need for custom subclasses. See spring-projectsgh-7263

Allow support for custom Lyout implementations with both the Maven and Gradle plugin. Implementations of `LayoutFactory` can now be specified to allow customization of the layout. In addition a layout may now implement `CustomLoaderLayout` if it wishes to write custom loader classes. See spring-projectsgh-7263

Add a sample that shows how a custom LayoutFactory can be used with both Maven and Gradle. Closes spring-projectsgh-7263

philwebb · 2016-11-21T23:09:41Z

@dsyer What about this version. The LayoutFactory is back and it can return a Layout that also implements CustomLoaderLayout if custom loader classes need to be written.

The loadFactory only kicks in if you don't specify an explicit layout (so we don't need to provide a default LayoutFactory).

So:

If the user specifies a layout (ZIP, JAR etc) it's always used.
If the user doesn't specify layout and there isn't a LayoutFactory on the classpath the layout is based on the file extension.
If the user doesn't specify layout and there's a single LayoutFactory on the classpath (and in spring.factories) the custom factory is used.
If the user doesn't specify a layout but does specify layoutFactory then the factory is used.

dsyer · 2016-11-22T09:18:34Z

That works for me. A default layout factory still seems like a good idea, just in case anyone needs it, but I don't think it's a big deal (they are easy to write).

philwebb · 2016-11-22T18:00:08Z

OK, I'll add a DefaultLayoutFactory and get this in.

Pull up common timeout code into Repackager and remove the need for custom subclasses. See gh-7263

Allow support for custom Lyout implementations with both the Maven and Gradle plugin. Implementations of `LayoutFactory` can now be specified to allow customization of the layout. In addition a layout may now implement `CustomLoaderLayout` if it wishes to write custom loader classes. See gh-7263

* gh-7263-2: Add custom LayoutFactory sample Support custom fat jar layouts Rework Repacakger timeout code

philwebb mentioned this pull request Nov 2, 2016

Add thin jar launcher (downloads dependencies as required on startup) #7216

Closed

dsyer force-pushed the feature/custom-layout branch from 0d2ca26 to 470bf49 Compare November 3, 2016 11:42

wilkinsona mentioned this pull request Nov 6, 2016

Repackager: pluggable layouts #2629

Closed

dsyer force-pushed the feature/custom-layout branch from c7e8198 to 1490c1c Compare November 10, 2016 07:17

Dave Syer added 6 commits November 14, 2016 12:12

Ensure Spring-Boot-Lib is never "null"

a5c372a

Add LayoutFactory in spring.factories

570a040

Instead of a fixed enum of layout types, user can provide custom layouts via implementations of LayoutFactory in spring.factories.

Support for custom layout types to change loader classes

222bc2a

A layout can also optionally change the loader jar that is unpacked in the root of the repackaged archive by implementing a new method in Layout.

Refactor to make LayoutType a true enum again

3fb135d

This makes the autocompletion for pom.xml and (maybe) build.gradle easier for most users, but at the cost of a slightly odd API for deriving Layout from LayoutType.

Locate a default LayoutFactory in spring.factories if possible

aa514a4

As a courtesy to the user, if there is only one LayoutFactory defined in spring.factories, then there is no need to explicitly configure it.

Simplify contract of LayoutFactory

24ec410

It's simpler if the build tools just use a factory if one is provided otherwise derive the layout from its type.

dsyer force-pushed the feature/custom-layout branch from 1490c1c to 24ec410 Compare November 14, 2016 12:13

philwebb self-assigned this Nov 15, 2016

philwebb added this to the 1.5.0 M1 milestone Nov 15, 2016

philwebb changed the title ~~Support for custom layout types to change loader classes~~ Support for custom repackaging to change loader classes Nov 18, 2016

philwebb added the in-progress label Nov 18, 2016

philwebb pushed a commit to philwebb/spring-boot that referenced this pull request Nov 18, 2016

Document repackager updates

57ee3c1

Add Maven and Gradle documentation for the updated Repackager support. See spring-projectsgh-7263

philwebb added a commit to philwebb/spring-boot that referenced this pull request Nov 18, 2016

Add custom Repackager sample

f40ff05

Add a sample that shows how a custom Repackager can be used with both Maven and Gradle. Closes spring-projectsgh-7263

philwebb added a commit to philwebb/spring-boot that referenced this pull request Nov 21, 2016

Rework Repacakger timeout code

e23b09b

Pull up common timeout code into Repackager and remove the need for custom subclasses. See spring-projectsgh-7263

philwebb added a commit to philwebb/spring-boot that referenced this pull request Nov 21, 2016

Add custom LayoutFactory sample

c665aee

Add a sample that shows how a custom LayoutFactory can be used with both Maven and Gradle. Closes spring-projectsgh-7263

philwebb added a commit that referenced this pull request Nov 29, 2016

Rework Repacakger timeout code

f5b03c8

Pull up common timeout code into Repackager and remove the need for custom subclasses. See gh-7263

philwebb added a commit that referenced this pull request Nov 29, 2016

Merge pull request #7263 from dsyer/feature/custom-layout

d0c3ece

* gh-7263-2: Add custom LayoutFactory sample Support custom fat jar layouts Rework Repacakger timeout code

philwebb closed this in 8432c52 Nov 29, 2016

philwebb mentioned this pull request Jan 9, 2017

spring-boot-2684 loader: archive main class should fall back to Main-Class attribute if the Start-Class attribute is unavailable #2685

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Support for custom repackaging to change loader classes #7263

Support for custom repackaging to change loader classes #7263

Uh oh!

dsyer commented Nov 1, 2016

Uh oh!

dsyer commented Nov 9, 2016

Uh oh!

philwebb commented Nov 18, 2016

Uh oh!

dsyer commented Nov 21, 2016

Uh oh!

dsyer commented Nov 21, 2016

Uh oh!

philwebb commented Nov 21, 2016

Uh oh!

philwebb commented Nov 21, 2016

Uh oh!

dsyer commented Nov 22, 2016

Uh oh!

philwebb commented Nov 22, 2016

Uh oh!

Uh oh!

Support for custom repackaging to change loader classes #7263

Support for custom repackaging to change loader classes #7263

Uh oh!

Conversation

dsyer commented Nov 1, 2016

Uh oh!

dsyer commented Nov 9, 2016

Uh oh!

philwebb commented Nov 18, 2016

Uh oh!

dsyer commented Nov 21, 2016

Uh oh!

dsyer commented Nov 21, 2016

Uh oh!

philwebb commented Nov 21, 2016

Uh oh!

philwebb commented Nov 21, 2016

Uh oh!

dsyer commented Nov 22, 2016

Uh oh!

philwebb commented Nov 22, 2016

Uh oh!

Uh oh!