Previously, `gradle eclipse` would generate .classpath files with
GRADLE_CACHE references. Now it generates fully-qualified paths to
the user's home directory by default. This means we can remove the
eclipseClasspath.variables = [:]
workaround.
Redirect all stdout for the test task to LogLevel.INFO, effectively
suppressing it from the default LogLevel of LIFECYCLE.
Gradle actually does this redirection during testing anyway, but for
non-main threads that exit after the test task has completed, their
output makes its way to the console. This is why, prior to this commit
verbose 'intentional test failure' stack traces could be seen polluting
the console.
Also tuned the Xlint flags to javac on a project-by-project basis. Only
those projects that have spurious path warnings get '-path'; only those
projects with spurious deprecation warnings get '-deprecation', and so
on. This way, there's no blanket policy applied too liberally to all
projects; if path or deprecation errors crop up in a different module,
folks should see them rather than having them automatically suppressed.
For ease of use by those (a) more familiar with Maven or (b) relying
on m2eclipse support within Eclipse/STS, generated poms are now checked
in. Changes to these files will be overwritted on subsequent gradle
builds.
Any changes to project dependencies should first be reflected in
build.gradle; then run `gradle generatePom` or simply `gradle build`
to see the change reflected in the pom(s).
Note that org.springframework.integration.ip.tcp.TcpInboundGatewayTests
currently fails when running `mvn clean test` from the root. This
problem does not manifest when running `gradle clean test`. The latter
is what's most important; Gary has been contacted to take a look at the
former.
Issues resolved:
INT-1609, INT-1610, INT-1611
.gradle scripts once in gradle/ dir now live in shared buildSrc/ dir.
Some hard-coding of Spring Integration specifics still remain and will
be removed shortly.
Generate poms from Gradle metadata with
`gradle generatePom`
This will create a root pom with a <modules> section as well as a pom
for every individual module.
These poms are suitable for use with m2eclipse (e.g., File->Import->
Existing Maven project), or at the command line for basic build goals
such as `mvn test`.
These poms are not capable of producing distribution artifacts or
deployment of artifacts.
pom.xml and target will remain in .gitignore as these artifacts are
transient and for developer convenience only.
