Previously, the launch script would always use a file named
<appname>.log to capture the application's console output. This commit
adds a variable, LOG_FILENAME, for specifying the file name defaulting
to <appname>.log.
Fixes gh-4194
This commit adds a dedicated property to specify the active profiles to
use when running an application via the Maven plugin. This works also
on the command line using the `run.profiles` system property and is
consistently applied whether the process is forked or not.
Closes gh-4199
Update `launch.script` to use `start-stop-daemon` when possible to
manage daemon processes. When `start-stop-daemon` is not available `su`
is used.
Closes gh-4137
Add an `excludeDevtools` property to both the Maven and Gradle plugin
that removes `org.springframework.boot:spring-boot-devtools` (if
necessary) when repackaging the application.
Closes gh-3171
Gradle 2.0, and only 2.0, requires a Plugin implementation to be
public. The changes made in gh-4113 (9c14ed3) made the class
package-private.
Closes gh-4139
Previously, JarFileArchive would always unpack any entries marked for
unpacking to ${java.io.tmpdir}/spring-boot-libs. This could cause
problems if multiple Spring Boot applications were running on the same
host:
- If the apps are run as different users the first application would
create the spring-boot-libs directory and the second and subsequent
applications may not have write permissions to that directory
- Multiple apps may overwrite each others unpacked libs. At best this
will mean one copy of a jar is overwritten with another identical
copy. At worst the jars may have different contents so that some of
the contents of the original jar disappear unexpectedly.
This commit updates JarFileArchive to use an application-specific
location when unpacking libs. A directory beneath ${java.io.tmpdir} is
still used but it's now named <jar-file-name>-spring-boot-libs-<uuid>.
A loop, limited to 1000 attempts, is used to avoid problems caused by
the uuid clashing.
Closes gh-4124
Replace existing Groovy code with Java since the Groovy Eclipse tooling
currently forces the use of an old jdt plugin which has formatter bugs.
Fixes gh-4113
The recommended usage for the java executable is:
java [-options] -jar jarfile [args...]
This commit updates the default launch script to match this recommended
usage by moving -jar to be the last option, after both the
disableJarChecking system property and any JAVA_OPTS.
Closes gh-3930
Use "return" instead of "exit" where possible, especially in
function definitions.
Also fixed the exit codes to match the LSB spec for some specific
conditions (fixes gh-3521).
Fixes gh-3199, fixes gh-3535
Previously, manual meta-data were added to the existing set of entries
which could lead to duplicates if a manual entry is meant to complement
a property that is detected via the processor.
We now match the name and type of the item against the auto-detected
entries. If no match is found, we add the extra entry as we did before.
If a match is found we override the description, default value and
deprecation information.
Closes gh-3562
The annotation processor detects `@ConfigurationProperties` bean or
method definition and merges manual meta-data. The former step will fail
with a NPE if the annotation is not present on the classpath. This could
happen if the annotation processor is added to a module that is not
actually using Spring Boot.
We now have a defensive check that skips that steps but still attempts to
merge manual meta-data if present.
Closes gh-3720
When nested jars are being used, hasMoreElements requires opening a
connection for an entry in every nested jar. If that entry doesn't
exist, a FileNotFoundException is thrown to indicate that a particular
jar doesn't contain the requested entry. This exception is used to
indicate the lack of an entry and is then swallowed, i.e. its stack
trace is of no importance. This means that the performance of
hasMoreElements can be improved by switching on fast exceptions while
it's being called. When fast exceptions are switched on a general
purpose pre-initialized FileNotFoundException is thrown rather than
creating a new FileNotFoundException instance each time.
In certain situations, the use of fast exceptions as described above
can improve performance fairly significantly. The JRE's default SAAJ
implementation uses META-INF/services-based discovery for _every_
request that's handled by Spring Web Services. Each discovery attempt
results in hasMoreElements being called making its performance
critical to throughput.
See gh-3640
DevTools look for a main thread named "main". The maven plugin is
actually using a different value and there is no real reason to. This
change fixes DevTools support as long as forking is enabled.
See gh-3315
8673250 updated the plugin so that the application plugin is no longer
applied by default. This exposed three problems:
1. bootRepackage may run before findMainClass has run, leaving it with
an unknown main class.
2. findMainClass may run before the classes have been built, making it
unable to find the main class by examining the class files
3. The project's mainClassName property was still being used as a
convention for the bootRun task's main property. If the application
plugin has not be applied, then this property does not exist.
The first problem has been addressed by configuring bootRepackage to
depend on findMainClass.
The second problem has been addressed by configuring the main source
set's output as an input of findMainClass, and configuring findMainClass
to depend on the tasks that build the output.
The third problem has been addressed by only using the mainClassName
property if it exists and its value is not null. We then fallback to
using the mainClassName property on the project's extra properties in
the same way.
See gh-2679
Previously, the Spring Boot Gradle plugin would always apply the
application plugin to a project. It then piggy-backed on the application
plugin’s mainClassName and applicationDefaultJvmArgs properties for the
configuration of the bootRun task.
This commit updates the Spring Boot Gradle plugin so that it no longer
applies the application plugin. If the user applies the application
plugin then its configuration will be used, but it’s a no longer
requirement.
Users who do not need the application plugin, but who were using the
mainClassName or applicationDefaultJvmArgs properties will need to
change their builds as a result of this change as those properties will
no longer exist. As before, the mainClassName can be configured on the
springBoot extension:
springBoot {
mainClassName 'com.example.YourApplication'
}
The applicationDefaultJvmArgs property can be used, but it must now be
declared with the project's ext block. For example:
ext {
applicationDefaultJvmArgs = [ '-Dcom.example.property=true' ]
}
Closes gh-2679
Add a new @DeprecatedConfigurationProperties annotation which can be
used by the `ConfigurationMetadataAnnotationProcessor` to generating
meta-data deprecated blocks.
Fixes gh-3543
Previously, an item could only have a 'deprecated' boolean flag to
indicate that the property is deprecated. It is desirable to provide an
additional description for the deprecation as well as the name of the
property to use instead.
The `deprecated` boolean flag is now supported. Instead, a `deprecated`
object can be specified with two optional attributes: `reason` to provide
an explanation for the deprecation and `replacement` to refer to the
property that should be used instead. If none of them is present, an
empty deprecation object should be set.
For backward compatibility, the `deprecated` field is still set.
Deprecation information can only set via manual meta-data.
Closes gh-3449
If a field is initialized via a factory method taking a single argument,
we can relatively safely consider that said argument is a good
representation of its default value. This is typically the case for
Charset or MimeType instances.
We now make sure to detect such use case (i.e. method argument with a
single argument).
Closes gh-3482
I think this is safe, judging by the integration tests, but I'm not
putting it in 1.2.x until we've had some feedback on it. The
integration tests actually had a bug that was masking this problem
because they were merging Properties from the whole classpath instead
of picking the first available resource (which is generally what
we do in Spring Boot applications for application.properties for
instance).
Fixes gh-3048
Liquibase has a `changeLog` property that is definitely used as a
`Resource` but cannot be defined as such as the original String value
should be kept against an API we don't control.
Update the tests also to make it more clear that if hints are added
against a property that is detected automatically, said property still
keeps all its auto-discovered capabilities.
Closes gh-3457
Add a new `spring-boot-configuration-metadata` module that provides an
API to manipulate Spring Boot configuration meta-data. Can read meta-data
from arbitrary locations, though the standard
`META-INF/spring-configuration-metadata.json` location must be preferred.
Closes gh-1970
When writing a jar, once an entry has been written it will never be
overwritten, i.e. the first write of a given entry will win. Previously,
when repackaging a jar, the existing contents were written followed by
any libraries. This caused a problem when repackaged a WAR file and
a library needed to be unpacked as the existing entry in WEB-INF/lib
would prevent the library with the UNPACK comment from being written.
This was addressed in f761916b by inverting the order so libraries
would take precedence over entries in the source jar.
It’s now become apparent that this change in the order causes a problem
for users who are obfuscating their code. The obfuscated code exists in
the source jar but is also provided to the repackager in its original
form as a library. When libraries take precedence, this means that the
code in its original form ends up in the repackaged war and the
obfuscation is lost.
This commit updates the repackager to write libraries that require
unpacking first. This allows the UNPACK comment to be written even if
there’s also a source entry for the library. Next, source entries are
written. This allows obfuscated source entries to take precedence over
any unobfuscated library equivalents. Lastly, standard libraries that
do not require unpacking are written into the repackaged archive.
Closes gh-3444
Previously, if the repackaged file was different from the main artifact
of the build, the maven plugin wrongly considered that it should attach
the file with a classifier.
The outputDirectory is honored properly now, regardless of the fact a
classifier is defined or not.
Fixes gh-3177
Make sure to fail the build with a proper compilation error message if
the user-defined meta-data are invalid. For now, this takes care of the
JSON format but other checks may be added in the future.
Closes gh-3329
Improve the "hints" section of the metadata so that each hint can provide
the reference to a value provider.
A value provider defines how a tool can discover the potential values of
a property based on the context. The provider is identifed by a name and
may have an arbitrary number of parameters.
Closes gh-3303
Create a new section in the meta-data called "hints" where users can
provide hints about a given property. The most basic use case for now
is to provide a list of values that a property can have. Each value may
have a description.
This sample JSON provides a basic example for a property called `foo.mode`
that exposes 3 values: "auto", "basic" and "advanced".
```
"hints": [
{
"id": "foo.mode",
"values": [
{
"value": "auto",
"description": "Some smart description."
},
{
"name": "basic"
},
{
"name": "advanced"
}
]
}
]
```
This information can be read by tools (such as IDE) and offer an
auto-completion with the list of values.
Closes gh-2054
Update the embedded launch script to include a `chkconfig` comment. This
solves the "Service doesn't support chkconfig" error when executing
the chkconfig command.
Fixes gh-3115
Update the launch script used in fully executable jars to:
- Include LSB-Header comments
- Source `.conf` files either next to the jar for additional script
configuration
Fixes gh-3243
Update the Maven and Gradle repackage tasks so that the embedded
startup script is no longer included by default. This change is
primarily due to the `cf` command line not currently accepting
the unusual jar format.
Fixes gh-3045
Do not rely on the packaging type to figure out what the extension of the
main artifact will be. So far, using `jar` and `war` packaging for `.jar`
and `.war` files worked by chance.
We know retrieve the actual extension as provided by Maven's
`ArtifactHandler`.
Fixes gh-2762
- Verify that isReady has been called
- When forking, use a random port for JMX
- Don’t wait for application termination as it introduces a race
condition and verifying that shutdown has been requested is
sufficient
See gh-2525
SpringApplicationLifecycle provides basic lifecycle operations on the
current Spring Boot application (that is checking if the application has
fully started and gracefully terminate the app). It can be registered as
an MBean of the platform MBean server if a specific property is set.
The Maven plugin uses that MBean to check that the application is ready
before ending the "start" phase. It uses it to trigger a proper shutdown
of the application during the "stop" phase.
If the process has to be forked, the platform MBean server is exposed on
a configurable port so that the maven plugin can connect to it.
Such change permits the maven plugin to integrate a classical integration
test scenario where the "start" goal is invoked during the
pre-integration phase and the "stop" goal during the post-integration
phase.
Closes gh-2525
Some of the features of the launch.script were not exposed for users
to be able to control at runtime. It now accepts things like
PID_FOLDER and LOG_FOLDER as environment variables, and also adopts
a clear naming convention where only the inputs are UPPER_CASE.
Previously, the CLI’s dependency management used proprietary Properties
file-based metadata to configure its dependency management. Since
spring-boot-gradle-plugin’s move to using the separate dependency
management plugin the CLI was the only user of this format.
This commit updates the CLI to use Maven boms to configure its
dependency management. By default it uses the spring-boot-dependencies
bom. This configuration can be augmented and overridden using the new
@DependencyManagementBom annotation which replaces @GrabMetadata.
Closes gh-2688
Closes gh-2439
This reverts commit b1c0a7cda4.
The plugin publishing process has moved to a new plugin-based approach
that brings with it some significant limitations:
- There's no staging to allow the promotion of good release builds
- There's no easy way to upload an existing artifact
- There's no control over the published pom.
The risk brought by these limitations, particularly the first, are
too great so we will no be publishing the Boot plugin to the Portal
until they're resolved.
Changing the plugin's ID was a breaking change that would require
users to do some work when they upgrade to Boot 1.3. The ID of the
plugin was changed purely so that it met the Portal's requirements.
Given that the plugin will not be published to the Portal for the
foreseaable future there's no need for us to inflict a breaking change
on people when there will be no benefit.
See gh-1567
Update JarWriter to set the entry timestamp for nested jars. The
timestamp is set to same time as the first (non directory) entry in
the nested jar.
This change should make it easier to created layered docker images.
Fixes gh-2807
SpringApplicationLifecycle provides lifecycle operations on the current
Spring Boot application. It can be registered as an MBean of the platform
MBean server if a specific property is set. Besides, the JMX name can
also be customized via a property in case more than one Spring Boot
application is started in the same process.
The Maven plugin uses that MBean to check that the application is ready
before ending the "start" phase. It uses it to trigger a proper shutdown
of the application during the "stop" phase.
If the process has to be forked, the platform MBean server is exposed on
a configurable port so that the maven plugin can connect to it.
Such change permits the maven plugin to integrate a classical integration
test scenario where the "start" goal is invoked during the
pre-integration phase and the "stop" goal during the post-integration
phase.
Closes gh-2525
The format is rather unusual.
The time is 16 bits: 5 bits for the hour, 6 bits for the minutes, and 5
bits for the seconds. 5 bits only allows 32 values (0-31) so the number
must be doubled, meaning that the time is only accurate to the nearest
two seconds. Also, the JDK rounds this down by subtracting one. The
doubling and rounding is performed by shifting one place to the left
and masking off the right-most bit respectively.
The date is 16 bits: 7 bits for the year, 4 bits for the month, and 5
bits for the day. The year is from 1980, i.e. the earliest date that
can be represented is 1980-01-01.
See http://mindprod.com/jgloss/zip.html for more details of the format.
Fixes gh-2826
Update the Maven and Gradle plugin to generate fully executable jar
files on Unix like machines. A launcher bash script is added to the
front of the jar file which handles execution.
The default execution script will either launch the application or
handle init.d service operations (start/stop/restart) depending on if
the application is executed directly, or via a symlink to init.d.
See gh-1117
Gradle’s plugin portal requires each plugin’s ID to be in a namespace.
Our existing ID, spring-boot, does not meet this requirement. This
commit changes the plugin’s ID to org.springframework.boot.spring-boot.
Note that, as is recommended [1], the plugin’s ID does not include
“gradle”.
See gh-1567
[1] http://plugins.gradle.org/submit
Following the move to using the separate dependency management plugin
this test is no longer valid. It should have been removed as part of
2c3c62d7
See gh-2133
This commit replaces Spring Boot's basic dependency management support
with separate dependency management plugin. This has a number of
benefits including:
1. A Maven bom can be used rather than a custom properties file
2. Dependency management is applied transitively rather than only to
direct dependencies
3. Exclusions are applied as they would be in Maven
4. Gradle-generated poms are automatically configured with the
appropriate dependency management
Closes gh-2133
Previously repackaging of an archive was performed in three steps:
1. Write the manifest
2. Write entries from the source archive into the destination
3. Write any libraries into the destination if they’re not already there
This worked fine for jar files, but not for war files. In the war file
case the libraries are already in the source archive’s WEB-INF/lib
directory so they’re copied into the destination in step 2. This means
that step 3 largely becomes a no-op and, crucially, the UNPACK comment
is not applied to any libraries that require it.
This commit reorders steps 2 and 3 so that the libraries are copied into
the destination first (allowing the UNPACK comment to be written, if
required) and then any entries in the source are written into the
destination if they’re not already there.
Fixes gh-2588
Update ConfigurationMetadataAnnotationProcessor so that `prefix` is
only obtained when the annotation is not null. Also improve exception
message by including the element.
Parse a version using our version format or any version that complies
with Major.Minor.Patch. Also add a VersionRange utility that can
determine if a given version is withing that range.
Closes gh-2494
The Maven plugin allows spring-boot:run to be configured so that
resources are loaded from their output location rather than from
src/main/resources. This commit adds an equivalent configuration
option to the Gradle plugin. To disable source resources from being
added to the classpath in place of those in the output location
the configure the bootRun tasks like this:
bootRun {
addResources = false
}
Closes gh-2431
The main change in this commit is to introduce a new BuildHandler
abstraction. A BuildHandler is responsible for producing the metadata
for a build. Two implementations are provided; one for standard builds
and one for incremental builds. This change means that the annotation
processor is no longer concerned with the two different build types
and can use the same logic in each case.
The code for reading and writing metadata files has also been moved
out into a separate class, MetadataStore, to allow it to be easily
utilised from multiple places.
Closes gh-2313
This commit udpdates the metadata annotation processor so that change
data from an incremental build is merged with the metadata from the
previous build.
Closes gh-2321
This commit adds support for configuring the XA DataSource and
ConnectionFactory pools created by Atomikos and Bitronix via the
environment. The property prefixes vary depending on the transaction
manager that’s in use. They are:
Bitronix:
- spring.jta.bitronix.datasource
- spring.jta.bitronix.connectionfactory
Atomikos:
- spring.jta.atomikos.datasource
- spring.jta.atomikos.connectionfactory
The configuration processor has been updated to ignore
javax.jms.XAConnectionFactory and javax.sql.XADataSource as neither of
these types can be created via property binding.
Closes gh-2027
By default, when building a project's jar its runtime dependencies
are not taken into account as they are not needed to successfully
compile the code that will be packaged in the jar. A side-effect of
this was that, if a project that was being repackaged had a runtime
dependency on another project, then the repackaged jar would not
include the jar of the project on which it has the runtime dependency
as the jar had not been built.
This commit updates Boot's repackage task to have a dependency on the
jar task of any project dependencies in the runtime configuration
thereby ensuring that those dependencies' jars will have been built
before the repackaging occurs.
Fixes gh-2344
Running the invoker plugin with multiple threads against an empty
Maven cache results in strange build failures where Maven claims that
it cannot find a jar or pom file for an artifact that it should be
able to find. It would appear that Maven is unable to cope with
concurrent writes to its cache.
This commit removes the usage of multiple threads that was introduced
in 4e907f1.
Fixes gh-2389
This test covers the code path that caused gh-2361 and also checks that,
when an additional metadata file is found, it’s correctly merged with
the other metadata.
Closes gh-2361
When running in Eclipse, by default Gradle builds its output into a
folder named bin. This commit update the annotation processor to remove
the failure assumption that the output will always be located beneath
a folder named classes.
Closes gh-2369
See gh-2361
If user runs an executable archive then it and its lib directory will be
on the classpath. Entries from loader.path take precedence in a way that
should make sense to users (earlier wins like in CLASSPATH env var).
Also added new integration tests to verify the behaviour (big improvement
on the old ones, which probably aought to be beefed up to the same
standard).
Fixes gh-2314
Update the @SupportedSourceVersion annotation to RELEASE_8 since it
should indicate "the latest source version an annotation processor
supports".
Fixes gh-2302
Update ConfigurationMetadataAnnotationProcessor to find the additional
metadata json file using createResource rather than getResource. Prior
to this commit the file could be skipped when multiple files were
contained on the classpath.
Fixes gh-2271
Previously, disabling forking was not possible if JVM arguments or an
agent are specified, even if the fork attribute is explicitly set to
`false`.
The fork attribute is now detected as it should and forking is disabled
when the fork attribute is set to false, even if JVM arguments or an
agent is either specified or discovered.
Fixes gh-2220
Previously, no configuration properties were discovered on a class using
lombok instead of regular getters/setters.
This commit adds a support for some of the lombok annotations,
specifically that is @Data, @Getter and @Setter. Provides the same
semantic as what lombok is generating.
Closes gh-2114
Previously, non camel case properties were wrongly resolved, i.e.
getFOO() leading to a 'f-o-o'. While unusual, underscores can also be
added to a property name. In that case, the hyphen should not be added
as the binder consider this to be a single "word". Typically setFoo_Bar
on the "something" prefix is mapped using "something.foo_bar".
All these cases are now handled properly, generating the target name that
the binder expects.
Fixes gh-2118
flyway.init and flyway.target are two options that are missing from the
meta-data following the change in f0bc3c0. It turns out that both these
properties have an additional setter taking a String so they shouldn't be
excluded after all
Closes gh-2088
Previously, a property holding an array did not have a proper default
value in the meta-data even though the related field was initialized
properly.
An explicit support for arrays has been added. The "defaultValue" now
holds the default value for singular properties or an array of values for
array-based properties. If the value is initalized with an empty array,
the default value is an empty array as well.
Closes gh-1996
Previously, any valid property was added to the meta-data of the current
group. This can be annoying for types that are not meant to be bound from
a simple string value. ClassLoader is one example.
A list of well-known types has been added: if the property type matches
an element of this list, it is ignored.
Fixes gh-2012
Previously, any property defined in a @Deprecated class were not marked
as deprecated as only the getter or field was inspected for the
annotation.
An additional check on the class has been added to handle this case.
Fixes gh-2014
Update the ConfigurationMetadataAnnotationProcessor nested class
algorithm to prevent inner classes being added as both groups and
properties.
Fixes gh-1975
Previously, an Enum that is defined as an inner class of a
@ConfigurationProperties pojo was wrongly detected as an nested group.
This case is now handled explicitly and covered by a test.
Fixes gh-1971
Add a companion module that IDE developers can use to read configuration
metadata from multiple sources into a single repository.
ConfigurationMetadataRepository provides access to groups and items as
well as an harmonized view on "sources" (that is the POJOs that have
contributed to a given group).
Closes gh-1970
Add a 'module' layout for the repackager which includes all 'compile'
and 'runtime' scope dependencies and does not require a main class.
Fixes gh-1941
Previously, WarLauncher included its root on the classpath. It also used
a filtered version of its root archive to hide both the WEB-INF and
META-INF directories. This meant that files in WEB-INF and META-INF
could be found by the classloader (as they were on the classpath) but
could not be read as the filtered archive was hiding them.
This commit updates WarLauncher to remove the root of the war file from
the classpath. It also removes the filtering of the archive, thereby
allowing files in META-INF and WEB-INF to be accessed via the
ServletContext.
Closes gh-1792
Update TypeElementMembers to correctly detect builder style setters.
The previous logic could fail because of the crazy way that TypeMirror
implements its equals() method.
Fixes gh-1859
See gh-1854
Previously, a setter method that was returning the current instance was
not identified as a "setter" by the configuration processor. As a result,
builder-style APIs were not covered by the configuration metadata.
If a setter returns either void or the current class, it is now
recognized as a valid setter.
Fixes gh-1854
Update ConfigurationMetadataAnnotationProcessor to ensure that only
local `additional-spring-configuration-metadata.json` files are merged
with the final output.
See gh-1830
Update ConfigurationMetadataAnnotationProcessor so that it gets called
even if the source code doesn't include any @ConfigurationProperties
items.
See gh-1830
Add a @NestedConfigurationProperty annotation which can be used to
customize how configuration mete-data is generated.
Prior to this commit only inner-classes where considered nested
(see Tomcat in ServerProperties). Using this new annotation, the Ssl
property in ServerProperties can be detected as well.
See gh-1001
Update `ConfigurationMetadataAnnotationProcessor` to include the
'defaultValue' of a property when possible. For example the
'defaultValue' or 'server.port' is '8080'.
Default values are detected by inspecting the field assignments of
@ConfigurationProperties items. In order to detect field values some
internals of the Java compiler are used. To save a dependency on
'tools.jar' internal javac classes are accessed using reflection.
See gh-1001
Adds an annotation processor to generates a JSON meta-data file at
compile time from @ConfigurationProperties items. Each meta-data file
can include an array or 'properties' and 'groups'.
A 'property' is a single item that may appear in a Spring Boot
'application.properties' file with a given value. For example,
'server.port' and 'server.context-path' are properties. Each property
may optionally include 'type' and 'description' attributes to provide
the data type (e.g. `java.lang.Integer`, `java.lang.String`) and
some short documentation (taken from the field javadoc) about what the
property is for. For consistency, the type of a primitive is translated
to its wrapper counterpart, i.e. `boolean` becomes `java.lang.Boolean`.
A 'group' provides a higher level grouping of properties. For example
the 'server.port' and 'server.context-path' properties are in the
'server' group.
Both 'property' and 'group' items may additional have 'sourceType' and
'sourceMethod' attributes to indicate the source that contributed them.
Users may use `META-INF/additional-spring-configuration-metadata.json`
to manually provide additionally meta-data that is not covered by
@ConfigurationProperties objects. The contents of this file will be
read and merged with harvested items. The complete meta-data file is
finally written to `META-INF/spring-configuration-metadata.json`.
See gh-1001
Previously, the Gradle plugin’s ProjectLibraries produced a new library
for every file dependency, even if the dependencies where on the same
file. This would lead to a repackaging failure due to multiple
libraries having the same name.
This commit updates ProjectLibraries to treat file dependencies on the
same file as a single library, thereby resolving the name clash.
Fixes gh-1646
The fix for gh-1475 introduced the use of an artifact's group to
discriminate between two libraries with the same name (artifact id)
and version. However, in the case of Gradle, a group name was not
provided for libraries that have been resolved from a repository.
This commit updates ResolvedArtifactLibrary to use the group obtained
from the underlying ResolvedArtifact as its discriminator.
Fixes gh-1543
The applicationDefaultJvmArgs property was added in Gradle 1.7. This
commit updates RunPluginFeatures to access the property defensively
so that the plugin can be used with Gradle 1.6.
Fixes gh-1511
Prior to this commit, the repackage goal silently ignored the case of
two libraries having the same name and version but a different group.
As a result, the second library was overwriting the first one in the
repackaged jar.
This commit adds support for custom Library names and updates the
Maven and Gradle plugins so that the name includes the group ID
when there would otherwise be a duplicate.
Fixes gh-1475
This commit clarifies the role of the 'addResources' flag and makes
it explicit that any duplicate found in the target directory are
actually removed
Fixes gh-1479
This commit adds a 'skip' parameter to the 'repackage' goal that is
false by default. When this parameter is enabled, the repackage goal
does not run at all.
This can be used when repackaging should occur conditionally or
when a particular module in a hierarchy should not use this feature.
Fixes gh-1424
Previously, ProjectLibraries only considered a configuration's
direct file dependencies. This meant that a transitive file
dependency that should have been pulled in via a project dependency
was not included in the repackaged jar's lib directory.
ProjectLibraries has been updated to walk down the tree of project
dependencies and create libraries for any file dependencies that
are found.
Fixes gh-1368
* Windows: allow absolute file paths without file:/// prefix
* All: only add nested archives (not directories), so loader.path=lib/*
behaves the same as -classpath=lib/* (except for adding zip files)
Fixes gh-1352
The ExplodedArchive would erroneously always attempt to filter
its contents (and thereby shield them from a classloader that wrapped
it) even if they haven't been explicitly provided.
See gh-1352
Previously, Repackager would repackage a jar file as many times as
it was asked to do so. This lead to problems if a user made a mistake
when using Maven that led to the package phase being driven twice,
for example by running "mvn clean install package".
This commit updates Repackager so that a repackage call becomes a
no-op if the source jar's manifest already contains the
Spring-Boot-Version attribute which is added by repackaging.
Fixes#1251
Use Java 7 `registerAsParallelCapable` and `getClassLoadingLock` methods
when possible. This should improve performance when running on JDK 7+
whilst still remaining JDK 6 compatible.
Closes gh-1284
Before this change a property whose key was in a non-enumerable property source would
not resolve placeholders, leading to ${style} values in @ConfigurationProperties beans
even if the placeholders ere resolvable.
This commit refines the changes made under 4be688aa. 4be688aa made the
default jar task a special case which broke repackaging of the archive
produced by the default war task.
This commit refines RepackageTask’s logic so that, when it’s enabled,
it will repackage a jar task’s archive if:
- The jar task is equal to RepackageTask.withJarTask
- The name of the jar task is equal to RepackageTask.withJarTask
- RepackageTask.withJarTask is null, the jar task is not referenced
by another RepackageTask’s withJarTask, and the jar task has an
empty classifier
The last of these three is the default case and ensures the, when the
Spring Boot plugin is applied, default jar and war artifacts are
repackaged. The classifier check is required to prevent default source
and javadoc artifacts from being repackaged.
Fixes#1204
The logic that determined whether or not the repackaging action should
be applied to a particular jar task was broken and caused problems
when a custom RepackageTask was used in a project's build.
This commit updates the logic so that repackaging will be applied:
- To the default jar task if RepackageTask.withJarTask is null
- To a jar task if it is equal to RepackageTask.withJarTask
- To a jar task if its name is equal to RepackageTask.withJarTask
Repackaging is not applied if:
- RepackageTask.enabled is false
Numerous integration tests have been added to verify the repackaging
behaviour.
Fixes#1204
The new ResolvedArtifact-based minus implementation was checking the
wrong Set when deciding whether or not a ResolvedArtifact should
be included in the result. This was leading to provided dependencies,
that should have only been packaging in WEB-INF/lib-provided also
being packaged in WEB-INF/lib.
The WarPackaging tests have been updated. In addition to checking that
WEB-INF/lib-provided does not contain anything that’s unexpected, they
also verify the contents of WEB-INF/lib
Fixes#1187
Phillip Webb
Tommy Ludwig
Spring Buildmaster
Stephane Nicoll
Bruce Edge
Andy Wilkinson
Thomas Raehalme
Ilayaperumal Gopinathan
Dave Syer
Martin Lippert
arghya88
izeye
Matt Benson
Johannes Stelzer
Daniel Young and Mathew Johnson
Lugi Cardito
Eddú Meléndez
Sylvère Richard
Kris De Volder
Domingo Suarez Torres
Michael Cramer
David Turanski
David Liu
Eric Dahl
Phillip Webb
Dave Syer
Stephane Nicoll
Andy Wilkinson