[jira] [Commented] (MRESOLVER-324) Make the BF algorithm as the default option to speed up maven dependency resolution and downloading
[
https://issues.apache.org/jira/browse/MRESOLVER-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17690641#comment-17690641
]
Steven Schlansker commented on MRESOLVER-324:
-
Wow. We tried out the BF changes in our full rebuild pipeline, and the download
set was 2.9GB before with DF and only 900MB with BF! I almost don't believe how
much better it is...
If no regressions are found, BF should be the new default!
> Make the BF algorithm as the default option to speed up maven dependency
> resolution and downloading
> ---
>
> Key: MRESOLVER-324
> URL: https://issues.apache.org/jira/browse/MRESOLVER-324
> Project: Maven Resolver
> Issue Type: Wish
> Components: Resolver
>Affects Versions: 1.10.0
>Reporter: wei cai
>Priority: Major
>
> This is a WISH type Jira :D. So far, Maven 3.9.0 has released a BF algorithm
> which includes changes from below JIRAs along with the DF option (default).
> * MRESOLVER-228
> * MRESOLVER-247
> * MRESOLVER-7
> The BF algorithm solves:
> * Cache missing issue when comes to resolve heavy dependencies with
> different exclusions, it can help speed up dependency resolution especially
> for large scale enterprise level projects.
> * Improve download speed by:
> ** Skip downloading poms for conflict losers.
> ** Download poms in parallel.
> Below is the introduction in
> [https://maven.apache.org/docs/3.9.0/release-notes.html:]
> {noformat}
> Choice of resolver collectors: a new BF collector (with parallel POM
> downloads) has been added along the existing DF one.{noformat}
> The solution is already widely adopted at eBay. You can simply enable it by
> putting below config item into file: ${maven.projectBasedir}/.mvn/maven.config
> {code:java}
> aether.dependencyCollector.impl=bf {code}
> More introduction about this option:
> [https://maven.apache.org/resolver/configuration.html]
> Please try and tells us how much it helps by running:
> {code:java}
> 1. mvn clean install -DskipTests -Dmaven.repo.local=bf
> -Daether.dependencyCollector.impl=bf
> 2. mvn clean install -DskipTests -Dmaven.repo.local=df{code}
> With more feedback collected, we would be able to propose the changes to
> Maven team to make BF as the default.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MDEP-791) Non-test scoped and transitive dependencies in compile scope
[
https://issues.apache.org/jira/browse/MDEP-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17519156#comment-17519156
]
Steven Schlansker commented on MDEP-791:
Thank you for the workaround :)
> Non-test scoped and transitive dependencies in compile scope
>
>
> Key: MDEP-791
> URL: https://issues.apache.org/jira/browse/MDEP-791
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Slawomir Jaranowski
>Priority: Critical
> Attachments: MDEP-791.zip
>
>
> When we use some dependency in test classes which is not used in production
> code but is required as transitive dependency for other used in production
> code - such dependency should not be included in {*}{{Non-test scoped}}{*}.
> Example:
> * test code use {{ObjectCodec}} from {{jackson-core}}
> * production code use only {{ObjectMapper}} from {{jackson-databind}}
> * production code don't use any classes from {{jackson-core}}
> {{jackson-core}} is needed by {{jackson-databind}} and must by in compile
> scope so should not be reported as {{Non-test scoped}}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MDEP-791) Non-test scoped and transitive dependencies in compile scope
[
https://issues.apache.org/jira/browse/MDEP-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17519088#comment-17519088
]
Steven Schlansker commented on MDEP-791:
I appreciate that this is ultimately a bug in Maven Core, however a fix there
is likely to take a long time (Maven 4?) and in the meantime users cannot
target any new JDK 17+.
Should we consider releasing artifacts that support JDK 17+ source level, but
use the old (incorrect) checker rules? At this point we are waiting for a very
long time with no progress. I agree it's a stop-gap but the whole community
that wants to target latest JDK is stuck on this set of issues at this point.
Fixing the Maven bug with dependency resolution is a great outcome, but it
should be implemented bottom-up (first fix core, then improve checker rules)
rather than the other way around (improve checker rules, break, wait
indefinitely on core...)
> Non-test scoped and transitive dependencies in compile scope
>
>
> Key: MDEP-791
> URL: https://issues.apache.org/jira/browse/MDEP-791
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0, 3.3.0
>Reporter: Slawomir Jaranowski
>Priority: Critical
> Attachments: MDEP-791.zip
>
>
> When we use some dependency in test classes which is not used in production
> code but is required as transitive dependency for other used in production
> code - such dependency should not be included in {*}{{Non-test scoped}}{*}.
> Example:
> * test code use {{ObjectCodec}} from {{jackson-core}}
> * production code use only {{ObjectMapper}} from {{jackson-databind}}
> * production code don't use any classes from {{jackson-core}}
> {{jackson-core}} is needed by {{jackson-databind}} and must by in compile
> scope so should not be reported as {{Non-test scoped}}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MDEP-774) analyze-only failed: PermittedSubclasses requires ASM9
[
https://issues.apache.org/jira/browse/MDEP-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17448798#comment-17448798
]
Steven Schlansker edited comment on MDEP-774 at 11/24/21, 8:13 PM:
---
I see the same problem, only it is:
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:3.2.0:analyze-only
(basepom.default) on project assisted-inject: Execution basepom.default of goal
org.apache.maven.plugins:maven-dependency-plugin:3.2.0:analyze-only failed:
Record requires ASM8 {code}
Probably the same fix in both cases... (I already managed asm dependency to
latest 9.2)
was (Author: stevenschlansker):
I see the same problem, only it is:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.2.0:analyze-only
> (basepom.default) on project assisted-inject: Execution basepom.default of
> goal org.apache.maven.plugins:maven-dependency-plugin:3.2.0:analyze-only
> failed: Record requires ASM8
Probably the same fix in both cases... (I already managed asm dependency to
latest 9.2)
> analyze-only failed: PermittedSubclasses requires ASM9
> --
>
> Key: MDEP-774
> URL: https://issues.apache.org/jira/browse/MDEP-774
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.2.0
> Environment: Maven 3.8.2, Adoptium 17, MacOS 11.6
>Reporter: Dan Ziemba
>Assignee: Sylwester Lachiewicz
>Priority: Critical
> Fix For: next-release
>
>
> The analyze-only goal does not work with Java 17 bytecode:
> {noformat}
> Execution dep-analyze of goal
> org.apache.maven.plugins:maven-dependency-plugin:3.2.0:analyze-only failed:
> PermittedSubclasses requires ASM9{noformat}
> Running the same build under the same version of Java 17, but with
> "maven.compiler.release" set to 16 works fine.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MDEP-774) analyze-only failed: PermittedSubclasses requires ASM9
[
https://issues.apache.org/jira/browse/MDEP-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17448798#comment-17448798
]
Steven Schlansker commented on MDEP-774:
I see the same problem, only it is:
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-dependency-plugin:3.2.0:analyze-only
> (basepom.default) on project assisted-inject: Execution basepom.default of
> goal org.apache.maven.plugins:maven-dependency-plugin:3.2.0:analyze-only
> failed: Record requires ASM8
Probably the same fix in both cases... (I already managed asm dependency to
latest 9.2)
> analyze-only failed: PermittedSubclasses requires ASM9
> --
>
> Key: MDEP-774
> URL: https://issues.apache.org/jira/browse/MDEP-774
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 3.2.0
> Environment: Maven 3.8.2, Adoptium 17, MacOS 11.6
>Reporter: Dan Ziemba
>Assignee: Sylwester Lachiewicz
>Priority: Critical
> Fix For: next-release
>
>
> The analyze-only goal does not work with Java 17 bytecode:
> {noformat}
> Execution dep-analyze of goal
> org.apache.maven.plugins:maven-dependency-plugin:3.2.0:analyze-only failed:
> PermittedSubclasses requires ASM9{noformat}
> Running the same build under the same version of Java 17, but with
> "maven.compiler.release" set to 16 works fine.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MDEP-754) Analyze incorrectly warns that junit is test only when it is a compile time dependency
[ https://issues.apache.org/jira/browse/MDEP-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17364605#comment-17364605 ] Steven Schlansker commented on MDEP-754: Possible duplicate of MDEP-753 > Analyze incorrectly warns that junit is test only when it is a compile time > dependency > -- > > Key: MDEP-754 > URL: https://issues.apache.org/jira/browse/MDEP-754 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 3.2.0 > Environment: Apache Maven 3.5.4 > (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T14:33:14-04:00) > Maven home: /usr/local/Cellar/maven/3.5.4/libexec > Java version: 1.8.0_144, vendor: Oracle Corporation, runtime: > /Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" >Reporter: John Camerin >Priority: Major > > A java module with some test utilities which decorate junit and therefore has > a compile time dependency on junit. Using dependency plugin 3.2.0 and > running dependency:analyze results in a warning > [*WARNING*] Non-test scoped test only dependencies found: > [*WARNING*] junit:junit:jar:4.13.2:compile > When I change the scope to test, compile fails (confirming it is a compile > dependency). > Previously using 3.1.2 of the dependency plugin works correctly (does not > warn) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEP-753) Non-test dependency reported as Non-test scoped test only dependency
[
https://issues.apache.org/jira/browse/MDEP-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17364602#comment-17364602
]
Steven Schlansker commented on MDEP-753:
I attempted to upgrade our project to use Java 16 source level and when we
upgraded the dependency-analyzer, we also ran into this problem. For us it is
{{commons-lang3}} which is obviously used in main sources, but triggers a
failure due to this check.
I would recommend raising the priority of this bug, potentially even to
Blocker, this is a serious regression.
> Non-test dependency reported as Non-test scoped test only dependency
>
>
> Key: MDEP-753
> URL: https://issues.apache.org/jira/browse/MDEP-753
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Reporter: Elliotte Rusty Harold
>Priority: Minor
>
> Saw this when updating the google-http-java-client from 3.1.2 to 3.2.0 of the
> plugin. I'm not immediately sure whether this is a regression:
> [INFO] --- maven-dependency-plugin:3.2.0:analyze (default-cli) @
> google-http-client ---
> Warning: Non-test scoped test only dependencies found:
> Warning: com.google.guava:guava:jar:30.1.1-android:compile
> Warning: io.opencensus:opencensus-api:jar:0.28.0:compile
> Changing Guava to scope test breaks the build, which is expected based on the
> code. The warning seems incorrect.
> https://github.com/googleapis/google-http-java-client/pull/1396
> https://github.com/googleapis/google-http-java-client/pull/1396/checks?check_run_id=2809438131
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1652) surefire/failsafe fails with --enable-preview in java 12
[ https://issues.apache.org/jira/browse/SUREFIRE-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804132#comment-16804132 ] Steven Schlansker commented on SUREFIRE-1652: - We are able to reproduce this problem in our environment – setting the forkCount to 0 gets us moving temporarily but sacrifices both speed and test isolation so is not a real solution. > surefire/failsafe fails with --enable-preview in java 12 > > > Key: SUREFIRE-1652 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1652 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Affects Versions: 3.0.0-M3 >Reporter: Krzysztof Krason >Priority: Blocker > > Minimal example: [https://github.com/krzyk/lombok-jdk10-example] > > When I run the build `mvn clean verify` in the above repository I get > following error: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M3:test (default-test) > on project lombok-jdk10: Execution default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M3:test failed: > java.lang.UnsupportedClassVersionError: Preview features are not enabled for > com/kirela/lombok/BarTest (class file version 56.65535). Try running with > '--enable-preview' -> [Help 1] > > Tests work when I remove `--enable-preview` from compiler OR when I remove > "forkCount" from surefire (and failsafe) configuration. > As I understand argLine property should be used in all forks, but appears to > be ignored, there is no difference if I use it as a property or as a > configuration paramater in surefire/failsafe. > > This bug makes using Java 12 with preview features unusable with > surefire/failsafe. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MPMD-280) maven-pmd-plugin does not support targetJdk 12
Steven Schlansker created MPMD-280:
--
Summary: maven-pmd-plugin does not support targetJdk 12
Key: MPMD-280
URL: https://issues.apache.org/jira/browse/MPMD-280
Project: Maven PMD Plugin
Issue Type: New Feature
Components: PMD
Affects Versions: 3.11.0
Environment: openjdk version "12" 2019-03-19
OpenJDK Runtime Environment 19.3 (build 12+33)
OpenJDK 64-Bit Server VM 19.3 (build 12+33, mixed mode, sharing)
Fedora release 29 (Twenty Nine)
Reporter: Steven Schlansker
Attempting to use maven-pmd-plugin with the newly GA openjdk12 and
source/target level 12 results in:
{code:java}
Caused by: org.apache.maven.reporting.MavenReportException: Unsupported
targetJdk value '12'.
at org.apache.maven.plugins.pmd.PmdReport.getPMDConfiguration
(PmdReport.java:672)
at org.apache.maven.plugins.pmd.PmdReport.executePmd (PmdReport.java:390)
at org.apache.maven.plugins.pmd.PmdReport.executePmdWithClassloader
(PmdReport.java:355)
at org.apache.maven.plugins.pmd.PmdReport.canGenerateReport (PmdReport.java:329)
at org.apache.maven.reporting.AbstractMavenReport.execute
(AbstractMavenReport.java:120{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-5731) DefaultArtifactCollector loses a transitive dependency with specific combination of versions and RUNTIME scope
[
https://issues.apache.org/jira/browse/MNG-5731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16406980#comment-16406980
]
Steven Schlansker commented on MNG-5731:
Too bad no progress was made on this issue :(
> DefaultArtifactCollector loses a transitive dependency with specific
> combination of versions and RUNTIME scope
> --
>
> Key: MNG-5731
> URL: https://issues.apache.org/jira/browse/MNG-5731
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.2.3
> Environment: Mac OS 10.9, Java 8u25
>Reporter: Steven Schlansker
>Priority: Major
> Attachments: maven-loses-transitive-dependency.tgz
>
>
> Unpack the attached test case. It is a rather large multimodule project
> which looks like the following:
> {code}
> test:i:jar:1 (0; enabled)
> test:c:jar:3:compile (1; enabled)
> test:b:jar:2:compile (2; enabled)
> test:e:jar:2:compile (1; enabled)
> test:c:jar:2:compile (2; disabled)
> test:b:jar:1:compile (3; disabled)
> test:a:jar:1:compile (4; disabled)
> test:h:jar:1:runtime (2; enabled)
> test:g:jar:1:runtime (3; enabled)
> test:a:jar:2:compile (4; disabled)
> test:f:jar:1:compile (1; enabled)
> test:e:jar:1:compile (2; disabled)
> test:c:jar:1:compile (3; disabled)
> test:d:jar:1:compile (2; enabled)
> test:c:jar:2:compile (3; disabled)
> test:b:jar:1:compile (4; disabled)
> test:a:jar:2:compile (5; disabled)
> {code}
> There is a dependency chain I1 -> E2 -> H1 -> G1(runtime) -> A2
> During version resolution, the G1->A2 dependency is dropped due to
> checkScopeUpdate in favor of upgrading the version of B1 -> A1 into B1 -> A2,
> since it has compile scope.
> The B1 -> A2 dependency is later suppressed because C3 has a "nearer"
> dependency on B2, tossing B1. So A2 is lost even though there is a
> legitimate need for it from G1.
> To reproduce:
> {code}
> [steven@Anesthetize:~/ot-code/maven-loses-transitive-dependency]% mvn clean
> package && java -cp i1/target/i-1-jar-with-dependencies.jar MainI
> Exception in thread "main" java.lang.NoClassDefFoundError: A
> at G.(G.java:2)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
> at java.lang.Class.newInstance(Class.java:433)
> at H.(H.java:6)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:259)
> at E.(E.java:5)
> at MainI.main(MainI.java:3)
> Caused by: java.lang.ClassNotFoundException: A
> at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 11 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MDEP-471) Java 8 Method references are not detected
[
https://issues.apache.org/jira/browse/MDEP-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987635#comment-15987635
]
Steven Schlansker commented on MDEP-471:
I can provide a sample project if need be, but I agree with Jonathan that it
should just be releasing the components and plugins.
> Java 8 Method references are not detected
> -
>
> Key: MDEP-471
> URL: https://issues.apache.org/jira/browse/MDEP-471
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 2.9
> Environment: Mac OSX
> 13.3.0 Darwin Kernel Version 13.3.0: Tue Jun 3 21:27:35 PDT 2014;
> root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64
>Reporter: Ben Hardy
>
> It is possible to get the depedency plugin to fail to recognize methods
> references.
> For example, the following function declaration is the only place in its
> class where the Guava "Lists" class is referenced (apart from imports):
> public static SequenceMap forStringKeys() {
> return new SequenceMap<>(Lists::charactersOf);
> }
> We choose to fail when declared dependencies are thought to be unused, and
> this usage is simply not detected, resulting in the following output and
> exception:
> [WARNING] Unused declared dependencies found:
> [WARNING]com.google.guava:guava:jar:18.0:compile
> [INFO]
>
> Caused by: org.apache.maven.plugin.MojoExecutionException: Dependency
> problems found
> at
> org.apache.maven.plugin.dependency.analyze.AbstractAnalyzeMojo.execute(AbstractAnalyzeMojo.java:187)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> Will try to get a test and patch attached to this once I figure out where
> your test case class file resources are coming from.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MDEP-471) Java 8 Method references are not detected
[
https://issues.apache.org/jira/browse/MDEP-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986875#comment-15986875
]
Steven Schlansker commented on MDEP-471:
I just confirmed the problem is still reproducible with 3.0.0
> Java 8 Method references are not detected
> -
>
> Key: MDEP-471
> URL: https://issues.apache.org/jira/browse/MDEP-471
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 2.9
> Environment: Mac OSX
> 13.3.0 Darwin Kernel Version 13.3.0: Tue Jun 3 21:27:35 PDT 2014;
> root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64
>Reporter: Ben Hardy
>
> It is possible to get the depedency plugin to fail to recognize methods
> references.
> For example, the following function declaration is the only place in its
> class where the Guava "Lists" class is referenced (apart from imports):
> public static SequenceMap forStringKeys() {
> return new SequenceMap<>(Lists::charactersOf);
> }
> We choose to fail when declared dependencies are thought to be unused, and
> this usage is simply not detected, resulting in the following output and
> exception:
> [WARNING] Unused declared dependencies found:
> [WARNING]com.google.guava:guava:jar:18.0:compile
> [INFO]
>
> Caused by: org.apache.maven.plugin.MojoExecutionException: Dependency
> problems found
> at
> org.apache.maven.plugin.dependency.analyze.AbstractAnalyzeMojo.execute(AbstractAnalyzeMojo.java:187)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> Will try to get a test and patch attached to this once I figure out where
> your test case class file resources are coming from.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (MDEP-471) Java 8 Method references are not detected
[
https://issues.apache.org/jira/browse/MDEP-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15985705#comment-15985705
]
Steven Schlansker edited comment on MDEP-471 at 4/26/17 11:03 PM:
--
Any movement here? We're still impacted by this issue, a year later... Looks
like a fix at this point might be as simple as updating mdep's dependencies and
making a new release?
was (Author: stevenschlansker):
Any movement here? We're still impacted by this issue, a year later...
> Java 8 Method references are not detected
> -
>
> Key: MDEP-471
> URL: https://issues.apache.org/jira/browse/MDEP-471
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 2.9
> Environment: Mac OSX
> 13.3.0 Darwin Kernel Version 13.3.0: Tue Jun 3 21:27:35 PDT 2014;
> root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64
>Reporter: Ben Hardy
>
> It is possible to get the depedency plugin to fail to recognize methods
> references.
> For example, the following function declaration is the only place in its
> class where the Guava "Lists" class is referenced (apart from imports):
> public static SequenceMap forStringKeys() {
> return new SequenceMap<>(Lists::charactersOf);
> }
> We choose to fail when declared dependencies are thought to be unused, and
> this usage is simply not detected, resulting in the following output and
> exception:
> [WARNING] Unused declared dependencies found:
> [WARNING]com.google.guava:guava:jar:18.0:compile
> [INFO]
>
> Caused by: org.apache.maven.plugin.MojoExecutionException: Dependency
> problems found
> at
> org.apache.maven.plugin.dependency.analyze.AbstractAnalyzeMojo.execute(AbstractAnalyzeMojo.java:187)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> Will try to get a test and patch attached to this once I figure out where
> your test case class file resources are coming from.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MDEP-471) Java 8 Method references are not detected
[
https://issues.apache.org/jira/browse/MDEP-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15985705#comment-15985705
]
Steven Schlansker commented on MDEP-471:
Any movement here? We're still impacted by this issue, a year later...
> Java 8 Method references are not detected
> -
>
> Key: MDEP-471
> URL: https://issues.apache.org/jira/browse/MDEP-471
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 2.9
> Environment: Mac OSX
> 13.3.0 Darwin Kernel Version 13.3.0: Tue Jun 3 21:27:35 PDT 2014;
> root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64
>Reporter: Ben Hardy
>
> It is possible to get the depedency plugin to fail to recognize methods
> references.
> For example, the following function declaration is the only place in its
> class where the Guava "Lists" class is referenced (apart from imports):
> public static SequenceMap forStringKeys() {
> return new SequenceMap<>(Lists::charactersOf);
> }
> We choose to fail when declared dependencies are thought to be unused, and
> this usage is simply not detected, resulting in the following output and
> exception:
> [WARNING] Unused declared dependencies found:
> [WARNING]com.google.guava:guava:jar:18.0:compile
> [INFO]
>
> Caused by: org.apache.maven.plugin.MojoExecutionException: Dependency
> problems found
> at
> org.apache.maven.plugin.dependency.analyze.AbstractAnalyzeMojo.execute(AbstractAnalyzeMojo.java:187)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> Will try to get a test and patch attached to this once I figure out where
> your test case class file resources are coming from.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MSHARED-581) Filtered resource copyFiles fails on pre-existing symlink
Steven Schlansker created MSHARED-581:
-
Summary: Filtered resource copyFiles fails on pre-existing symlink
Key: MSHARED-581
URL: https://issues.apache.org/jira/browse/MSHARED-581
Project: Maven Shared Components
Issue Type: Bug
Components: maven-shared-utils
Affects Versions: maven-filtering-3.1.1, maven-shared-utils-3.0.0
Environment: Apache Maven 3.3.9
(bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
Maven home: /usr/local/Cellar/maven/3.3.9/libexec
Java version: 1.8.0_77, vendor: Oracle Corporation
Java home: /Users/steven/.jabba/jdk/1.8.77/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
Reporter: Steven Schlansker
I have a file shared between multiple projects via symlink:
{code}
-rw-r--r-- 1 steven staff 149 Mar 30 16:56
client/src/test/resources/simplelogger.properties
lrwxr-xr-x 1 steven staff 64 Oct 16 2014
integration-tests/jersey-client/src/test/resources/simplelogger.properties ->
../../../../../client/src/test/resources/simplelogger.properties
lrwxr-xr-x 1 steven staff 64 Oct 16 2014
integration-tests/resteasy-client/src/test/resources/simplelogger.properties ->
../../../../../client/src/test/resources/simplelogger.properties
{code}
This works fine from a clean build, but on an incremental build, it fails:
{code}
Caused by: org.apache.maven.plugin.MojoExecutionException:
/Users/steven/ot-code/service-discovery/integration-tests/jersey-client/target/test-classes/simplelogger.properties
at
org.apache.maven.plugins.resources.ResourcesMojo.execute(ResourcesMojo.java:348)
at
org.apache.maven.plugins.resources.TestResourcesMojo.execute(TestResourcesMojo.java:75)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 20 more
Caused by: org.apache.maven.shared.filtering.MavenFilteringException:
/Users/steven/ot-code/service-discovery/integration-tests/jersey-client/target/test-classes/simplelogger.properties
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:128)
at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources(DefaultMavenResourcesFiltering.java:232)
at
org.apache.maven.plugins.resources.ResourcesMojo.execute(ResourcesMojo.java:342)
... 23 more
Caused by: java.nio.file.FileAlreadyExistsException:
/Users/steven/ot-code/service-discovery/integration-tests/jersey-client/target/test-classes/simplelogger.properties
at
sun.nio.fs.UnixException.translateToIOException(UnixException.java:88)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at
sun.nio.fs.UnixFileSystemProvider.createSymbolicLink(UnixFileSystemProvider.java:457)
at java.nio.file.Files.createSymbolicLink(Files.java:1043)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.maven.shared.utils.io.Java7Support.createSymbolicLink(Java7Support.java:176)
at
org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:821)
at
org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1939)
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:121)
... 25 more
{code}
Perhaps {{FileUtils.copyFile}} should not attempt to copy over an existing
symlink? It should leave it be if the target is the same, otherwise unlink it
first.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-6016) Maven incorrectly builds POM when you override Shade transformers in a child
[
https://issues.apache.org/jira/browse/MNG-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15270988#comment-15270988
]
Steven Schlansker commented on MNG-6016:
Hi [~michael-o], indeed it does not. But I never configured it!
{code}
META-INF/spring.factories
{code}
I only ever tell it about a {{}}, I think the {{}} comes
from incorrect POM merging.
> Maven incorrectly builds POM when you override Shade transformers in a child
>
>
> Key: MNG-6016
> URL: https://issues.apache.org/jira/browse/MNG-6016
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation, POM
>Affects Versions: 3.3.9
>Reporter: Steven Schlansker
>
> Consider the project:
> https://github.com/stevenschlansker/maven-configure-transformer-bug/
> Simple 2 module project. Parent defines some Shade plugin configuration,
> notably a {{ResourceTransformer}} with a {{mainClass}} declaration.
> Child then tries to add a {{PropertiesMergingResourceTransformer}}, but
> somehow the {{mainClass}} declaration from the parent gets merged into this
> other transformer, causing a build failure:
> {quote}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade (assemble-app) on
> project maven-configure-transformer-bug-child: Unable to parse configuration
> of mojo org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade for parameter
> mainClass: Cannot find 'mainClass' in class
> org.springframework.boot.maven.PropertiesMergingResourceTransformer -> [Help
> 1]
> {quote}
> The effective POM shows that something extremely unintuitive is going on with
> model merging:
> {code}
>
> maven-shade-plugin
> 2.4.3
>
>
> assemble-app
> package
>
> shade
>
>
>
> implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
> META-INF/spring.handlers
>
> implementation="org.springframework.boot.maven.PropertiesMergingResourceTransformer">
> META-INF/spring.factories
> foo
> true
>
> implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
> META-INF/spring.schemas
>
> implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"
> />
> implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"
> />
>
>
>
>
>
>
> org.springframework.boot
> spring-boot-maven-plugin
> 1.3.3.RELEASE
> compile
>
>
>
>
> implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
> META-INF/spring.handlers
>
> implementation="org.springframework.boot.maven.PropertiesMergingResourceTransformer">
> META-INF/spring.factories
> foo
> true
>
> implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
> META-INF/spring.schemas
>
> implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"
> />
> implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"
> />
>
>
>
> {code}
> It is possible to escape this by adding {{combine.self="override"}} to the
> {{}} node. But I think the configuration ending up on the
> wrong transformer is a bug, and the fact that it causes duplicate
> configuration sections is also extremely confusing. And somewhere in the
> shuffle the original {{CollectingManifestResourceTransformer}} is lost
> entirely. (Note that it's not even on the plugin path, so referencing it
> should be an error!)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MNG-6016) Maven incorrectly builds POM when you override Shade transformers in a child
[
https://issues.apache.org/jira/browse/MNG-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Schlansker updated MNG-6016:
---
Description:
Consider the project:
https://github.com/stevenschlansker/maven-configure-transformer-bug/
Simple 2 module project. Parent defines some Shade plugin configuration,
notably a {{ResourceTransformer}} with a {{mainClass}} declaration.
Child then tries to add a {{PropertiesMergingResourceTransformer}}, but somehow
the {{mainClass}} declaration from the parent gets merged into this other
transformer, causing a build failure:
{quote}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade (assemble-app) on
project maven-configure-transformer-bug-child: Unable to parse configuration of
mojo org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade for parameter
mainClass: Cannot find 'mainClass' in class
org.springframework.boot.maven.PropertiesMergingResourceTransformer -> [Help 1]
{quote}
The effective POM shows that something extremely unintuitive is going on with
model merging:
{code}
maven-shade-plugin
2.4.3
assemble-app
package
shade
META-INF/spring.handlers
META-INF/spring.factories
foo
true
META-INF/spring.schemas
org.springframework.boot
spring-boot-maven-plugin
1.3.3.RELEASE
compile
META-INF/spring.handlers
META-INF/spring.factories
foo
true
META-INF/spring.schemas
{code}
It is possible to escape this by adding {{combine.self="override"}} to the
{{}} node. But I think the configuration ending up on the wrong
transformer is a bug, and the fact that it causes duplicate configuration
sections is also extremely confusing. And somewhere in the shuffle the
original {{CollectingManifestResourceTransformer}} is lost entirely. (Note
that it's not even on the plugin path, so referencing it should be an error!)
was:
Consider the project:
https://github.com/stevenschlansker/maven-configure-transformer-bug/
Simple 2 module project. Parent defines some Shade plugin configuration,
notably a {{ResourceTransformer}} with a {{mainClass}} declaration.
Child then tries to add a {{PropertiesMergingResourceTransformer}}, but somehow
the {{mainClass}} declaration from the parent gets merged into this other
transformer, causing a build failure:
{quote}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade (assemble-app) on
project maven-configure-transformer-bug-child: Unable to parse configuration of
mojo org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade for parameter
mainClass: Cannot find 'mainClass' in class
org.springframework.boot.maven.PropertiesMergingResourceTransformer -> [Help 1]
{quote}
The effective POM shows that something extremely unintuitive is going on with
model merging:
{code}
maven-shade-plugin
2.4.3
assemble-app
package
shade
META-INF/spring.handlers
META-INF/spring.factories
foo
true
META-INF/spring.schemas
org.springframework.boot
spring-boot-maven-plugin
1.3.3.RELEASE
compile
META-INF/spring.handlers
META-INF/spring.factories
foo
true
META-INF/spring.schemas
{code}
It is possible to escape this by adding {{combine.self="override}} to the
{{}} node. But I think the configuration ending up on the wrong
transformer is a bug, and the fact that it causes duplicate configuration
sections is also extremely confusing.
> Maven incorrectly builds POM when you override Shade transformers in a child
> ---
[jira] [Updated] (MNG-6016) Maven incorrectly builds POM when you override Shade transformers in a child
[
https://issues.apache.org/jira/browse/MNG-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Schlansker updated MNG-6016:
---
Description:
Consider the project:
https://github.com/stevenschlansker/maven-configure-transformer-bug/
Simple 2 module project. Parent defines some Shade plugin configuration,
notably a {{ResourceTransformer}} with a {{mainClass}} declaration.
Child then tries to add a {{PropertiesMergingResourceTransformer}}, but somehow
the {{mainClass}} declaration from the parent gets merged into this other
transformer, causing a build failure:
{quote}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade (assemble-app) on
project maven-configure-transformer-bug-child: Unable to parse configuration of
mojo org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade for parameter
mainClass: Cannot find 'mainClass' in class
org.springframework.boot.maven.PropertiesMergingResourceTransformer -> [Help 1]
{quote}
The effective POM shows that something extremely unintuitive is going on with
model merging:
{code}
maven-shade-plugin
2.4.3
assemble-app
package
shade
META-INF/spring.handlers
META-INF/spring.factories
foo
true
META-INF/spring.schemas
org.springframework.boot
spring-boot-maven-plugin
1.3.3.RELEASE
compile
META-INF/spring.handlers
META-INF/spring.factories
foo
true
META-INF/spring.schemas
{code}
It is possible to escape this by adding {{combine.self="override}} to the
{{}} node. But I think the configuration ending up on the wrong
transformer is a bug, and the fact that it causes duplicate configuration
sections is also extremely confusing.
was:
Consider the project:
https://github.com/stevenschlansker/maven-configure-transformer-bug/
Simple 2 module project. Parent defines some Shade plugin configuration,
notably a {{ResourceTransformer}} with a {{mainClass}} declaration.
Child then tries to add a {{PropertiesMergingResourceTransformer}}, but somehow
the {{mainClass}} declaration from the parent gets merged into this other
transformer, causing a build failure:
{quote}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade (assemble-app) on
project maven-configure-transformer-bug-child: Unable to parse configuration of
mojo org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade for parameter
mainClass: Cannot find 'mainClass' in class
org.springframework.boot.maven.PropertiesMergingResourceTransformer -> [Help 1]
{quote}
The effective POM shows that something extremely unintuitive is going on with
resource merging:
{code}
maven-shade-plugin
2.4.3
assemble-app
package
shade
META-INF/spring.handlers
META-INF/spring.factories
foo
true
META-INF/spring.schemas
org.springframework.boot
spring-boot-maven-plugin
1.3.3.RELEASE
compile
META-INF/spring.handlers
META-INF/spring.factories
foo
true
META-INF/spring.schemas
{code}
It is possible to escape this by adding {{combine.self="override}} to the
{{}} node. But I think the configuration ending up on the wrong
transformer is a bug, and the fact that it causes duplicate configuration
sections is also extremely confusing.
> Maven incorrectly builds POM when you override Shade transformers in a child
>
>
> Key: MNG-6016
> URL: https://issues.apache.org/jira/browse/MNG-6016
> Project: Maven
> Issue Type: Bug
> Components: Inh
[jira] [Created] (MNG-6016) Maven incorrectly builds POM when you override Shade transformers in a child
Steven Schlansker created MNG-6016:
--
Summary: Maven incorrectly builds POM when you override Shade
transformers in a child
Key: MNG-6016
URL: https://issues.apache.org/jira/browse/MNG-6016
Project: Maven
Issue Type: Bug
Components: Inheritance and Interpolation, POM
Affects Versions: 3.3.9
Reporter: Steven Schlansker
Consider the project:
https://github.com/stevenschlansker/maven-configure-transformer-bug/
Simple 2 module project. Parent defines some Shade plugin configuration,
notably a {{ResourceTransformer}} with a {{mainClass}} declaration.
Child then tries to add a {{PropertiesMergingResourceTransformer}}, but somehow
the {{mainClass}} declaration from the parent gets merged into this other
transformer, causing a build failure:
{quote}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade (assemble-app) on
project maven-configure-transformer-bug-child: Unable to parse configuration of
mojo org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade for parameter
mainClass: Cannot find 'mainClass' in class
org.springframework.boot.maven.PropertiesMergingResourceTransformer -> [Help 1]
{quote}
The effective POM shows that something extremely unintuitive is going on with
resource merging:
{code}
maven-shade-plugin
2.4.3
assemble-app
package
shade
META-INF/spring.handlers
META-INF/spring.factories
foo
true
META-INF/spring.schemas
org.springframework.boot
spring-boot-maven-plugin
1.3.3.RELEASE
compile
META-INF/spring.handlers
META-INF/spring.factories
foo
true
META-INF/spring.schemas
{code}
It is possible to escape this by adding {{combine.self="override}} to the
{{}} node. But I think the configuration ending up on the wrong
transformer is a bug, and the fact that it causes duplicate configuration
sections is also extremely confusing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (MNG-5731) DefaultArtifactCollector loses a transitive dependency with specific combination of versions and RUNTIME scope
Steven Schlansker created MNG-5731:
--
Summary: DefaultArtifactCollector loses a transitive dependency
with specific combination of versions and RUNTIME scope
Key: MNG-5731
URL: https://jira.codehaus.org/browse/MNG-5731
Project: Maven
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.2.3
Environment: Mac OS 10.9, Java 8u25
Reporter: Steven Schlansker
Attachments: maven-loses-transitive-dependency.tgz
Unpack the attached test case. It is a rather large multimodule project which
looks like the following:
{code}
test:i:jar:1 (0; enabled)
test:c:jar:3:compile (1; enabled)
test:b:jar:2:compile (2; enabled)
test:e:jar:2:compile (1; enabled)
test:c:jar:2:compile (2; disabled)
test:b:jar:1:compile (3; disabled)
test:a:jar:1:compile (4; disabled)
test:h:jar:1:runtime (2; enabled)
test:g:jar:1:runtime (3; enabled)
test:a:jar:2:compile (4; disabled)
test:f:jar:1:compile (1; enabled)
test:e:jar:1:compile (2; disabled)
test:c:jar:1:compile (3; disabled)
test:d:jar:1:compile (2; enabled)
test:c:jar:2:compile (3; disabled)
test:b:jar:1:compile (4; disabled)
test:a:jar:2:compile (5; disabled)
{code}
There is a dependency chain I1 -> E2 -> H1 -> G1(runtime) -> A2
During version resolution, the G1->A2 dependency is dropped due to
checkScopeUpdate in favor of upgrading the version of B1 -> A1 into B1 -> A2,
since it has compile scope.
The B1 -> A2 dependency is later suppressed because C3 has a "nearer"
dependency on B2, tossing B1. So A2 is lost even though there is a legitimate
need for it from G1.
To reproduce:
{code}
[steven@Anesthetize:~/ot-code/maven-loses-transitive-dependency]% mvn clean
package && java -cp i1/target/i-1-jar-with-dependencies.jar MainI
Exception in thread "main" java.lang.NoClassDefFoundError: A
at G.(G.java:2)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
at java.lang.Class.newInstance(Class.java:433)
at H.(H.java:6)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:259)
at E.(E.java:5)
at MainI.main(MainI.java:3)
Caused by: java.lang.ClassNotFoundException: A
at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 11 more
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEP-439) maven-dependency-plugin not compatible with Java 8
[
https://jira.codehaus.org/browse/MDEP-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344782#comment-344782
]
Steven Schlansker commented on MDEP-439:
Heads up, you also need a patch like this, otherwise you get exceptions like:
Caused by: java.lang.IllegalArgumentException: INVOKESPECIAL/STATIC on
interfaces require ASM 5
at org.objectweb.asm.MethodVisitor.visitMethodInsn(Unknown Source)
at org.objectweb.asm.ClassReader.a(Unknown Source)
at org.objectweb.asm.ClassReader.b(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at
org.apache.maven.shared.dependency.analyzer.asm.DependencyClassFileVisitor.visitClass(DependencyClassFileVisitor.java:70)
at
org.apache.maven.shared.dependency.analyzer.ClassFileVisitorUtils.visitClass(ClassFileVisitorUtils.java:154)
Index:
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DefaultAnnotationVisitor.java
===
---
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DefaultAnnotationVisitor.java
(revision 1586727)
+++
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DefaultAnnotationVisitor.java
(working copy)
@@ -36,7 +36,7 @@
public DefaultAnnotationVisitor(ResultCollector resultCollector)
{
-super(Opcodes.ASM4);
+super(Opcodes.ASM5);
this.resultCollector = resultCollector;
}
Index:
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DefaultClassVisitor.java
===
---
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DefaultClassVisitor.java
(revision 1586727)
+++
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DefaultClassVisitor.java
(working copy)
@@ -49,7 +49,7 @@
public DefaultClassVisitor(SignatureVisitor signatureVisitor,
AnnotationVisitor annotationVisitor, FieldVisitor fieldVisitor, MethodVisitor
methodVisitor, ResultCollector resultCollector)
{
-super(Opcodes.ASM4);
+super(Opcodes.ASM5);
this.signatureVisitor = signatureVisitor;
this.annotationVisitor = annotationVisitor;
this.fieldVisitor = fieldVisitor;
Index:
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DefaultFieldVisitor.java
===
---
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DefaultFieldVisitor.java
(revision 1586727)
+++
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DefaultFieldVisitor.java
(working copy)
@@ -37,7 +37,7 @@
public DefaultFieldVisitor(AnnotationVisitor annotationVisitor,
ResultCollector resultCollector)
{
-super(Opcodes.ASM4);
+super(Opcodes.ASM5);
this.annotationVisitor = annotationVisitor;
this.resultCollector = resultCollector;
}
Index:
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DefaultMethodVisitor.java
===
---
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DefaultMethodVisitor.java
(revision 1586727)
+++
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DefaultMethodVisitor.java
(working copy)
@@ -39,7 +39,7 @@
public DefaultMethodVisitor(AnnotationVisitor annotationVisitor,
SignatureVisitor signatureVisitor, ResultCollector resultCollector)
{
-super(Opcodes.ASM4);
+super(Opcodes.ASM5);
this.annotationVisitor = annotationVisitor;
this.signatureVisitor = signatureVisitor;
this.resultCollector = resultCollector;
Index:
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DefaultSignatureVisitor.java
===
---
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DefaultSignatureVisitor.java
(revision 1586727)
+++
src/main/java/org/apache/maven/shared/dependency/analyzer/asm/DefaultSignatureVisitor.java
(working copy)
@@ -38,7 +38,7 @@
public DefaultSignatureVisitor(ResultCollector resultCollector)
{
-super(Opcodes.ASM4);
+super(Opcodes.ASM5);
this.resultCollector = resultCollector;
}
> maven-dependency-plugin not compatible with Java 8
> --
>
> Key: MDEP-439
> URL: https://jira.codehaus.org/browse/MDEP-439
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 2.8
> Environment: Java 8
>Reporter: Steven Schlansker
>Assignee: Mirko Friedenhagen
>Priority: Critical
>
> m
[jira] (MDEP-439) maven-dependency-plugin not compatible with Java 8
[ https://jira.codehaus.org/browse/MDEP-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343891#comment-343891 ] Steven Schlansker commented on MDEP-439: Confirmed working for me, thanks so much! Hopefully we can get a release of maven-dependency-plugin so everyone can benefit by default :) > maven-dependency-plugin not compatible with Java 8 > -- > > Key: MDEP-439 > URL: https://jira.codehaus.org/browse/MDEP-439 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 2.8 > Environment: Java 8 >Reporter: Steven Schlansker >Assignee: Mirko Friedenhagen >Priority: Critical > > maven-dependency-plugin uses asm 3.x, which is not compatible with Java 8 > (throws ArrayIndexOutOfBoundsException) > This seriously hinders the use of Maven with Java 8, which is now the > "production" version of Java. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEP-439) maven-dependency-plugin not compatible with Java 8
[ https://jira.codehaus.org/browse/MDEP-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343745#comment-343745 ] Steven Schlansker commented on MDEP-439: https://github.com/stevenschlansker/mdep-439-analyze-java8 > maven-dependency-plugin not compatible with Java 8 > -- > > Key: MDEP-439 > URL: https://jira.codehaus.org/browse/MDEP-439 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 2.8 > Environment: Java 8 >Reporter: Steven Schlansker >Assignee: Mirko Friedenhagen >Priority: Critical > > maven-dependency-plugin uses asm 3.x, which is not compatible with Java 8 > (throws ArrayIndexOutOfBoundsException) > This seriously hinders the use of Maven with Java 8, which is now the > "production" version of Java. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHADE-166) maven-shade-plugin not compatible with Java 8
Steven Schlansker created MSHADE-166: Summary: maven-shade-plugin not compatible with Java 8 Key: MSHADE-166 URL: https://jira.codehaus.org/browse/MSHADE-166 Project: Maven Shade Plugin Issue Type: Bug Affects Versions: 2.2 Environment: Java 8 Reporter: Steven Schlansker Priority: Critical maven-shade-plugin uses asm 3.x which is not compatible with Java 8 (throws ArrayIndexOutOfBoundsException) This seriously hinders the use of Java 8, which is now the production version of Java. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEP-439) maven-dependency-plugin not compatible with Java 8
Steven Schlansker created MDEP-439: -- Summary: maven-dependency-plugin not compatible with Java 8 Key: MDEP-439 URL: https://jira.codehaus.org/browse/MDEP-439 Project: Maven Dependency Plugin Issue Type: Bug Components: analyze Affects Versions: 2.8 Environment: Java 8 Reporter: Steven Schlansker Priority: Critical maven-dependency-plugin uses asm 3.x, which is not compatible with Java 8 (throws ArrayIndexOutOfBoundsException) This seriously hinders the use of Maven with Java 8, which is now the "production" version of Java. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5551) check that everything compile and run fine with Java 8
[ https://jira.codehaus.org/browse/MNG-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343549#comment-343549 ] Steven Schlansker edited comment on MNG-5551 at 3/24/14 7:20 PM: - Maven 3.2.1 does not correctly work with Java 8 due to use of asm 3. asm 5 is the earliest version that supports Java 8. At least the maven-shade-plugin and maven-dependency-plugin are affected. Is there any chance of getting this fixed soon? Java 8 is now out, and it is very sad that Maven is broken with it... was (Author: stevenschlansker): Maven 3.2.1 does not correctly work with Java 8 due to use of asm 3. asm 5 is the earliest version that supports Java 8. > check that everything compile and run fine with Java 8 > -- > > Key: MNG-5551 > URL: https://jira.codehaus.org/browse/MNG-5551 > Project: Maven 2 & 3 > Issue Type: Task >Reporter: Herve Boutemy > > Java 8 will be released shortly: we need a good support as soon as possible > Some ASF Jenkins jobs are available to check and see results in a shared > place: > - > [maven-plugins-ITs-m3.1.x-with-maven-plugin-jdk-1.8|https://builds.apache.org/view/M-R/view/Maven/job/maven-plugins-ITs-m3.1.x-with-maven-plugin-jdk-1.8/modules] > there is a [Wiki page too with some problems > tracked|https://cwiki.apache.org/confluence/display/MAVEN/Java+8+Upgrade] -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5551) check that everything compile and run fine with Java 8
[ https://jira.codehaus.org/browse/MNG-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343549#comment-343549 ] Steven Schlansker commented on MNG-5551: Maven 3.2.1 does not correctly work with Java 8 due to use of asm 3. asm 5 is the earliest version that supports Java 8. > check that everything compile and run fine with Java 8 > -- > > Key: MNG-5551 > URL: https://jira.codehaus.org/browse/MNG-5551 > Project: Maven 2 & 3 > Issue Type: Task >Reporter: Herve Boutemy > > Java 8 will be released shortly: we need a good support as soon as possible > Some ASF Jenkins jobs are available to check and see results in a shared > place: > - > [maven-plugins-ITs-m3.1.x-with-maven-plugin-jdk-1.8|https://builds.apache.org/view/M-R/view/Maven/job/maven-plugins-ITs-m3.1.x-with-maven-plugin-jdk-1.8/modules] > there is a [Wiki page too with some problems > tracked|https://cwiki.apache.org/confluence/display/MAVEN/Java+8+Upgrade] -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] Created: (MRELEASE-715) Impossible to release projects which have compiler args such as Xlint:all
Impossible to release projects which have compiler args such as Xlint:all - Key: MRELEASE-715 URL: https://jira.codehaus.org/browse/MRELEASE-715 Project: Maven 2.x Release Plugin Issue Type: Bug Components: prepare Affects Versions: 2.2.1 Reporter: Steven Schlansker Priority: Critical Attachments: pom.xml When you configure maven-compiler-plugin to pass arguments with a colon to javac, such as -Xlint:all, the release plugin is no longer capable of processing the POM file. e.g. org.apache.maven.plugins maven-compiler-plugin true produces: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.2.1:prepare (default-cli) on project compiler-colon-args: Error reading POM: Error on line 29: The prefix "Xlint" for element "Xlint:all" is not bound. -> [Help 1] A sample pom file is attached. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MCOMPILER-120) Javac compiler plugin doesn't support -Werror
[
https://jira.codehaus.org/browse/MCOMPILER-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281147#comment-281147
]
Steven Schlansker edited comment on MCOMPILER-120 at 10/12/11 12:20 PM:
Thank you, I had to do this actually:
{code}
org.codehaus.plexus
plexus-compiler-api
1.8.2
org.codehaus.plexus
plexus-component-api
org.codehaus.plexus
plexus-compiler-manager
1.8.2
org.codehaus.plexus
plexus-component-api
org.codehaus.plexus
plexus-compiler-javac
1.8.2
runtime
org.codehaus.plexus
plexus-component-api
{code}
but it does work now!
was (Author: stevenschlansker):
Thank you, I had to do this actually:
org.codehaus.plexus
plexus-compiler-api
1.8.2
org.codehaus.plexus
plexus-component-api
org.codehaus.plexus
plexus-compiler-manager
1.8.2
org.codehaus.plexus
plexus-component-api
org.codehaus.plexus
plexus-compiler-javac
1.8.2
runtime
org.codehaus.plexus
plexus-component-api
but it does work now!
> Javac compiler plugin doesn't support -Werror
> -
>
> Key: MCOMPILER-120
> URL: https://jira.codehaus.org/browse/MCOMPILER-120
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Christopher Webster
>Assignee: Kristian Rosenvold
> Fix For: 2.4
>
> Attachments: JavacCompiler.java, JavacCompiler.patch,
> trial-maven.zip, werror.zip
>
>
> If I write a pom file like the following:
> {code:xml}...
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.1
>
> javac
> 1.6
> 1.6
>
>
>
>
>
> true
>
> {code}
> and if there are only warnings, then the build will not fail as intended by
> the compiler Argument. The reason is that in compileInProcess the exit code
> from javac is only considered if there are no messages. In the case of
> treating warnings as errors, there will be messages but no errors so the
> intention of the build failure is lost.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-120) Javac compiler plugin doesn't support -Werror
[
https://jira.codehaus.org/browse/MCOMPILER-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281147#comment-281147
]
Steven Schlansker commented on MCOMPILER-120:
-
Thank you, I had to do this actually:
org.codehaus.plexus
plexus-compiler-api
1.8.2
org.codehaus.plexus
plexus-component-api
org.codehaus.plexus
plexus-compiler-manager
1.8.2
org.codehaus.plexus
plexus-component-api
org.codehaus.plexus
plexus-compiler-javac
1.8.2
runtime
org.codehaus.plexus
plexus-component-api
but it does work now!
> Javac compiler plugin doesn't support -Werror
> -
>
> Key: MCOMPILER-120
> URL: https://jira.codehaus.org/browse/MCOMPILER-120
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Christopher Webster
>Assignee: Kristian Rosenvold
> Fix For: 2.4
>
> Attachments: JavacCompiler.java, JavacCompiler.patch,
> trial-maven.zip, werror.zip
>
>
> If I write a pom file like the following:
> {code:xml}...
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.1
>
> javac
> 1.6
> 1.6
>
>
>
>
>
> true
>
> {code}
> and if there are only warnings, then the build will not fail as intended by
> the compiler Argument. The reason is that in compileInProcess the exit code
> from javac is only considered if there are no messages. In the case of
> treating warnings as errors, there will be messages but no errors so the
> intention of the build failure is lost.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-120) Javac compiler plugin doesn't support -Werror
[
https://jira.codehaus.org/browse/MCOMPILER-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281100#comment-281100
]
Steven Schlansker commented on MCOMPILER-120:
-
I've sent a mail to the plexus compiler user list in the hopes that there are
in fact additional issues fixed worthy of a new release.
> Javac compiler plugin doesn't support -Werror
> -
>
> Key: MCOMPILER-120
> URL: https://jira.codehaus.org/browse/MCOMPILER-120
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Christopher Webster
>Assignee: Kristian Rosenvold
> Fix For: 2.4
>
> Attachments: JavacCompiler.java, JavacCompiler.patch,
> trial-maven.zip, werror.zip
>
>
> If I write a pom file like the following:
> {code:xml}...
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.1
>
> javac
> 1.6
> 1.6
>
>
>
>
>
> true
>
> {code}
> and if there are only warnings, then the build will not fail as intended by
> the compiler Argument. The reason is that in compileInProcess the exit code
> from javac is only considered if there are no messages. In the case of
> treating warnings as errors, there will be messages but no errors so the
> intention of the build failure is lost.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-120) Javac compiler plugin doesn't support -Werror
[
https://jira.codehaus.org/browse/MCOMPILER-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280688#comment-280688
]
Steven Schlansker commented on MCOMPILER-120:
-
Ref:
http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-compiler/1.8.2/plexus-compiler-1.8.2.pom
> Javac compiler plugin doesn't support -Werror
> -
>
> Key: MCOMPILER-120
> URL: https://jira.codehaus.org/browse/MCOMPILER-120
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Christopher Webster
>Assignee: Kristian Rosenvold
> Fix For: 2.4
>
> Attachments: JavacCompiler.java, JavacCompiler.patch,
> trial-maven.zip, werror.zip
>
>
> If I write a pom file like the following:
> {code:xml}...
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.1
>
> javac
> 1.6
> 1.6
>
>
>
>
>
> true
>
> {code}
> and if there are only warnings, then the build will not fail as intended by
> the compiler Argument. The reason is that in compileInProcess the exit code
> from javac is only considered if there are no messages. In the case of
> treating warnings as errors, there will be messages but no errors so the
> intention of the build failure is lost.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-120) Javac compiler plugin doesn't support -Werror
[
https://jira.codehaus.org/browse/MCOMPILER-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280687#comment-280687
]
Steven Schlansker commented on MCOMPILER-120:
-
Kristian commented above that the Plexus compiler was fixed and that 1.8.2 was
released... I can confirm that I see 1.8.2 on various Maven mirrors. Is that
not sufficient? (Sorry, I don't know too much about the dependencies here, I
just want to offer to go bug whoever is blocking this from getting out so I can
use it!)
> Javac compiler plugin doesn't support -Werror
> -
>
> Key: MCOMPILER-120
> URL: https://jira.codehaus.org/browse/MCOMPILER-120
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Christopher Webster
>Assignee: Kristian Rosenvold
> Fix For: 2.4
>
> Attachments: JavacCompiler.java, JavacCompiler.patch,
> trial-maven.zip, werror.zip
>
>
> If I write a pom file like the following:
> {code:xml}...
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.1
>
> javac
> 1.6
> 1.6
>
>
>
>
>
> true
>
> {code}
> and if there are only warnings, then the build will not fail as intended by
> the compiler Argument. The reason is that in compileInProcess the exit code
> from javac is only considered if there are no messages. In the case of
> treating warnings as errors, there will be messages but no errors so the
> intention of the build failure is lost.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-120) Javac compiler plugin doesn't support -Werror
[
https://jira.codehaus.org/browse/MCOMPILER-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280544#comment-280544
]
Steven Schlansker commented on MCOMPILER-120:
-
It seems that maven-compiler-plugin 2.4 still hasn't been released... I don't
suppose that it's easy to do that? I'd love to use this bug fix but I don't
want to maintain my own build unless I have to :-)
> Javac compiler plugin doesn't support -Werror
> -
>
> Key: MCOMPILER-120
> URL: https://jira.codehaus.org/browse/MCOMPILER-120
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Christopher Webster
>Assignee: Kristian Rosenvold
> Fix For: 2.4
>
> Attachments: JavacCompiler.java, JavacCompiler.patch,
> trial-maven.zip, werror.zip
>
>
> If I write a pom file like the following:
> {code:xml}...
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.1
>
> javac
> 1.6
> 1.6
>
>
>
>
>
> true
>
> {code}
> and if there are only warnings, then the build will not fail as intended by
> the compiler Argument. The reason is that in compileInProcess the exit code
> from javac is only considered if there are no messages. In the case of
> treating warnings as errors, there will be messages but no errors so the
> intention of the build failure is lost.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5121) maven seems to lose transitive dependencies from the list of compilation dependencies
[ https://jira.codehaus.org/browse/MNG-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279457#comment-279457 ] Steven Schlansker commented on MNG-5121: That was always the behavior - even in the failing cases, it was always present in dependency:tree even if it did not appear in the class path in the appropriate place. At least, that is my understanding. > maven seems to lose transitive dependencies from the list of compilation > dependencies > - > > Key: MNG-5121 > URL: https://jira.codehaus.org/browse/MNG-5121 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.1, 3.0.2, 3.0.3 > Environment: Fedora Linux, Sun JDK 1.6.0_24, MacOS X 10.6.7, AppleJDK > 1.6.0_24 >Reporter: Henning Schmiedehausen >Priority: Blocker > Attachments: build_failed.log, build_successful.log, maven-pom.xml, > mng-5121.tgz > > > See the attached build logs "build_failed.log" and "build_succesful.log". > They were both created from using the attached POM. The only difference is > that in the successful build the dependency > > > com.google.inject > > guice > > 3.0 > > > is moved to the very top of the dependency list. When diffing the two build > logs, the most important difference is that in the failed log maven picks up > these dependencies: > [DEBUG]com.google.inject:guice:jar:3.0:compile > while in the successful build, the same dependency looks like this: > [DEBUG]com.google.inject:guice:jar:3.0:compile > > [DEBUG] javax.inject:javax.inject:jar:1:compile > > [DEBUG] aopalliance:aopalliance:jar:1.0: > This translates for the successful build into: > [DEBUG] Classpath: > [/Users/henning/private/source/services/thetargetproject/target/classes > > /Users/henning/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar > > > /Users/henning/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar > > [...] > and for the failed build: > [DEBUG] Classpath: [...] > /Users/henning/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar > > > [...] > (note that even for the successful build, the aopalliance dependency still > got dropped). > This behaviour started with maven 3.x, all permutations of the dependencies > build fine with maven 2.2.1 > This problem can be reproduced in all maven 3.0.x versions (.1, .2 and .3). > In both cases, the transitive dependencies of guice 3.0 > (javax.inject:javax.inject and aopalliance:aopalliance) should always be > present. > The same behaviour occurs in the exec-maven-plugin which uses the runtime > dependency path to execute java code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-5121) maven seems to lose transitive dependencies from the list of compilation dependencies
[ https://jira.codehaus.org/browse/MNG-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279446#comment-279446 ] Steven Schlansker edited comment on MNG-5121 at 9/20/11 4:22 PM: - I downloaded Henning's POM file, and tested it locally. With the versions that included the same dependency loop, the compile fails with Compilation failure: Compilation failure: [ERROR] /Volumes/Zoom/code/maven-bugs/mng-5121-a/src/main/java/testing/Badness.java:[3,19] package javax.inject does not exist [ERROR] /Volumes/Zoom/code/maven-bugs/mng-5121-a/src/main/java/testing/Badness.java:[7,27] cannot find symbol which matches the problem as described. When I remove the dependency loop, it prints out many "[WARNING] The POM for io.trumpet.components:tc-config:jar:4.0 is missing, no dependency information available" but compiles and runs successfully. Additionally, downloading the new aether jars as you suggest fixed both the test case I had and Henning's test case. So I am suspecting that it is actually the same problem, and that it is indeed fixed with a new version of aether - do you have any other reason to believe it is not? was (Author: stevenschlansker): I downloaded Henning's POM file, and tested it locally. With the versions that included the same dependency loop, the compile fails with Compilation failure: Compilation failure: [ERROR] /Volumes/Zoom/code/maven-bugs/mng-5121-a/src/main/java/testing/Badness.java:[3,19] package javax.inject does not exist [ERROR] /Volumes/Zoom/code/maven-bugs/mng-5121-a/src/main/java/testing/Badness.java:[7,27] cannot find symbol which matches the problem as described. When I remove the dependency loop, it prints out many "[WARNING] The POM for io.trumpet.components:tc-config:jar:4.0 is missing, no dependency information available" but compiles and runs successfully. Additionally, downloading the new aether jars as you suggest fixed both the test case I had and Henning's test case. So I am suspecting that it is actually the same problem - do you have any other reason to believe it is not? > maven seems to lose transitive dependencies from the list of compilation > dependencies > - > > Key: MNG-5121 > URL: https://jira.codehaus.org/browse/MNG-5121 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.1, 3.0.2, 3.0.3 > Environment: Fedora Linux, Sun JDK 1.6.0_24, MacOS X 10.6.7, AppleJDK > 1.6.0_24 >Reporter: Henning Schmiedehausen >Priority: Blocker > Attachments: build_failed.log, build_successful.log, maven-pom.xml, > mng-5121.tgz > > > See the attached build logs "build_failed.log" and "build_succesful.log". > They were both created from using the attached POM. The only difference is > that in the successful build the dependency > > > com.google.inject > > guice > > 3.0 > > > is moved to the very top of the dependency list. When diffing the two build > logs, the most important difference is that in the failed log maven picks up > these dependencies: > [DEBUG]com.google.inject:guice:jar:3.0:compile > while in the successful build, the same dependency looks like this: > [DEBUG]com.google.inject:guice:jar:3.0:compile > > [DEBUG] javax.inject:javax.inject:jar:1:compile > > [DEBUG] aopalliance:aopalliance:jar:1.0: > This translates for the successful build into: > [DEBUG] Classpath: > [/Users/henning/private/source/services/thetargetproject/target/classes > > /Users/henning/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar > > > /Users/henning/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar > > [...] > and for the failed build: > [DEBUG] Classpath: [...] > /Users/henning/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar > > > [...] > (note that even for the successful build, the aopalliance depen
[jira] Commented: (MNG-5121) maven seems to lose transitive dependencies from the list of compilation dependencies
[ https://jira.codehaus.org/browse/MNG-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279446#comment-279446 ] Steven Schlansker commented on MNG-5121: I downloaded Henning's POM file, and tested it locally. With the versions that included the same dependency loop, the compile fails with Compilation failure: Compilation failure: [ERROR] /Volumes/Zoom/code/maven-bugs/mng-5121-a/src/main/java/testing/Badness.java:[3,19] package javax.inject does not exist [ERROR] /Volumes/Zoom/code/maven-bugs/mng-5121-a/src/main/java/testing/Badness.java:[7,27] cannot find symbol which matches the problem as described. When I remove the dependency loop, it prints out many "[WARNING] The POM for io.trumpet.components:tc-config:jar:4.0 is missing, no dependency information available" but compiles and runs successfully. Additionally, downloading the new aether jars as you suggest fixed both the test case I had and Henning's test case. So I am suspecting that it is actually the same problem - do you have any other reason to believe it is not? > maven seems to lose transitive dependencies from the list of compilation > dependencies > - > > Key: MNG-5121 > URL: https://jira.codehaus.org/browse/MNG-5121 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.1, 3.0.2, 3.0.3 > Environment: Fedora Linux, Sun JDK 1.6.0_24, MacOS X 10.6.7, AppleJDK > 1.6.0_24 >Reporter: Henning Schmiedehausen >Priority: Blocker > Attachments: build_failed.log, build_successful.log, maven-pom.xml, > mng-5121.tgz > > > See the attached build logs "build_failed.log" and "build_succesful.log". > They were both created from using the attached POM. The only difference is > that in the successful build the dependency > > > com.google.inject > > guice > > 3.0 > > > is moved to the very top of the dependency list. When diffing the two build > logs, the most important difference is that in the failed log maven picks up > these dependencies: > [DEBUG]com.google.inject:guice:jar:3.0:compile > while in the successful build, the same dependency looks like this: > [DEBUG]com.google.inject:guice:jar:3.0:compile > > [DEBUG] javax.inject:javax.inject:jar:1:compile > > [DEBUG] aopalliance:aopalliance:jar:1.0: > This translates for the successful build into: > [DEBUG] Classpath: > [/Users/henning/private/source/services/thetargetproject/target/classes > > /Users/henning/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar > > > /Users/henning/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar > > [...] > and for the failed build: > [DEBUG] Classpath: [...] > /Users/henning/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar > > > [...] > (note that even for the successful build, the aopalliance dependency still > got dropped). > This behaviour started with maven 3.x, all permutations of the dependencies > build fine with maven 2.2.1 > This problem can be reproduced in all maven 3.0.x versions (.1, .2 and .3). > In both cases, the transitive dependencies of guice 3.0 > (javax.inject:javax.inject and aopalliance:aopalliance) should always be > present. > The same behaviour occurs in the exec-maven-plugin which uses the runtime > dependency path to execute java code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5121) maven seems to lose transitive dependencies from the list of compilation dependencies
[ https://jira.codehaus.org/browse/MNG-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279434#comment-279434 ] Steven Schlansker commented on MNG-5121: Hrrrm. I was trying to reproduce the same issue but was paring down the test case (we have probably hundreds of dependencies involved otherwise) and this is what I came up with. I will try to work from Henning's example pom, rather than our code base, and see if I can come up with different reproduction steps. > maven seems to lose transitive dependencies from the list of compilation > dependencies > - > > Key: MNG-5121 > URL: https://jira.codehaus.org/browse/MNG-5121 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.1, 3.0.2, 3.0.3 > Environment: Fedora Linux, Sun JDK 1.6.0_24, MacOS X 10.6.7, AppleJDK > 1.6.0_24 >Reporter: Henning Schmiedehausen >Priority: Blocker > Attachments: build_failed.log, build_successful.log, maven-pom.xml, > mng-5121.tgz > > > See the attached build logs "build_failed.log" and "build_succesful.log". > They were both created from using the attached POM. The only difference is > that in the successful build the dependency > > > com.google.inject > > guice > > 3.0 > > > is moved to the very top of the dependency list. When diffing the two build > logs, the most important difference is that in the failed log maven picks up > these dependencies: > [DEBUG]com.google.inject:guice:jar:3.0:compile > while in the successful build, the same dependency looks like this: > [DEBUG]com.google.inject:guice:jar:3.0:compile > > [DEBUG] javax.inject:javax.inject:jar:1:compile > > [DEBUG] aopalliance:aopalliance:jar:1.0: > This translates for the successful build into: > [DEBUG] Classpath: > [/Users/henning/private/source/services/thetargetproject/target/classes > > /Users/henning/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar > > > /Users/henning/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar > > [...] > and for the failed build: > [DEBUG] Classpath: [...] > /Users/henning/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar > > > [...] > (note that even for the successful build, the aopalliance dependency still > got dropped). > This behaviour started with maven 3.x, all permutations of the dependencies > build fine with maven 2.2.1 > This problem can be reproduced in all maven 3.0.x versions (.1, .2 and .3). > In both cases, the transitive dependencies of guice 3.0 > (javax.inject:javax.inject and aopalliance:aopalliance) should always be > present. > The same behaviour occurs in the exec-maven-plugin which uses the runtime > dependency path to execute java code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5121) maven seems to lose transitive dependencies from the list of compilation dependencies
[
https://jira.codehaus.org/browse/MNG-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279371#comment-279371
]
Steven Schlansker commented on MNG-5121:
More specifics about the test case:
In the process of isolating it, I discovered that we inadvertently introduced a
build cycle between different versions. The project as bundled is a large
multi module build, which maven 2 (probably correctly) rejects due to:
Project 'io.trumpet.components:tc-tracking' is duplicated in the reactor
If you remove one of them from the reactor, the error message changes to:
The projects in the reactor contain a cyclic reference: Edge between
'Vertex{label='io.trumpet.components:tc-httpclient'}' and
'Vertex{label='io.trumpet.components:tc-tracking'}' introduces to cycle in the
graph io.trumpet.components:tc-tracking --> io.trumpet.components:tc-httpclient
--> io.trumpet.components:tc-tracking
Interestingly enough, this cycle was *not* detected in our (much larger, "real
life") code base - Maven 2 somehow misses the error but completes the build
successfully. I assume that Maven 2 is now being phased out and further
development is focused on 3, but if you would like a separate test case to show
this issue I could try to isolate it.
Now, on to Maven 3 - the project as bundled is considered valid (even though it
likely should not be, given that there is a dependency cycle that Maven 2
noticed). It bravely forges ahead but loses some transitive dependencies along
the way -- leading to an eventual
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile)
on project mng-5121: Compilation failure: Compilation failure:
[ERROR]
/Volumes/Zoom/code/maven-bugs/mng-5121/badness/src/main/java/testing/Badness.java:[3,23]
package org.slf4j.bridge does not exist
[ERROR]
/Volumes/Zoom/code/maven-bugs/mng-5121/badness/src/main/java/testing/Badness.java:[7,8]
cannot find symbol
[ERROR] symbol : variable SLF4JBridgeHandler
[ERROR] location: class testing.Badness
The SLF4JBridgeHandler is from jul-to-slf4j, which is clearly in the
dependencies:
[INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ mng-5121 ---
[INFO] io.trumpet.testing:mng-5121:jar:1.0-SNAPSHOT
[INFO] +- io.trumpet.components:tc-log:jar:5.0-BOGUS:compile
[INFO] | \- org.slf4j:jul-to-slf4j:jar:1.6.1:compile
[INFO] | \- org.slf4j:slf4j-api:jar:1.6.1:compile
[INFO] \- io.trumpet.testing:tc-message-storage:jar:1.0-SNAPSHOT:compile
[INFO]\- io.trumpet.testing:tc-clients-base:jar:1.0-SNAPSHOT:compile
[INFO] \- io.trumpet.components:tc-tracking:jar:7.0-BOGUS:compile
[INFO] \- io.trumpet.components:tc-httpclient:jar:10.0-BOGUS:compile
But it does not make it to the runtime class path somehow.
Since this is arguably an invalid project setup, it is not clear to me whether
Maven *should* handle it, but whether it does or does not it would be insanely
useful to detect invalid projects like this and warn. Maven 2 seems to have
caught it in the "smaller" test case but did not notice it in our "larger"
world -- and Maven 3 doesn't notice at all.
More than willing to provide more information as requested, hopefully this is
detailed enough to work on. Thank you much for your looking in to this bug!
> maven seems to lose transitive dependencies from the list of compilation
> dependencies
> -
>
> Key: MNG-5121
> URL: https://jira.codehaus.org/browse/MNG-5121
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.1, 3.0.2, 3.0.3
> Environment: Fedora Linux, Sun JDK 1.6.0_24, MacOS X 10.6.7, AppleJDK
> 1.6.0_24
>Reporter: Henning Schmiedehausen
>Priority: Blocker
> Attachments: build_failed.log, build_successful.log, maven-pom.xml,
> mng-5121.tgz
>
>
> See the attached build logs "build_failed.log" and "build_succesful.log".
> They were both created from using the attached POM. The only difference is
> that in the successful build the dependency
>
>
> com.google.inject
>
> guice
>
> 3.0
>
>
> is moved to the very top of the dependency list. When diffing the two build
> logs, the most important difference is that in the failed log m
[jira] Issue Comment Edited: (MNG-5121) maven seems to lose transitive dependencies from the list of compilation dependencies
[ https://jira.codehaus.org/browse/MNG-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279370#comment-279370 ] Steven Schlansker edited comment on MNG-5121 at 9/19/11 6:09 PM: - After a rather annoying amount of work, here is an executable test case, attached. was (Author: stevenschlansker): After a huge amount of work, here is an executable test case, attached. > maven seems to lose transitive dependencies from the list of compilation > dependencies > - > > Key: MNG-5121 > URL: https://jira.codehaus.org/browse/MNG-5121 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.1, 3.0.2, 3.0.3 > Environment: Fedora Linux, Sun JDK 1.6.0_24, MacOS X 10.6.7, AppleJDK > 1.6.0_24 >Reporter: Henning Schmiedehausen >Priority: Blocker > Attachments: build_failed.log, build_successful.log, maven-pom.xml, > mng-5121.tgz > > > See the attached build logs "build_failed.log" and "build_succesful.log". > They were both created from using the attached POM. The only difference is > that in the successful build the dependency > > > com.google.inject > > guice > > 3.0 > > > is moved to the very top of the dependency list. When diffing the two build > logs, the most important difference is that in the failed log maven picks up > these dependencies: > [DEBUG]com.google.inject:guice:jar:3.0:compile > while in the successful build, the same dependency looks like this: > [DEBUG]com.google.inject:guice:jar:3.0:compile > > [DEBUG] javax.inject:javax.inject:jar:1:compile > > [DEBUG] aopalliance:aopalliance:jar:1.0: > This translates for the successful build into: > [DEBUG] Classpath: > [/Users/henning/private/source/services/thetargetproject/target/classes > > /Users/henning/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar > > > /Users/henning/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar > > [...] > and for the failed build: > [DEBUG] Classpath: [...] > /Users/henning/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar > > > [...] > (note that even for the successful build, the aopalliance dependency still > got dropped). > This behaviour started with maven 3.x, all permutations of the dependencies > build fine with maven 2.2.1 > This problem can be reproduced in all maven 3.0.x versions (.1, .2 and .3). > In both cases, the transitive dependencies of guice 3.0 > (javax.inject:javax.inject and aopalliance:aopalliance) should always be > present. > The same behaviour occurs in the exec-maven-plugin which uses the runtime > dependency path to execute java code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-5121) maven seems to lose transitive dependencies from the list of compilation dependencies
[ https://jira.codehaus.org/browse/MNG-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Schlansker updated MNG-5121: --- Attachment: mng-5121.tgz After a huge amount of work, here is an executable test case, attached. > maven seems to lose transitive dependencies from the list of compilation > dependencies > - > > Key: MNG-5121 > URL: https://jira.codehaus.org/browse/MNG-5121 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.1, 3.0.2, 3.0.3 > Environment: Fedora Linux, Sun JDK 1.6.0_24, MacOS X 10.6.7, AppleJDK > 1.6.0_24 >Reporter: Henning Schmiedehausen >Priority: Blocker > Attachments: build_failed.log, build_successful.log, maven-pom.xml, > mng-5121.tgz > > > See the attached build logs "build_failed.log" and "build_succesful.log". > They were both created from using the attached POM. The only difference is > that in the successful build the dependency > > > com.google.inject > > guice > > 3.0 > > > is moved to the very top of the dependency list. When diffing the two build > logs, the most important difference is that in the failed log maven picks up > these dependencies: > [DEBUG]com.google.inject:guice:jar:3.0:compile > while in the successful build, the same dependency looks like this: > [DEBUG]com.google.inject:guice:jar:3.0:compile > > [DEBUG] javax.inject:javax.inject:jar:1:compile > > [DEBUG] aopalliance:aopalliance:jar:1.0: > This translates for the successful build into: > [DEBUG] Classpath: > [/Users/henning/private/source/services/thetargetproject/target/classes > > /Users/henning/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar > > > /Users/henning/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar > > [...] > and for the failed build: > [DEBUG] Classpath: [...] > /Users/henning/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar > > > [...] > (note that even for the successful build, the aopalliance dependency still > got dropped). > This behaviour started with maven 3.x, all permutations of the dependencies > build fine with maven 2.2.1 > This problem can be reproduced in all maven 3.0.x versions (.1, .2 and .3). > In both cases, the transitive dependencies of guice 3.0 > (javax.inject:javax.inject and aopalliance:aopalliance) should always be > present. > The same behaviour occurs in the exec-maven-plugin which uses the runtime > dependency path to execute java code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-616) release:rollback does not honor -DcommitByProject
release:rollback does not honor -DcommitByProject - Key: MRELEASE-616 URL: http://jira.codehaus.org/browse/MRELEASE-616 Project: Maven 2.x Release Plugin Issue Type: Bug Components: rollback Affects Versions: 2.1 Reporter: Steven Schlansker MRELEASE-168 added a commitByProject flag to release:prepare for situations where you have a project layout proj/ mod1/ mod2/ where proj, mod1, mod2 are all different SCM repositories. Effectively, instead of doing commit proj/pom.xml proj/mod1/pom.xml proj/mod2/pom.xml it will run commit proj/pom.xml commit proj/mod1/pom.xml commit proj/mod2/pom.xml This works great, but release:rollback doesn't know about this and still tries to commit them all in one go, which fails if they are different source repositories. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
