[jira] (MNG-5435) Project which has shared dependency with a plugin fails to recognize artifact was downloaded and fails.
[
https://jira.codehaus.org/browse/MNG-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342578#comment-342578
]
Chris Wesdorp commented on MNG-5435:
What exactly is the relation with -llr and repositories with id "central"? My
pom xmls don't override "central" and not repo proxy is used.
> Project which has shared dependency with a plugin fails to recognize artifact
> was downloaded and fails.
> ---
>
> Key: MNG-5435
> URL: https://jira.codehaus.org/browse/MNG-5435
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.0.4
>Reporter: Kirk Rasmussen
>Priority: Blocker
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: a.3, maven2.log, maven.log, pom.xml, settings.xml,
> simple.zip
>
>
> This is a twofer bug report :)
> Issue #1:
> I have included a stripped down version of an example using the maven antrun
> plugin to spawn the Antlr tool. For technical reasons we cannot use the
> native maven Antlr plugin.
> If you look at the attached project you will see that Antlr is a dependency
> of both the antrun plugin:
> {code}
> ...
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> org.antlr
> antlr
> ${antlr.version}
>
> ...
> {code}
> And the project itself:
> {code}
> ...
>
>
> org.antlr
> antlr
>
>
> ...
> {code}
> Starting with a blank M2 local repo, and then running
> $ mvn -e -X -U clean install -s settings.xml > /tmp/maven.log
> Results in failure:
> Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not
> find artifact org.antlr:antlr:jar:3.4
> However this artifact was indeed downloaded (first as a project dependency).
> I stepped through some of the Maven code and it appears to fail during the
> second run through
> org.sonatype.aether.impl.internal.DefaultArtifactResolver#resolve as a plugin
> dependency.
> I strongly suspect it has to do with how
> org.sonatype.aether.impl.internal.EnhancedLocalRepositoryManager#find is
> implemented. It sees the file but it is not being tracked correctly I believe
> so it ignores it.
> If you run the build a second time it will then succeed because the Antlr
> artifacts will be available as they are in the local repo from the previous
> run.
> $ mvn -e -X -U clean install -s settings.xml > /tmp/maven2.log
> I observed the exact same problem when using the Maven enforcer plugin along
> with TestNG as they both depend on beanshell and with the Maven GWT plugin
> and GWT project dependencies.
> This was discovered as an issue once we started clearing out our local repo.
> Once the artifacts are populated locally the issue goes away. It takes a
> couple of runs to get past the bogus "missing artifact" errors but after that
> it is ok. It's difficult to predict when it will fail w/o being intimately
> familiar with all plugin/project dependencies per project.
> I noticed that having Antlr 3.0.4 only as plugin dependency works fine. It
> also works fine if it's only a project dependency. It's the combination of
> having it both as a plugin AND a project dependency causes this problem.
> #2
> My first thought to get around issue #1 was to use dependency:resolve as a
> pre-build step after cleaning the local repo but that doesn't full solve the
> problem.
> Using the Mavan dependency:resolve and dependency:resolve-plugins goals
> partially sidesteps issue #1 but it still gets confused about inter-module
> dependencies.
> For example I have a simple multi-module project that includes: foo-module,
> bar-module, and baz-module (see simple.zip).
> Running:
> $ mvn dependency:resolve dependency:resolve-plugins -s settings.xml
> Results in a build failure on the baz-module:
> [INFO] acme-pom .. SUCCESS [6.835s]
> [INFO] foo-module SUCCESS [1.327s]
> [INFO] bar-module SUCCESS [0.090s]
> [INFO] baz-module FAILURE [0.012s]
> This seems to avoid issue #1 as it doesn't complain about missing Antlr
> artifacts anymore but it gets stuck on the baz-module with the error:
> [ERROR] Failed to execute goal on project baz-module: Could not resolve
> dependencies for project com.acme:baz-module:jar:4.0.0-SNAPSHOT: The
> following artifacts could not be resolved:
> com.acme:foo-module:jar:4.0.0-SNAPSHOT,
> com.acme:bar-module:jar:4.0.0-SNAPSHOT: Could not find artifact
> com.acme:foo-module:jar:4.0.0-SNAPSHOT -> [Help 1]
> In our r
[jira] (MNG-5435) Project which has shared dependency with a plugin fails to recognize artifact was downloaded and fails.
[
https://jira.codehaus.org/browse/MNG-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342396#comment-342396
]
Chris Wesdorp edited comment on MNG-5435 at 3/4/14 3:30 PM:
On my environment I encounter the same issue in combination with the
maven-checkstyle-plugin. The work around seems to be to remove all the state
files (lastUpdated) from the m2 repo folder that holds my JAR file. The
workaround for now is to use the maven dependency plugin to extract the
checkstyle.xml from the other JAR.
I use Maven 3.0.3 but it also happens with 3.1.1.
Are the any clues to where the case of this issue can be found?
was (Author: chriswesdorp):
On my environment I encounter the same issue in combination with the
maven-checkstyle-plugin. The work around seems to be to remove all the state
files (lastUpdated) from the m2 repo folder that holds my JAR file. The
workaround for now is to use the maven dependency plugin to extract the
checkstyle.xml from the other JAR.
Are the any clues to where the case of this issue can be found?
> Project which has shared dependency with a plugin fails to recognize artifact
> was downloaded and fails.
> ---
>
> Key: MNG-5435
> URL: https://jira.codehaus.org/browse/MNG-5435
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.0.4
>Reporter: Kirk Rasmussen
>Priority: Blocker
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: a.3, maven2.log, maven.log, pom.xml, settings.xml,
> simple.zip
>
>
> This is a twofer bug report :)
> Issue #1:
> I have included a stripped down version of an example using the maven antrun
> plugin to spawn the Antlr tool. For technical reasons we cannot use the
> native maven Antlr plugin.
> If you look at the attached project you will see that Antlr is a dependency
> of both the antrun plugin:
> {code}
> ...
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> org.antlr
> antlr
> ${antlr.version}
>
> ...
> {code}
> And the project itself:
> {code}
> ...
>
>
> org.antlr
> antlr
>
>
> ...
> {code}
> Starting with a blank M2 local repo, and then running
> $ mvn -e -X -U clean install -s settings.xml > /tmp/maven.log
> Results in failure:
> Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not
> find artifact org.antlr:antlr:jar:3.4
> However this artifact was indeed downloaded (first as a project dependency).
> I stepped through some of the Maven code and it appears to fail during the
> second run through
> org.sonatype.aether.impl.internal.DefaultArtifactResolver#resolve as a plugin
> dependency.
> I strongly suspect it has to do with how
> org.sonatype.aether.impl.internal.EnhancedLocalRepositoryManager#find is
> implemented. It sees the file but it is not being tracked correctly I believe
> so it ignores it.
> If you run the build a second time it will then succeed because the Antlr
> artifacts will be available as they are in the local repo from the previous
> run.
> $ mvn -e -X -U clean install -s settings.xml > /tmp/maven2.log
> I observed the exact same problem when using the Maven enforcer plugin along
> with TestNG as they both depend on beanshell and with the Maven GWT plugin
> and GWT project dependencies.
> This was discovered as an issue once we started clearing out our local repo.
> Once the artifacts are populated locally the issue goes away. It takes a
> couple of runs to get past the bogus "missing artifact" errors but after that
> it is ok. It's difficult to predict when it will fail w/o being intimately
> familiar with all plugin/project dependencies per project.
> I noticed that having Antlr 3.0.4 only as plugin dependency works fine. It
> also works fine if it's only a project dependency. It's the combination of
> having it both as a plugin AND a project dependency causes this problem.
> #2
> My first thought to get around issue #1 was to use dependency:resolve as a
> pre-build step after cleaning the local repo but that doesn't full solve the
> problem.
> Using the Mavan dependency:resolve and dependency:resolve-plugins goals
> partially sidesteps issue #1 but it still gets confused about inter-module
> dependencies.
> For example I have a simple multi-module project that includes: foo-module,
> bar-module, and baz-module (see simple.zip).
> Running:
> $ mvn dependency:resolve dependency:resolve-plugins -s settings.xml
> Results in a build failure on the baz-module:
> [INFO] acme-pom
[jira] (MNG-5435) Project which has shared dependency with a plugin fails to recognize artifact was downloaded and fails.
[
https://jira.codehaus.org/browse/MNG-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342396#comment-342396
]
Chris Wesdorp commented on MNG-5435:
On my environment I encounter the same issue in combination with the
maven-checkstyle-plugin. The work around seems to be to remove all the state
files (lastUpdated) from the m2 repo folder that holds my JAR file. The
workaround for now is to use the maven dependency plugin to extract the
checkstyle.xml from the other JAR.
Are the any clues to where the case of this issue can be found?
> Project which has shared dependency with a plugin fails to recognize artifact
> was downloaded and fails.
> ---
>
> Key: MNG-5435
> URL: https://jira.codehaus.org/browse/MNG-5435
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.0.4
>Reporter: Kirk Rasmussen
>Priority: Blocker
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: a.3, maven2.log, maven.log, pom.xml, settings.xml,
> simple.zip
>
>
> This is a twofer bug report :)
> Issue #1:
> I have included a stripped down version of an example using the maven antrun
> plugin to spawn the Antlr tool. For technical reasons we cannot use the
> native maven Antlr plugin.
> If you look at the attached project you will see that Antlr is a dependency
> of both the antrun plugin:
> {code}
> ...
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> org.antlr
> antlr
> ${antlr.version}
>
> ...
> {code}
> And the project itself:
> {code}
> ...
>
>
> org.antlr
> antlr
>
>
> ...
> {code}
> Starting with a blank M2 local repo, and then running
> $ mvn -e -X -U clean install -s settings.xml > /tmp/maven.log
> Results in failure:
> Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not
> find artifact org.antlr:antlr:jar:3.4
> However this artifact was indeed downloaded (first as a project dependency).
> I stepped through some of the Maven code and it appears to fail during the
> second run through
> org.sonatype.aether.impl.internal.DefaultArtifactResolver#resolve as a plugin
> dependency.
> I strongly suspect it has to do with how
> org.sonatype.aether.impl.internal.EnhancedLocalRepositoryManager#find is
> implemented. It sees the file but it is not being tracked correctly I believe
> so it ignores it.
> If you run the build a second time it will then succeed because the Antlr
> artifacts will be available as they are in the local repo from the previous
> run.
> $ mvn -e -X -U clean install -s settings.xml > /tmp/maven2.log
> I observed the exact same problem when using the Maven enforcer plugin along
> with TestNG as they both depend on beanshell and with the Maven GWT plugin
> and GWT project dependencies.
> This was discovered as an issue once we started clearing out our local repo.
> Once the artifacts are populated locally the issue goes away. It takes a
> couple of runs to get past the bogus "missing artifact" errors but after that
> it is ok. It's difficult to predict when it will fail w/o being intimately
> familiar with all plugin/project dependencies per project.
> I noticed that having Antlr 3.0.4 only as plugin dependency works fine. It
> also works fine if it's only a project dependency. It's the combination of
> having it both as a plugin AND a project dependency causes this problem.
> #2
> My first thought to get around issue #1 was to use dependency:resolve as a
> pre-build step after cleaning the local repo but that doesn't full solve the
> problem.
> Using the Mavan dependency:resolve and dependency:resolve-plugins goals
> partially sidesteps issue #1 but it still gets confused about inter-module
> dependencies.
> For example I have a simple multi-module project that includes: foo-module,
> bar-module, and baz-module (see simple.zip).
> Running:
> $ mvn dependency:resolve dependency:resolve-plugins -s settings.xml
> Results in a build failure on the baz-module:
> [INFO] acme-pom .. SUCCESS [6.835s]
> [INFO] foo-module SUCCESS [1.327s]
> [INFO] bar-module SUCCESS [0.090s]
> [INFO] baz-module FAILURE [0.012s]
> This seems to avoid issue #1 as it doesn't complain about missing Antlr
> artifacts anymore but it gets stuck on the baz-module with the error:
> [ERROR] Failed to execute goal on project baz-module: Could not resolve
> dependencies for project com.acme:
[jira] (MCHECKSTYLE-205) NPE in CheckstyleReportGenerator.doFilesSummary:654 version 2.11 regression
[
https://jira.codehaus.org/browse/MCHECKSTYLE-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338941#comment-338941
]
Chris Wesdorp edited comment on MCHECKSTYLE-205 at 1/21/14 4:04 AM:
The workaround that worked for me is to disable the inclusion of test
resources. This also works for the OpenGamma project above.
{noformat}
org.apache.maven.plugins
maven-checkstyle-plugin
${maven-checkstyle-plugin.version}
false
org.apache.maven.plugins
maven-checkstyle-plugin
${maven-checkstyle-plugin.version}
false
NPE in CheckstyleReportGenerator.doFilesSummary:654 version 2.11 regression
> ---
>
> Key: MCHECKSTYLE-205
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-205
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.11, 2.12
> Environment: maven-checkstyle-plugin v2.11 and 2.12-SNAPSHOT (as of
> 12/5/13). Windows 7, JDK7.45 64 bit, maven 3.1
>Reporter: Bob Fields
> Attachments: CheckstyleResults.java.patch
>
>
> This worked in release 2.10, no longer works in 2.11. Running mvn site
> against a large project with a parent pom with many subprojects (though no
> code in the parent project) (andromda v3.5-SNAPSHOT, from sourceforge). Maven
> output:
> [INFO] Generating "Checkstyle" report---
> maven-checkstyle-plugin:2.12-SNAPSHOT
> [INFO] Starting audit...
> ... About 6000 files ...
> Audit done.
> [INFO] There are 4777 checkstyle errors.
> And no additional troubleshooting information, even in debug mode ...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> andromda: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> NullPointerException -> [Help 1]
> Caused by: java.lang.NullPointerException
> at java.lang.String.compareTo(String.java:1139)
> at java.lang.String.compareTo(String.java:108)
> at
> java.util.ComparableTimSort.countRunAndMakeAscending(ComparableTimSort.java:290)
> at java.util.ComparableTimSort.sort(ComparableTimSort.java:171)
> at java.util.ComparableTimSort.sort(ComparableTimSort.java:146)
> at java.util.Arrays.sort(Arrays.java:472)
> at java.util.Collections.sort(Collections.java:155)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleReportGenerator.doFilesSummary(CheckstyleReportGenerator.java:654)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleReportGenerator.generateReport(CheckstyleReportGenerator.java:134)
> I built version 2.12-SNAPSHOT locally, the NPE still exists. Running with
> version 2.10 - no NPE. The code attempts to run Collections.sort on a null
> key in the ArrayList from checkstyle results.getFiles().keySet(). This area
> of code was not modified in any of the previous revisions going into release
> 2.11. The results Collection is populated from
> DefaultCheckstyleExecutor.executeChecks calling sinkListener.addDirectory,
> but that method code also did not change over the last year.
> This bug prevents us from using the latest checkstyle version. If the stack
> trace isn't enough to be able to add an extra null value check in
> executeChecks, I could run in debug mode and figure where the difference in
> values from 2.10 and 2.11 comes from, but it may be a little while before I
> can get to that.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHECKSTYLE-205) NPE in CheckstyleReportGenerator.doFilesSummary:654 version 2.11 regression
[
https://jira.codehaus.org/browse/MCHECKSTYLE-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=338941#comment-338941
]
Chris Wesdorp commented on MCHECKSTYLE-205:
---
The workaround that worked for me is to disable the inclusion of test
resources. This also works for the OpenGamma project above.
{noformat}
org.apache.maven.plugins
maven-checkstyle-plugin
${maven-checkstyle-plugin.version}
false
NPE in CheckstyleReportGenerator.doFilesSummary:654 version 2.11 regression
> ---
>
> Key: MCHECKSTYLE-205
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-205
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.11, 2.12
> Environment: maven-checkstyle-plugin v2.11 and 2.12-SNAPSHOT (as of
> 12/5/13). Windows 7, JDK7.45 64 bit, maven 3.1
>Reporter: Bob Fields
> Attachments: CheckstyleResults.java.patch
>
>
> This worked in release 2.10, no longer works in 2.11. Running mvn site
> against a large project with a parent pom with many subprojects (though no
> code in the parent project) (andromda v3.5-SNAPSHOT, from sourceforge). Maven
> output:
> [INFO] Generating "Checkstyle" report---
> maven-checkstyle-plugin:2.12-SNAPSHOT
> [INFO] Starting audit...
> ... About 6000 files ...
> Audit done.
> [INFO] There are 4777 checkstyle errors.
> And no additional troubleshooting information, even in debug mode ...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> andromda: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed.
> NullPointerException -> [Help 1]
> Caused by: java.lang.NullPointerException
> at java.lang.String.compareTo(String.java:1139)
> at java.lang.String.compareTo(String.java:108)
> at
> java.util.ComparableTimSort.countRunAndMakeAscending(ComparableTimSort.java:290)
> at java.util.ComparableTimSort.sort(ComparableTimSort.java:171)
> at java.util.ComparableTimSort.sort(ComparableTimSort.java:146)
> at java.util.Arrays.sort(Arrays.java:472)
> at java.util.Collections.sort(Collections.java:155)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleReportGenerator.doFilesSummary(CheckstyleReportGenerator.java:654)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleReportGenerator.generateReport(CheckstyleReportGenerator.java:134)
> I built version 2.12-SNAPSHOT locally, the NPE still exists. Running with
> version 2.10 - no NPE. The code attempts to run Collections.sort on a null
> key in the ArrayList from checkstyle results.getFiles().keySet(). This area
> of code was not modified in any of the previous revisions going into release
> 2.11. The results Collection is populated from
> DefaultCheckstyleExecutor.executeChecks calling sinkListener.addDirectory,
> but that method code also did not change over the last year.
> This bug prevents us from using the latest checkstyle version. If the stack
> trace isn't enough to be able to add an extra null value check in
> executeChecks, I could run in debug mode and figure where the difference in
> values from 2.10 and 2.11 comes from, but it may be a little while before I
> can get to that.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
