Commit Graph

15 Commits

Author SHA1 Message Date
Andy Wilkinson ad3e5c04bb Add a second, portal-compatible ID to the Gradle plugin
To be compatible with Gradle's plugin portal, plugins must have an
ID that uses a reverse domain name. This means that spring-boot is
not compatible.

This commit introduces a new ID, org.springframework.boot, and
deprecates the old ID.

Closes gh-6997
2016-10-05 14:58:26 +01:00
Andy Wilkinson fc78a8de90 Merge branch '1.3.x' 2016-06-15 20:22:56 +01:00
Andy Wilkinson c808de0021 Allow custom repackage task to be used without a global main class
Closes gh-5956
2016-06-15 20:17:51 +01:00
Andy Wilkinson 3bfc6b1a4b Avoid packaging two versions of same dependency in Gradle repackaging
Previously, the Gradle plugin would include all of the dependencies
from both the compile and runtime configurations in the repackaged
jar. In the unlikely event that the compile and runtime configurations
contained different versions of the same dependency, this would lead
to both versions of the dependency being packaged in the jar file.

The runtime configuration extends the compile configuration so, in
normal circumstances, it will contain a superset of the compile
configuration's dependencies. In the situation described above where
the two configurations contain different versions of the same
dependency the runtime configuration will only contain whichever
version of the two dependencies has "won". By default, this will
be the dependency with the higher version.

This commit updates the Gradle plugin to only include the runtime
configuration's resolved dependencies during repackaging. As explained
above, the runtime configuration extends the compile configuration so
any compile dependencies will still be included, with the added
benefit that duplicate versions of the same dependency will have been
resolved to a single, preferred version.

Closes gh-5749
2016-04-21 11:37:40 +01:00
Andy Wilkinson 1043239de0 Ignore non-JavaExec run task when finding application's main class
Previously, FindMainClassTask would look for a property named main
on any class named run. This was based on the assumption that the
run task would be a JavaExec task (typically provided by the
application plugin). If the run task was not a JavaExec task (more
accurately, if it did not have a main property) this would result in
a build failure due to trying to read a non-existent property.

This commit updates FindMainClassTask to only use the main property
of the run task if the task is a JavaExec task. This guarantees that
the property will exist on the task, and unlike using any property
named main on a task named run, also guarantee that its value will
refer to a Java class with a main method.

Closes gh-5501
2016-03-29 11:03:47 +01:00
Andy Wilkinson 9dc858cdf5 Add missing properties to RepackageTask and improve test coverage
Closes gh-4978
2016-01-21 17:04:25 +00:00
Stephane Nicoll e79ef9b73b Add option to exclude devtools from fat jar
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
2015-10-14 01:22:57 -07:00
Phillip Webb d09805fd75 Polish license headers 2015-09-08 16:05:05 -07:00
Andy Wilkinson 434f528e0a Fix Gradle plugin task dependencies broken by removal of app plugin
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
2015-07-22 13:47:29 +01:00
Phillip Webb 61fc4f3f12 Polish copyright headers 2015-06-23 10:22:14 -07:00
Andy Wilkinson 4452bb1873 Revert "Upgrade Gradle plugin’s ID so it’s suitable for the Plugin Portal"
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
2015-04-21 12:37:12 +01:00
Andy Wilkinson b1c0a7cda4 Upgrade Gradle plugin’s ID so it’s suitable for the Plugin Portal
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
2015-03-19 14:25:07 +00:00
Andy Wilkinson 2c3c62d71c Replace basic Gradle dependency management with use of separate plugin
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
2015-03-19 13:23:40 +00:00
Phillip Webb 8e594c790e Fix eclipse errors and warnings
Fix some eclipse errors and warnings caused by XSD validation errors and
classes in the wrong place.
2015-02-24 12:44:19 -08:00
Phillip Webb 7ac8cac3b5 Reorganize integration tests
Make spring-boot-integration-tests a top level project and move the
existing gradle tests and security tests to be sub-modules.
2015-02-23 17:24:05 -08:00