[jira] Closed: (MNG-4879) CLONE -Multiple Executions of Plugin at Difference Inhertiance levels causes plugin executions to run multiple times
[
http://jira.codehaus.org/browse/MNG-4879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4879.
--
Resolution: Cannot Reproduce
Assignee: Benjamin Bentmann (was: John Casey)
Not able to reproduce from the information given, both inherited execution and
child execution run exactly once:
{noformat}
> mvn -V package
Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
Java version: 1.5.0_22
Java home: D:\java\jdk-1.5\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 7" version: "6.1" arch: "x86" Family: "windows"
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building Child Repeat Execution Test 1.0
[INFO]
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @
child-repeat-test ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
M:\downloads\repeat-test\repeat-test\repeat-child-test\src\main\resources
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @
child-repeat-test ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @
child-repeat-test ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory
M:\downloads\repeat-test\repeat-test\repeat-child-test\src\test\resources
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @
child-repeat-test ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.5:test (default-test) @ child-repeat-test ---
[INFO] No tests to run.
[INFO]
[INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) @ child-repeat-test ---
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO]
[INFO] --- maven-antrun-plugin:1.3:run (parent-echo) @ child-repeat-test ---
[INFO] Executing tasks
[echo] PARENT TESTING
[INFO] Executed tasks
[INFO]
[INFO] --- maven-antrun-plugin:1.3:run (child-echo) @ child-repeat-test ---
[INFO] Executing tasks
[echo] CHILD TESTING
[INFO] Executed tasks
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1.050s
[INFO] Finished at: Wed Oct 27 10:13:36 CEST 2010
[INFO] Final Memory: 3M/7M
[INFO]
{noformat}
> CLONE -Multiple Executions of Plugin at Difference Inhertiance levels causes
> plugin executions to run multiple times
>
>
> Key: MNG-4879
> URL: http://jira.codehaus.org/browse/MNG-4879
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Reporter: David Bernard
>Assignee: Benjamin Bentmann
>Priority: Critical
> Attachments: repeat-test.zip
>
>
> Can occur in a variety of ways, but the attached test case shows a parent pom
> defining an antrun-execution, and then a child specifying another execution
> with a different id. Both executions run twice when running from the child.
> I believe this is the same as Kenney Westerhof's comment:
> http://jira.codehaus.org/browse/MNG-2054#action_62477
--
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
[jira] Commented: (MSITE-518) Aggregated javadoc report not generated for multi-module project at sub-level if run from parent level.
[
http://jira.codehaus.org/browse/MSITE-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=241140#action_241140
]
André Fügenschuh commented on MSITE-518:
Some further investigations:
1)
Using {{mvn site}} apidocs *are* generated at (*wrong*)
_library.modules-\[a|b\]_ level,
using {{mvn site:stage}} _library_'s apidocs are *not* generated at all.
Caused by automatic (inherited?) invocation at the very end of the reactor run:
{noformat}
...
[INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.7:javadoc'
has not be previously called for the project:
'foo.library:module-a:jar:3.0-SNAPSHOT'.
Trying to invoke it...
[INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.7:javadoc'
has not be previously called for the project:
'foo.library:module-b:jar:3.0-SNAPSHOT'.
Trying to invoke it...
...
{noformat}
2)
Trying to break inheritance in the _library_ pom with the {{}}
element, it appears that it's not
allowed at any level: neither at _javadoc_ {{}} nor at its
{{}}.
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:site (default-site)
on project library: Unable to parse configuration of mojo
org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:site
for parameter plugin: Cannot find setter nor field in
org.apache.maven.plugins.site.ReportPlugin for 'inherited' -> [Help 1]
...
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:site (default-site)
on project parent: Unable to parse configuration of mojo
org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:site
for parameter reportSet: Cannot find setter nor field in
org.apache.maven.plugins.site.ReportSet for 'inherited' -> [Help 1]
{noformat}
Question: is this a) by design, b) simply yet missing, or c) a bug?
> Aggregated javadoc report not generated for multi-module project at sub-level
> if run from parent level.
> ---
>
> Key: MSITE-518
> URL: http://jira.codehaus.org/browse/MSITE-518
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: inheritance, multi module
>Affects Versions: 3.0-beta-3
> Environment: Windows Vista x64, JDK 6u22, Maven 3.0
>Reporter: André Fügenschuh
> Attachments: maven3-site-javadoc-testcase.zip
>
>
> With a +multi-module project design+ (cf. attached testcase):
> {noformat}
> - parent(pom)
> + library (pom) // javadoc:aggregate
> + module-a (jar)
> + module-b (jar)
> + application (jar) // javadoc:javadoc
> {noformat}
> run
> {{mvn site}} | {{mvn -DstagingDirectory=\[dir\] site:stage}}
> at _parent_ level.
> +Result:+
> Aggregated javadocs for _library_ are *not* generated (but are properly done
> if {{mvn site}} is run at _library_ level itself), while javadocs at
> _application_ level are generated.
> OT: as appropriate {{}} sections are declared (cf. attached
> testcase), {{mvn compile}} runs as expected at _parent_ level.
> This is a follow-up to MJAVADOC-181, which, although marked as resolved, has
> never been working for me using the _old_ site/reports configuration for
> Maven 2.2.1 / Site plugin 2.1.1.
--
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
[jira] Commented: (MJAVADOC-297) NullPointerException in AbstractFixJavadocMojo.writeParamTag()
[
http://jira.codehaus.org/browse/MJAVADOC-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=241149#action_241149
]
Vincent Siveton commented on MJAVADOC-297:
--
It seems that a given javadoc param has no type. Could you isolate your error
and give us a sample?
> NullPointerException in AbstractFixJavadocMojo.writeParamTag()
> --
>
> Key: MJAVADOC-297
> URL: http://jira.codehaus.org/browse/MJAVADOC-297
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.7
> Environment: graham-leggetts-macbook-pro-3:patricia-db-trunk minfrin$
> mvn --version
> Apache Maven 2.2.0 (r788681; 2009-06-26 15:04:01+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac"
>Reporter: Graham Leggett
>
> While attempting to run the javadoc:fix goal against source code, v2.7 of the
> javadoc plugin crashed as follows:
> {noformat}[INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.plugin.javadoc.AbstractFixJavadocMojo.writeParamTag(AbstractFixJavadocMojo.java:1958)
> at
> org.apache.maven.plugin.javadoc.AbstractFixJavadocMojo.updateJavadocTags(AbstractFixJavadocMojo.java:1842)
> at
> org.apache.maven.plugin.javadoc.AbstractFixJavadocMojo.updateJavadocTags(AbstractFixJavadocMojo.java:1747)
> at
> org.apache.maven.plugin.javadoc.AbstractFixJavadocMojo.updateJavadocComment(AbstractFixJavadocMojo.java:1658)
> at
> org.apache.maven.plugin.javadoc.AbstractFixJavadocMojo.updateEntityComment(AbstractFixJavadocMojo.java:1527)
> at
> org.apache.maven.plugin.javadoc.AbstractFixJavadocMojo.fixMethodComment(AbstractFixJavadocMojo.java:1391)
> at
> org.apache.maven.plugin.javadoc.AbstractFixJavadocMojo.processFix(AbstractFixJavadocMojo.java:993)
> at
> org.apache.maven.plugin.javadoc.AbstractFixJavadocMojo.execute(AbstractFixJavadocMojo.java:405)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {noformat}
--
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
[jira] Commented: (MJAVADOC-298) java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl cannot be cast to com.sun.javadoc.AnnotationTypeDoc when building a javadoc-jar
[
http://jira.codehaus.org/browse/MJAVADOC-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=241150#action_241150
]
Vincent Siveton commented on MJAVADOC-298:
--
mvn clean install from your test case works for me. My env:
{noformat}
$ mvn -version
Apache Maven 3.0 (r1004208; 2010-10-04 07:50:56-0400)
Java version: 1.6.0_22
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: fr_FR, platform encoding: MacRoman
OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
{noformat}
What is your env?
> java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl cannot be
> cast to com.sun.javadoc.AnnotationTypeDoc when building a javadoc-jar
>
>
> Key: MJAVADOC-298
> URL: http://jira.codehaus.org/browse/MJAVADOC-298
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Marius Kruger
> Attachments: test-javadoc.zip
>
>
> I'm trying to build java-doc jar, but I get the stack trace below if I run
> `mvn install` in the attached maven project.
> I tried the workarounds in the following, but could not get them to work for
> building a javadoc-jar:
> http://jira.codehaus.org/browse/MJAVADOC-214
> http://maven.40175.n5.nabble.com/JavaDoc-Report-crashes-with-TestNG-td106262.html
> [ERROR] MavenReportException: Error while creating archive:
>
>
> Exit code: 1 -
> /stf/prj/arch_prototypes/maven/test-javadoc/src/main/java/com/google/common/collect/UnFinalHashMultimap.java:49:
> warning - Tag @link: reference not found:
> com.google.common.collect.HashMultimaps
> /stf/prj/arch_prototypes/maven/test-javadoc/src/main/java/com/google/common/collect/UnFinalHashMultimap.java:49:
> warning - Tag @link: reference not found: http
>
> ://code.google.com/p/guava-libraries/issues/detail?id=338
>
>
> java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl cannot be
> cast to com.sun.javadoc.AnnotationTypeDoc
>
> at
> com.sun.tools.javadoc.AnnotationDescImpl.annotationType(AnnotationDescImpl.java:46)
>
>
> at
> com.sun.tools.doclets.formats.html.HtmlDocletWriter.getAnnotations(HtmlDocletWriter.java:1739)
>
>
> at
> com.sun.tools.doclets.formats.html.HtmlDocletWriter.writeAnnotationInfo(HtmlDocletWriter.java:1713)
>
>
> at
> com.sun.tools.doclets.formats.html.HtmlDocletWriter.writeAnnotationInfo(HtmlDocletWriter.java:1692)
>
>
> at
> com.sun.tools.doclets.formats.html.AbstractExecutableMemberWriter.writeParameters(AbstractExecutableMemberWriter.java:117)
>
> at
> com.sun.tools.doclets.formats.html.AbstractExecutableMemberWriter.writeParameters(AbstractExecutableMemberWriter.java:100)
>
> at
> com.sun.tools.doclets.formats.html.MethodWriterImpl.writeSignature(MethodWriterImpl.java:154)
>
>
> at
> com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.buildSignature(MethodBuilder.java:176)
>
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
>
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce
[jira] Created: (MNG-4880) apache-release does unwanted things in the prepare goal
apache-release does unwanted things in the prepare goal --- Key: MNG-4880 URL: http://jira.codehaus.org/browse/MNG-4880 Project: Maven 2 & 3 Issue Type: Bug Components: Apache or Maven Parent poms Reporter: Benson Margulies Release 7 of the org.apache:apache use -P to turn on an 'apache-release' profile in the release plugin. By using -P, this profile is turned on in prepare as well as perform. This may turn into a contest of opinion, and you all may just tell me to jump in a lake, but I think this is a bad idea. At prepare time, we're just looking to get the versions setup and the tag made. Having to deal with gpg signing, and source archiving seems out of place. At very least, I'd request that this the element be left out of the release plugin spec. If some project wants to use that particular collection of functions, fine. For the rest of us, who just want to get distribution management and other universals, you we wouldn't have to worry about it. -- 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
[jira] Commented: (MNG-4142) Maven doesn't try to download a dependency when it already exists a version with classifier locally
[
http://jira.codehaus.org/browse/MNG-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=241160#action_241160
]
Martin Todorov commented on MNG-4142:
-
Hi,
I would like to ask why the attached patch is not being accepted?
There are currently over three dozen votes for this and it is apparent that
people are hitting the problem.
In addition, perhaps the title of the bug is not quite correct. This doesn't
just happen for artifacts with classifiers. In our case it happens for POM
files where there are several inherited POMs.
We're using Hudson and Nexus had to limit the parents to build on one Hudson
node, while all modules which depend on them - on the rest of the nodes.
I also think this is a huge and very obscure problem (esp. with distributed
builds) and, provided that there is already a patch, I believe it's about time
for it to be reviewed.
Regards,
Martin
> Maven doesn't try to download a dependency when it already exists a version
> with classifier locally
> ---
>
> Key: MNG-4142
> URL: http://jira.codehaus.org/browse/MNG-4142
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.9, 2.0.10, 2.1.0
> Environment: Java 5, Windows XP
>Reporter: Arnaud Heritier
>Priority: Critical
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: MNG-4142.patch, test-metadata-local-clover.zip
>
>
> When maven installs in the local repository an artifact with a classifier,
> and not the principal artifact, it won't try in a reactor to download the
> principal artifact from the remote repository.
> I created a testcase to reproduce it. It's quite simple. You unzip it and in
> the root directory you launch {code}mvn site{code}
> This build uses clover, thus it installs locally cloverified versions of
> artifacts.
> The build will fail because it doesn't find the SNAPSHOT of the module1 :
> {code}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/pa
> th/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path
> /to/file -Durl=[url] -DrepositoryId=[id]
> Path to dependency:
> 1)
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> 2)
> org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> from the specified remote repositories:
> central (http://maven-proxy.groupe.generali.fr/all),
> remote-repo
> (file://E:\jtb\workspaces\tests\test-metadata-local-clover/remote-repo)
> {code}
> It's anormal because I set a "local" remote repository in the build where it
> should try to download it.
> You can validate that it is working by launching :
> {code}mvn install -f module2/pom.xml{code}
> This bug is really annoying for us. It exists for a long long time now. I
> thought it was due to a problem with metadata sent by archiva, but after
> migrating to nexus the problem always occurs.
> I don't know if the problem is in metadata or in the reactor itself. I think
> it is the second one. There are many issues opened about the reactor and
> classifiers.
> Is there some who can try if it can reproduce the error with my testcase ?
> It should be easy to create a real IT for maven with it if it is necessary.
--
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
[jira] Closed: (MPIR-205) Add the license information for each dependency
[ http://jira.codehaus.org/browse/MPIR-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPIR-205. Resolution: Fixed Fix Version/s: 2.3 Assignee: Vincent Siveton Fixed in r1027937 with minor modifications, snapshot deployed. > Add the license information for each dependency > --- > > Key: MPIR-205 > URL: http://jira.codehaus.org/browse/MPIR-205 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: New Feature >Affects Versions: 2.1 >Reporter: Matthew Smith >Assignee: Vincent Siveton > Fix For: 2.3 > > Attachments: patch > > > The current Dependency report includes tables for the dependencies that > include GroupId,ArtifactId, Version, Classifier,Type. This patch will > include a License column to the tables. The License will also be a link > making it easier to relate licenses to atrifacts. The License section of the > document is affected. -- 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
[jira] Commented: (MNG-4142) Maven doesn't try to download a dependency when it already exists a version with classifier locally
[
http://jira.codehaus.org/browse/MNG-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=241162#action_241162
]
Arnaud Heritier commented on MNG-4142:
--
Were you able to test if the problem exists with maven 3 ?
I agree that this issue is really annoying but for now there is no 2.X version
release scheduled.
That's why there was no feedback from dev team.
> Maven doesn't try to download a dependency when it already exists a version
> with classifier locally
> ---
>
> Key: MNG-4142
> URL: http://jira.codehaus.org/browse/MNG-4142
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.9, 2.0.10, 2.1.0
> Environment: Java 5, Windows XP
>Reporter: Arnaud Heritier
>Priority: Critical
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: MNG-4142.patch, test-metadata-local-clover.zip
>
>
> When maven installs in the local repository an artifact with a classifier,
> and not the principal artifact, it won't try in a reactor to download the
> principal artifact from the remote repository.
> I created a testcase to reproduce it. It's quite simple. You unzip it and in
> the root directory you launch {code}mvn site{code}
> This build uses clover, thus it installs locally cloverified versions of
> artifacts.
> The build will fail because it doesn't find the SNAPSHOT of the module1 :
> {code}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/pa
> th/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file
> -DgroupId=org.apache.maven.it.test-metadata-local-clover -DartifactId=module1
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path
> /to/file -Durl=[url] -DrepositoryId=[id]
> Path to dependency:
> 1)
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> 2)
> org.apache.maven.it.test-metadata-local-clover:module1:jar:1.0.0-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> org.apache.maven.it.test-metadata-local-clover:module2:jar:1.0.0-SNAPSHOT
> from the specified remote repositories:
> central (http://maven-proxy.groupe.generali.fr/all),
> remote-repo
> (file://E:\jtb\workspaces\tests\test-metadata-local-clover/remote-repo)
> {code}
> It's anormal because I set a "local" remote repository in the build where it
> should try to download it.
> You can validate that it is working by launching :
> {code}mvn install -f module2/pom.xml{code}
> This bug is really annoying for us. It exists for a long long time now. I
> thought it was due to a problem with metadata sent by archiva, but after
> migrating to nexus the problem always occurs.
> I don't know if the problem is in metadata or in the reactor itself. I think
> it is the second one. There are many issues opened about the reactor and
> classifiers.
> Is there some who can try if it can reproduce the error with my testcase ?
> It should be easy to create a real IT for maven with it if it is necessary.
--
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
[jira] Created: (MJAVADOC-299) excludePackageNames has no effect if subpackages is specified
excludePackageNames has no effect if subpackages is specified - Key: MJAVADOC-299 URL: http://jira.codehaus.org/browse/MJAVADOC-299 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.7 Reporter: Paul Mealor Priority: Minor I am using a configuration something like the following: org.apache.maven.plugins maven-javadoc-plugin 2.7 foo.bar.api foo.bar.api.impl:*impl:*.impl true jar When I do this, every package under subpackages is included in my Javadoc, including foo.bar.api.impl. The @options file includes "-subpackages foo.bar.api", but does not include "-exclude". No @packages file is created. If I do not include , the works as desired: an @packages file is produced that excludes every package named like *.impl. Unfortunately, in my case, this means that packages like foo.bar.qux is included in the Javadoc, and I do not want that included. It would seem sensible if was used to generate the @packages file, the same as if no packages are specified. Then could be applied to the list of packages in that file. My best workaround so far is to do the following, which tricks Javadoc and the plugin into building only foo.bar.api and foo.bar.api.event org.apache.maven.plugins maven-javadoc-plugin 2.7 none foo.bar.api foo.bar.api.event true jar -- 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
[jira] Commented: (MJAVADOC-298) java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl cannot be cast to com.sun.javadoc.AnnotationTypeDoc when building a javadoc-jar
[ http://jira.codehaus.org/browse/MJAVADOC-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=241184#action_241184 ] Marius Kruger commented on MJAVADOC-298: Thanks for the hint, I mainly use the following: $ mvn -version Apache Maven 2.2.1 (rdebian-4) Java version: 1.6.0_22 Java home: /usr/lib/jvm/java-6-sun-1.6.0.22/jre Default locale: en_ZA, platform encoding: UTF-8 OS name: "linux" version: "2.6.35-22-generic" arch: "amd64" Family: "unix" but I tested it now and I can reproduce this with the following too: $ /stf/opt/apache-maven-2.2.1/bin/mvn -version Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) ... $ /stf/opt/apache-maven-3.0/bin/mvn -version Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200) > java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl cannot be > cast to com.sun.javadoc.AnnotationTypeDoc when building a javadoc-jar > > > Key: MJAVADOC-298 > URL: http://jira.codehaus.org/browse/MJAVADOC-298 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Marius Kruger > Attachments: test-javadoc.zip > > > I'm trying to build java-doc jar, but I get the stack trace below if I run > `mvn install` in the attached maven project. > I tried the workarounds in the following, but could not get them to work for > building a javadoc-jar: > http://jira.codehaus.org/browse/MJAVADOC-214 > http://maven.40175.n5.nabble.com/JavaDoc-Report-crashes-with-TestNG-td106262.html > [ERROR] MavenReportException: Error while creating archive: > > > Exit code: 1 - > /stf/prj/arch_prototypes/maven/test-javadoc/src/main/java/com/google/common/collect/UnFinalHashMultimap.java:49: > warning - Tag @link: reference not found: > com.google.common.collect.HashMultimaps > /stf/prj/arch_prototypes/maven/test-javadoc/src/main/java/com/google/common/collect/UnFinalHashMultimap.java:49: > warning - Tag @link: reference not found: http > > ://code.google.com/p/guava-libraries/issues/detail?id=338 > > > java.lang.ClassCastException: com.sun.tools.javadoc.ClassDocImpl cannot be > cast to com.sun.javadoc.AnnotationTypeDoc > > at > com.sun.tools.javadoc.AnnotationDescImpl.annotationType(AnnotationDescImpl.java:46) > > > at > com.sun.tools.doclets.formats.html.HtmlDocletWriter.getAnnotations(HtmlDocletWriter.java:1739) > > > at > com.sun.tools.doclets.formats.html.HtmlDocletWriter.writeAnnotationInfo(HtmlDocletWriter.java:1713) > > > at > com.sun.tools.doclets.formats.html.HtmlDocletWriter.writeAnnotationInfo(HtmlDocletWriter.java:1692) > > > at > com.sun.tools.doclets.formats.html.AbstractExecutableMemberWriter.writeParameters(AbstractExecutableMemberWriter.java:117) > > at > com.sun.tools.doclets.formats.html.AbstractExecutableMemberWriter.writeParameters(AbstractExecutableMemberWriter.java:100) > > at > com.sun.tools.doclets.formats.html.MethodWriterImpl.writeSignature(MethodWriterImpl.java:154) > > > at > com.sun.tools.doclets.internal.toolkit.builders.MethodBuilder.buildSignature(MethodBuilder.java:176) > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >
[jira] Created: (MASSEMBLY-518) Select which output formats by profile
Select which output formats by profile -- Key: MASSEMBLY-518 URL: http://jira.codehaus.org/browse/MASSEMBLY-518 Project: Maven 2.x Assembly Plugin Issue Type: New Feature Affects Versions: 2.2 Reporter: Benson Margulies When debugging an assembly descriptor, it sure would be nice to be able to just make the '.dir' and not any other formats specified. Yea, I can use a temporary XML comment, but wouldn't it be nice to control these from a POM profile somehow? -- 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
[jira] Commented: (MJAVADOC-289) generate javadoc warnings report
[ http://jira.codehaus.org/browse/MJAVADOC-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=241224#action_241224 ] Lukas Theussl commented on MJAVADOC-289: If I count as a final user, yes, I would care! ;) But it's not a high-priority issue. > generate javadoc warnings report > > > Key: MJAVADOC-289 > URL: http://jira.codehaus.org/browse/MJAVADOC-289 > Project: Maven 2.x Javadoc Plugin > Issue Type: New Feature >Reporter: Lukas Theussl > > A la m1, eg > http://maven.apache.org/maven-1.x/plugins/javadoc/javadoc-warnings-report.html -- 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
[jira] Closed: (MENFORCER-108) Documentation/Typo : 'unCheckedPluginsList' is written instead of 'unCheckedPluginList'
[ http://jira.codehaus.org/browse/MENFORCER-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MENFORCER-108. --- Resolution: Fixed Fix Version/s: 1.0 > Documentation/Typo : 'unCheckedPluginsList' is written instead of > 'unCheckedPluginList' > --- > > Key: MENFORCER-108 > URL: http://jira.codehaus.org/browse/MENFORCER-108 > Project: Maven 2.x Enforcer Plugin > Issue Type: Bug > Components: Standard Rules >Affects Versions: 1.0-beta-1 >Reporter: Jonathan Perret >Priority: Minor > Fix For: 1.0 > > > The documentation at > http://maven.apache.org/enforcer/enforcer-rules/requirePluginVersions.html > uses the element name 'unCheckedPluginsList', both in the parameter list and > in the sample, where it should use 'unCheckedPluginList' (note singular > 'Plugin'). > See > http://svn.apache.org/viewvc/maven/enforcer/tags/enforcer-1.0-beta-1/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequirePluginVersions.java?r1=729232&r2=746626&diff_format=h#l122 > for proof that the rule expects 'unCheckedPluginList'. -- 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
[jira] Commented: (MENFORCER-98) requirePluginVersions rule is not compatible with maven 3.0-beta-1
[ http://jira.codehaus.org/browse/MENFORCER-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=241242#action_241242 ] Brian Fox commented on MENFORCER-98: The warning is changed to info and the message is updated in 1.0 > requirePluginVersions rule is not compatible with maven 3.0-beta-1 > -- > > Key: MENFORCER-98 > URL: http://jira.codehaus.org/browse/MENFORCER-98 > Project: Maven 2.x Enforcer Plugin > Issue Type: Bug > Components: Standard Rules >Affects Versions: 1.0-beta-1 > Environment: Windows XP > Sun JDK 1.6.0_18 > Maven 3.0-beta-1 >Reporter: Anders Hammar > > When using the requirePluginVersions rule, I get a message saying "This rule > is not compatible with the current version of Maven. The rule is not able to > perform any checks." -- 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
[jira] Closed: (MENFORCER-105) requirePluginVersions rule doesn't work with POM named other than pom.xml
[ http://jira.codehaus.org/browse/MENFORCER-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MENFORCER-105. --- Resolution: Fixed Fix Version/s: 1.0 > requirePluginVersions rule doesn't work with POM named other than pom.xml > - > > Key: MENFORCER-105 > URL: http://jira.codehaus.org/browse/MENFORCER-105 > Project: Maven 2.x Enforcer Plugin > Issue Type: Bug > Components: Standard Rules >Affects Versions: 1.0-beta-2 > Environment: RH-EL 5, java 1.6.0_14, maven 2.2.1 >Reporter: Uriel Volovich > Fix For: 1.0 > > > My POM file have name NOT pom.xml. When I runs build enforcer failed with > exception: > org.apache.maven.enforcer.rule.api.EnforcerRuleException: Unable to download > the artifact from any repository > The stacktrace of the cause exception: > [DEBUG] Unable to locate resource in repository > org.apache.maven.wagon.ResourceDoesNotExistException: Unable to locate > resource in repository > at > org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:139) > at > org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116) > at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88) > at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61) > at > org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:546) > at > org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:427) > at > org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:382) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:216) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:90) > at > org.apache.maven.plugins.enforcer.utils.EnforcerRuleUtils.getPomModel(EnforcerRuleUtils.java:210) > at > org.apache.maven.plugins.enforcer.utils.EnforcerRuleUtils.getModelsRecursively(EnforcerRuleUtils.java:237) > at > org.apache.maven.plugins.enforcer.RequirePluginVersions.getAllPluginEntries(RequirePluginVersions.java:1014) > at > org.apache.maven.plugins.enforcer.RequirePluginVersions.execute(RequirePluginVersions.java:219) > at > org.apache.maven.plugins.enforcer.EnforceMojo.execute(EnforceMojo.java:185) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > ... > It seems, that bug in the file > "enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequirePluginVersions.java" > at line 1014: > List models = utils.getModelsRecursively( project.getGroupId(), > project.getArtifactId(), project.getVersion(), new File( > project.getBasedir(), "pom.xml" ) ); > POM name is hardcoded as "pom.xml"!!! So it should be replaced with: > List models = utils.getModelsRecursively( project.getGroupId(), > project.getArtifactId(), project.getVersion(), new File( > project.getBasedir(), project.getFile().getName() ) ); -- 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
[jira] Closed: (MENFORCER-107) An enforcer rule that demands developers ensure all dependency (and transitive dependency) version numbers converge
[ http://jira.codehaus.org/browse/MENFORCER-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MENFORCER-107. --- Resolution: Fixed Fix Version/s: 1.0-beta-2 Assignee: Brian Fox > An enforcer rule that demands developers ensure all dependency (and > transitive dependency) version numbers converge > --- > > Key: MENFORCER-107 > URL: http://jira.codehaus.org/browse/MENFORCER-107 > Project: Maven 2.x Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 1.0-beta-2 >Reporter: Rex Hoffman >Assignee: Brian Fox > Fix For: 1.0-beta-2 > > Attachments: noconflicts.tar.gz > > > Includes it cases. > Currently formatted as it's own maven project. No tricks used in the maven > compilation, so it should be trivial to merge. Copy the class and src/it > cases, though the dependencies will change slightly (don't hard code the > enforcer rule version) and remove the other dependency. > Included an apt page that explains the rule. Should also be be almost a cut > and past. Will have to do the same artifact fixes to the usage section. > Marked as major as there is no good existing workaround > Marking as a patch, because it's close. If you want me to prep it as a > straight patch, please point me to the best branch... > All probably between 15 and 30 minutes. -- 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
[jira] Closed: (MENFORCER-101) Enforcer does not allow to restrict based on SNAPSHOT version as version comparison uses artifact.getVersion() instead of artifact.getBaseVersion()
[
http://jira.codehaus.org/browse/MENFORCER-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MENFORCER-101.
---
Resolution: Fixed
Fix Version/s: 1.0-beta-2
> Enforcer does not allow to restrict based on SNAPSHOT version as version
> comparison uses artifact.getVersion() instead of artifact.getBaseVersion()
> ---
>
> Key: MENFORCER-101
> URL: http://jira.codehaus.org/browse/MENFORCER-101
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.0-beta-1
> Environment: Any
>Reporter: Prashant Bhate
> Fix For: 1.0-beta-2
>
>
> When following restriction is given to banned dependency rule, comparison
> fails as it compare with actual snapshot version in the repository (which
> includes timestamp 1.0-20100715.155142-18 ) instead of base version ( which
> has 1.0-SNAPSHOT )
> {code:xml}
>
>
>
> maven-enforcer-plugin
>
>
> enforce-snapshot-ver
>
> enforce
>
>
>
>
> true
>
> org.apache.maven.enforcer:enforcer-rules
>
>
>
> org.apache.maven.enforcer:enforcer-rules:[1.0-beta-2-SNAPSHOT]
>
>
>
> true
>
>
>
>
>
> ..
> ..
> ..
>
>
> org.apache.maven.enforcer
> enforcer-rules
> 1.0-beta-2-SNAPSHOT
>
>
> {code}
> See code snippet below
> {code:title=BannedDependencies.java|borderStyle=solid}
> try
> {
> result = AbstractVersionEnforcer.containsVersion(
> VersionRange.createFromVersionSpec( pattern[2] ),
> new DefaultArtifactVersion( artifact.getVersion() )
> );
> }
> catch ( InvalidVersionSpecificationException e )
> {
> throw new EnforcerRuleException( "Invalid Version Range: ", e );
> }
> {code}
> replace
> {code}
> new DefaultArtifactVersion( artifact.getVersion() )
> {code}
> with
> {code}
> new DefaultArtifactVersion( artifact.getBaseVersion() )
> {code}
> will solve this issue
--
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
