[
https://issues.apache.org/jira/browse/TOMEE-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16276839#comment-16276839
]
Jens Berke commented on TOMEE-2152:
-----------------------------------
Hi, Romain. Yes, I actually had to switch from @Default to @Jars to make it
work at all with Gradle (latest Version 4.3.1), but @Jars has a similar problem
as @Default. It currently works with a workaround but will break with Gradle 5.
Some details:
I have a Gradle multi build project, where "model" and "webapp" are subprojects
(with each subproject having its own Gradle output directory structure):
{noformat}
rootProject
|- model
|- webapp
{noformat}
The application composer in "webapp" is configured like this and is used with a
SingleApplicationComposerRunner:
{code:java}
@Application
@Classes(cdi = true)
@Jars(value = {
"model", "webapp"
})
public class WebappTestDescriptor
{code}
I have to include the "webapp" subproject in @Jars because @Default doesn't
work with Gradle >= 4. If I didn't include "webapp" in @Jars, the unit tests
would fail for the "webapp" subproject because its test classes are not found.
Including "webapp" in @Jars on the other hand will add it's output directories
to the classpath, not its jar. Therefore, "ApplicationComposers.findFiles"
will look for the Maven-like directory structure "target/classes", which it
doesn't find because of Gradle's different default output directory layout. To
make it work I had to change the output directories in my Gradle build script
like this:
{code}
sourceSets {
main {
output.classesDir =
"${project.buildDir}/main/${project.name}/target/classes"
output.resourcesDir =
"${project.buildDir}/main/${project.name}/target/classes"
}
test {
output.classesDir =
"${project.buildDir}/test/${project.name}/target/classes"
output.resourcesDir =
"${project.buildDir}/test/${project.name}/target/classes"
}
}
{code}
This workaround will stop working in Gradle 5 because being able to change the
"output" folder is scheduled to be removed in version 5. Then neither @Default
nor @Jars will work with Gradle.
> ApplicationComposers @Default fails to detect main classes for Gradle >= 4
> --------------------------------------------------------------------------
>
> Key: TOMEE-2152
> URL: https://issues.apache.org/jira/browse/TOMEE-2152
> Project: TomEE
> Issue Type: Bug
> Affects Versions: 7.0.4
> Reporter: Jens Berke
> Attachments: ApplicationComposers.patch
>
>
> Starting with Gradle 4, the output directory layout has been changed, and as
> a result the detection of the main classes directory in
> org.apache.openejb.testing.ApplicationComposers.addWebApp fails.
> The changes are documented in the [release notes for Gradle
> 4|https://docs.gradle.org/4.0/release-notes.html], see chapters "Multiple
> class directories for a single source set" and "Location of classes in the
> build directory" there.
> As a workaround it is currently possible to change the output directory
> structure in the Gradle build script to what ApplicationComposers.addWebApp
> expects, but this possibility is scheduled to be removed in Gradle 5.0.
> The attached patch only demonstrates the minimal change necessary for Gradle
> >= 4, but it also breaks backwards compatibility with Gradle <= 3. Therefore
> it might be a good idea to add a system property or something similar which
> allows activation of the old directory structure detection for Gradle <= 3.
> It also may be a good idea to not hard-code the "java" sub-directory because
> the value might be different depending on the plugins used to run and build
> in Gradle. See the Gradle API doc for
> [SourceDirectorySet.outputdir|https://docs.gradle.org/4.0/dsl/org.gradle.api.file.SourceDirectorySet.html]
> which shows how Gradle now creates the output path dynamically.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
