[
https://issues.apache.org/jira/browse/GEODE-6753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160130#comment-17160130
]
Kirk Lund edited comment on GEODE-6753 at 7/17/20, 6:40 PM:
------------------------------------------------------------
Even if we exclude the test-sources jars such as
log4j-core-2.11.1-test-sources.jar, the problems described in this ticket still
occur for the test jars such as log4j-core-2.11.1-test.jar.
We require use of log4j-core-n.n.n-test.jar for the Log4j JUnit Rule. Without
that Rule, our geode-log4j tests require writing LOTS of code to manipulate
log4j. We could theoretically copy the Log4j JUnit Rule and classes it depends
on from log4j-core-n.n.n-test into geode-log4j but then we have to refresh that
in our code base every time we upgrade log4j dependencies or risk having the
Rule fall behind.
The issue with Jetty is similar.
Removing our use of log4j-core or jetty test jars should only be done if we
want to remove the use of log4j-core and jetty from Geode which is obviously
more problematic than removing Geode's use of mavenLocal(). I don't see what
value mavenLocal() provides. It's simply a huge headache to any developers who
work on both maven and gradle projects.
was (Author: klund):
Even if we exclude the test-sources jars such as
log4j-core-2.11.1-test-sources.jar, the problems described in this ticket still
occur for the test jars such as log4j-core-2.11.1-test.jar.
We require use of log4j-core-n.n.n-test.jar for the Log4j JUnit Rule. Without
that Rule, our geode-log4j tests require writing LOTS of code to manipulate
log4j. We could theoretically copy the Log4j JUnit Rule and classes it depends
on from log4j-core-n.n.n-test into geode-log4j but then we have to refresh that
in our code base every time we upgrade log4j dependencies or risk having the
Rule fall behind.
The issue with Jetty is similar.
Removing our use of log4j or jetty test jars should only be done if we want to
remove the use of log4j and jetty from Geode which is obviously more
problematic than removing Geode's use of mavenLocal(). I don't see what value
mavenLocal() provides. It's simply a huge headache to any developers who work
on both maven and gradle projects.
> Use of mavenLocal in gradle may cause build to fail with missing tests
> dependencies
> -----------------------------------------------------------------------------------
>
> Key: GEODE-6753
> URL: https://issues.apache.org/jira/browse/GEODE-6753
> Project: Geode
> Issue Type: Bug
> Components: build
> Reporter: Kirk Lund
> Assignee: Patrick Rhomberg
> Priority: Major
>
> This reproduces easily for me with:
> {noformat}
> $ ./gradlew build -x test -x javadoc -x pmdMain
> {noformat}
> I'm not sure why this doesn't reproduce consistently for everyone, but it
> seems to be caused by working on multiple software projects that use both
> gradle and maven. If I delete my .m2 directory or remove the mavenLocal line
> from geode/build.gradle then the build completes without failure.
> If I then use maven to build any project that depends on jetty-http or
> log4j-core, then my .m2 directory is recreated and the problem reproduces
> until I remove mavenLocal or delete my .m2 directory.
> In my case, it seems to be specific to tests dependencies: jetty-http:tests
> and log4j-core:tests.
> Based on feedback from gradle developers regarding this type of problem, I
> believe we should remove mavenLocal use from Geode's gradle build:
> https://discuss.gradle.org/t/gradle-fails-to-download-dependencies-if-not-present-in-mavenlocal/2532/16
> {noformat}
> 1: Task failed with an exception.
> -----------
> * What went wrong:
> Execution failed for task
> ':extensions:geode-modules-session:compileIntegrationTestJava'.
> > Could not resolve all files for configuration
> > ':extensions:geode-modules-session:integrationTestCompileClasspath'.
> > Could not find jetty-http-tests.jar
> (org.eclipse.jetty:jetty-http:9.4.12.v20180830).
> Searched in the following locations:
>
> file:/Users/klund/.m2/repository/org/eclipse/jetty/jetty-http/9.4.12.v20180830/jetty-http-9.4.12.v20180830-tests.jar
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> ==============================================================================
> 2: Task failed with an exception.
> -----------
> * What went wrong:
> Execution failed for task ':geode-assembly:compileDistributedTestJava'.
> > Could not resolve all files for configuration
> > ':geode-assembly:distributedTestCompileClasspath'.
> > Could not find log4j-core-tests.jar
> (org.apache.logging.log4j:log4j-core:2.11.1).
> Searched in the following locations:
>
> file:/Users/klund/.m2/repository/org/apache/logging/log4j/log4j-core/2.11.1/log4j-core-2.11.1-tests.jar
> > Could not find log4j-core-test-sources.jar
> (org.apache.logging.log4j:log4j-core:2.11.1).
> Searched in the following locations:
>
> file:/Users/klund/.m2/repository/org/apache/logging/log4j/log4j-core/2.11.1/log4j-core-2.11.1-test-sources.jar
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> ==============================================================================
> 3: Task failed with an exception.
> -----------
> * What went wrong:
> Execution failed for task ':geode-core:compileIntegrationTestJava'.
> > Could not resolve all files for configuration
> > ':geode-core:integrationTestCompileClasspath'.
> > Could not find log4j-core-tests.jar
> (org.apache.logging.log4j:log4j-core:2.11.1).
> Searched in the following locations:
>
> file:/Users/klund/.m2/repository/org/apache/logging/log4j/log4j-core/2.11.1/log4j-core-2.11.1-tests.jar
> > Could not find log4j-core-test-sources.jar
> (org.apache.logging.log4j:log4j-core:2.11.1).
> Searched in the following locations:
>
> file:/Users/klund/.m2/repository/org/apache/logging/log4j/log4j-core/2.11.1/log4j-core-2.11.1-test-sources.jar
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output. Run with --scan to get full insights.
> ==============================================================================
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
