[jira] (SUREFIRE-957) XML report with Junit 4.7 or 4.11 does not include method names
[ https://jira.codehaus.org/browse/SUREFIRE-957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318452#comment-318452 ] Benson Margulies commented on SUREFIRE-957: --- Yes, I see the fix. > XML report with Junit 4.7 or 4.11 does not include method names > --- > > Key: SUREFIRE-957 > URL: https://jira.codehaus.org/browse/SUREFIRE-957 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support, xml generation >Affects Versions: 2.13 >Reporter: Benson Margulies > > The XML files that result from Junit have a series of elements. > Each names the class, each is a result of a method in the class, but the > method name is not anywhere in the XML. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-957) XML report with Junit 4.7 or 4.11 does not include method names
[ https://jira.codehaus.org/browse/SUREFIRE-957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-957. --- Resolution: Duplicate Fix Version/s: 2.14 Assignee: Kristian Rosenvold Duplicates SUREFIRE-943 > XML report with Junit 4.7 or 4.11 does not include method names > --- > > Key: SUREFIRE-957 > URL: https://jira.codehaus.org/browse/SUREFIRE-957 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support, xml generation >Affects Versions: 2.13 >Reporter: Benson Margulies >Assignee: Kristian Rosenvold > Fix For: 2.14 > > > The XML files that result from Junit have a series of elements. > Each names the class, each is a result of a method in the class, but the > method name is not anywhere in the XML. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPH-90) help:effective-pom does not show full effective-pom
[
https://jira.codehaus.org/browse/MPH-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318464#comment-318464
]
Michael Osipov commented on MPH-90:
---
I was referring to the JavaDoc of this class:
http://maven.apache.org/ref/2.0.11/maven-project/apidocs/org/apache/maven/project/MavenProject.html
I would add: Please note that configuration set through expressions are not
reflected in the configuration section and only if -X is called.
Something link. Folks should know that if they set maven.compiler.target = xxx
or anything expression-based it won't be written out ot the effective pom.
> help:effective-pom does not show full effective-pom
> ---
>
> Key: MPH-90
> URL: https://jira.codehaus.org/browse/MPH-90
> Project: Maven 2.x Help Plugin
> Issue Type: Bug
>Affects Versions: 2.1.1
> Environment: Maven 2.2.1 and Maven 3.0.3
>Reporter: Michael Osipov
>Assignee: Robert Scholte
> Attachments: compiler-debug.png, effective-pom.log, pom.xml,
> target-option.png
>
>
> When I define something like this in my POM:
> {code:xml}
>
> 1.6
> 1.6
>
> {code}
> the compiler plugin picks this up but this settings is not reflected in the
> {{Model}} and not written out as part of the effective POM.
> Either this is fixed within the system or the docs of this plugin need to
> mention this clearly.
> This is related to MJAVADOC-310 and MPIR-263.
> I a workaround for now by passing those properties to the plugin but this
> does not solve this problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (JXR-63) Bottom line in jxr report does not correspond to Javadoc style
[
https://jira.codehaus.org/browse/JXR-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated JXR-63:
Fix Version/s: 2.4
> Bottom line in jxr report does not correspond to Javadoc style
> --
>
> Key: JXR-63
> URL: https://jira.codehaus.org/browse/JXR-63
> Project: Maven JXR
> Issue Type: Bug
> Components: maven2 jxr plugin
>Affects Versions: 2.1
>Reporter: Michael Osipov
>Assignee: Olivier Lamy
> Fix For: 2.4
>
> Attachments: JXR-63.patch
>
>
> I user JXR with Maven and produce Javadoc too.
> I've set:
> 2004
> MyOrg
> http://www.somedomain.com
> What the JAvadoc plugin does for the javadoc report is, it creates a bottom
> line like this:
> {code}
> Copyright © 2004-2008 http://www.somedomain.com";>MyOrg. All
> Rights Reserved.
> {code}
> but what jxr produces is
> {code}
> Copyright © 2004-2008 MyOrg. All Rights Reserved.
> {code}
> Because JXR tries to resemble javadoc, this bottom line should produce the
> same ouput
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (JXR-63) Bottom line in jxr report does not correspond to Javadoc style
[
https://jira.codehaus.org/browse/JXR-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy reassigned JXR-63:
---
Assignee: Olivier Lamy
> Bottom line in jxr report does not correspond to Javadoc style
> --
>
> Key: JXR-63
> URL: https://jira.codehaus.org/browse/JXR-63
> Project: Maven JXR
> Issue Type: Bug
> Components: maven2 jxr plugin
>Affects Versions: 2.1
>Reporter: Michael Osipov
>Assignee: Olivier Lamy
> Fix For: 2.4
>
> Attachments: JXR-63.patch
>
>
> I user JXR with Maven and produce Javadoc too.
> I've set:
> 2004
> MyOrg
> http://www.somedomain.com
> What the JAvadoc plugin does for the javadoc report is, it creates a bottom
> line like this:
> {code}
> Copyright © 2004-2008 http://www.somedomain.com";>MyOrg. All
> Rights Reserved.
> {code}
> but what jxr produces is
> {code}
> Copyright © 2004-2008 MyOrg. All Rights Reserved.
> {code}
> Because JXR tries to resemble javadoc, this bottom line should produce the
> same ouput
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (JXR-63) Bottom line in jxr report does not correspond to Javadoc style
[
https://jira.codehaus.org/browse/JXR-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed JXR-63.
---
Resolution: Fixed
applied http://svn.apache.org/r1441356
Thanks !
> Bottom line in jxr report does not correspond to Javadoc style
> --
>
> Key: JXR-63
> URL: https://jira.codehaus.org/browse/JXR-63
> Project: Maven JXR
> Issue Type: Bug
> Components: maven2 jxr plugin
>Affects Versions: 2.1
>Reporter: Michael Osipov
>Assignee: Olivier Lamy
> Fix For: 2.4
>
> Attachments: JXR-63.patch
>
>
> I user JXR with Maven and produce Javadoc too.
> I've set:
> 2004
> MyOrg
> http://www.somedomain.com
> What the JAvadoc plugin does for the javadoc report is, it creates a bottom
> line like this:
> {code}
> Copyright © 2004-2008 http://www.somedomain.com";>MyOrg. All
> Rights Reserved.
> {code}
> but what jxr produces is
> {code}
> Copyright © 2004-2008 MyOrg. All Rights Reserved.
> {code}
> Because JXR tries to resemble javadoc, this bottom line should produce the
> same ouput
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (JXR-63) Bottom line in jxr report does not correspond to Javadoc style
[
https://jira.codehaus.org/browse/JXR-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318469#comment-318469
]
Michael Osipov commented on JXR-63:
---
Thanks you, looking forward for the next release.
> Bottom line in jxr report does not correspond to Javadoc style
> --
>
> Key: JXR-63
> URL: https://jira.codehaus.org/browse/JXR-63
> Project: Maven JXR
> Issue Type: Bug
> Components: maven2 jxr plugin
>Affects Versions: 2.1
>Reporter: Michael Osipov
>Assignee: Olivier Lamy
> Fix For: 2.4
>
> Attachments: JXR-63.patch
>
>
> I user JXR with Maven and produce Javadoc too.
> I've set:
> 2004
> MyOrg
> http://www.somedomain.com
> What the JAvadoc plugin does for the javadoc report is, it creates a bottom
> line like this:
> {code}
> Copyright © 2004-2008 http://www.somedomain.com";>MyOrg. All
> Rights Reserved.
> {code}
> but what jxr produces is
> {code}
> Copyright © 2004-2008 MyOrg. All Rights Reserved.
> {code}
> Because JXR tries to resemble javadoc, this bottom line should produce the
> same ouput
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (JXR-63) Bottom line in jxr report does not correspond to Javadoc style
[
https://jira.codehaus.org/browse/JXR-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318469#comment-318469
]
Michael Osipov edited comment on JXR-63 at 2/1/13 3:32 AM:
---
Thank you, looking forward for the next release.
was (Author: michael-o):
Thanks you, looking forward for the next release.
> Bottom line in jxr report does not correspond to Javadoc style
> --
>
> Key: JXR-63
> URL: https://jira.codehaus.org/browse/JXR-63
> Project: Maven JXR
> Issue Type: Bug
> Components: maven2 jxr plugin
>Affects Versions: 2.1
>Reporter: Michael Osipov
>Assignee: Olivier Lamy
> Fix For: 2.4
>
> Attachments: JXR-63.patch
>
>
> I user JXR with Maven and produce Javadoc too.
> I've set:
> 2004
> MyOrg
> http://www.somedomain.com
> What the JAvadoc plugin does for the javadoc report is, it creates a bottom
> line like this:
> {code}
> Copyright © 2004-2008 http://www.somedomain.com";>MyOrg. All
> Rights Reserved.
> {code}
> but what jxr produces is
> {code}
> Copyright © 2004-2008 MyOrg. All Rights Reserved.
> {code}
> Because JXR tries to resemble javadoc, this bottom line should produce the
> same ouput
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-358) Following mirror configuration from settings.xml
[
https://jira.codehaus.org/browse/ARCHETYPE-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anders Hammar reassigned ARCHETYPE-358:
---
Assignee: Anders Hammar
> Following mirror configuration from settings.xml
>
>
> Key: ARCHETYPE-358
> URL: https://jira.codehaus.org/browse/ARCHETYPE-358
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator, Plugin
>Affects Versions: 2.1
>Reporter: Grégory Joseph
>Assignee: Anders Hammar
> Fix For: 2.3
>
> Attachments: patch.txt
>
>
> It looks like the current snapshot of the plugin does not follow the mirror
> configuration from my settings.xml when I do {{mvn archetype:generate}}. I
> would expect it to grab the catalog from
> {{http://nexus.magnolia-cms.com/content/groups/all/archetype-catalog.xml}}
> instead of the central one.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MWAR-296) maven-war-plugin can cause multiple dependent lib files with same snapshot version.
[ https://jira.codehaus.org/browse/MWAR-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318472#comment-318472 ] Hayarobi Park edited comment on MWAR-296 at 2/1/13 4:32 AM: I added patch MWAR-296.patch that make targetName with baseVersion(eg. lib-0.1-SNAPSHOT.jar), not version (lib-0.1-20130101.01-1.jar) was (Author: hayarobipark): I add patch, that make targetName with baseVersion(eg. lib-0.1-SNAPSHOT.jar), not version (lib-0.1-20130101.01-1.jar) > maven-war-plugin can cause multiple dependent lib files with same snapshot > version. > --- > > Key: MWAR-296 > URL: https://jira.codehaus.org/browse/MWAR-296 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Hayarobi Park > Attachments: MWAR-296.patch > > > maven-war-plugin copies jar files of dependent artifacts to WEB-INF/lib > directory. with filename as is. It could make trouble when the version of > depenedent artifact is snapshot. > If the artifact was downloaded from remote repository, the jar filename in > local repository contains timestamp value. (eg. > deplib-1.0.0-20121220.074535-93.jar ) > If the artifact was built in workspace, the jar file in local repository > contains 'SNAPSHOT'. (eg. deplib-1.0.0-SNAPSHOT.jar ) > Guess multimodule project MyProject which has submodules modA and modWAR, > where modWAR is dependent to modA. > MyProject |-- modA > |-- modWAR > When I built just modWAR in my PC, maven (maybe war plugin) looks for > repository, and then find modA-0.1-20130101.074535-93.jar, copy this file to > WEB-INF/lib with same filename. > Then, I 'mvn install' upper moudule MyProject, the submodules will be built. > modA is built and copied to local repository with filename > modA-0.1-SNAPSHOT.jar, and war plugin will copy modA-0.1-SNAPSHOT.jar to > WEB-INF/lib when submodule modWAR is built. Now, there are two modA jar files > in WEB-INF/lib directory of modWAR; modA-0.1-20130101.074535-93.jar and > modA-0.1-SNAPSHOT.jar. > If co-work developer build modA and deploy next day in his PC, the lastest > snapshot file will look like modA-0.1-20130102.11-1.jar > I build modWAR without cleaning modWAR beforehand. maven will find newer > snapshot of modA, download it, and copy it to WEB-INF/lib without deleting > older snapshot version. There are three of modA jar files now. > This behavier is different from that of dependey-plugin. 'mvn > dependency:copy-dependencies' will copy files to target directory, changing > timestamp value of filename to 'SNAPSHOT'. There is duplicated dependent > library problem. > I think maven-war-plugin's copying behavier should be like dependent-plugin. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MWAR-296) maven-war-plugin can cause multiple dependent lib files with same snapshot version.
[ https://jira.codehaus.org/browse/MWAR-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318472#comment-318472 ] Hayarobi Park edited comment on MWAR-296 at 2/1/13 4:32 AM: I add patch, that make targetName with baseVersion(eg. lib-0.1-SNAPSHOT.jar), not version (lib-0.1-20130101.01-1.jar) was (Author: hayarobipark): copy targetName to baseVersion(eg. lib-0.1-SNAPSHOT.jar), not version (lib-0.1-20130101.01-1.jar) > maven-war-plugin can cause multiple dependent lib files with same snapshot > version. > --- > > Key: MWAR-296 > URL: https://jira.codehaus.org/browse/MWAR-296 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Hayarobi Park > Attachments: MWAR-296.patch > > > maven-war-plugin copies jar files of dependent artifacts to WEB-INF/lib > directory. with filename as is. It could make trouble when the version of > depenedent artifact is snapshot. > If the artifact was downloaded from remote repository, the jar filename in > local repository contains timestamp value. (eg. > deplib-1.0.0-20121220.074535-93.jar ) > If the artifact was built in workspace, the jar file in local repository > contains 'SNAPSHOT'. (eg. deplib-1.0.0-SNAPSHOT.jar ) > Guess multimodule project MyProject which has submodules modA and modWAR, > where modWAR is dependent to modA. > MyProject |-- modA > |-- modWAR > When I built just modWAR in my PC, maven (maybe war plugin) looks for > repository, and then find modA-0.1-20130101.074535-93.jar, copy this file to > WEB-INF/lib with same filename. > Then, I 'mvn install' upper moudule MyProject, the submodules will be built. > modA is built and copied to local repository with filename > modA-0.1-SNAPSHOT.jar, and war plugin will copy modA-0.1-SNAPSHOT.jar to > WEB-INF/lib when submodule modWAR is built. Now, there are two modA jar files > in WEB-INF/lib directory of modWAR; modA-0.1-20130101.074535-93.jar and > modA-0.1-SNAPSHOT.jar. > If co-work developer build modA and deploy next day in his PC, the lastest > snapshot file will look like modA-0.1-20130102.11-1.jar > I build modWAR without cleaning modWAR beforehand. maven will find newer > snapshot of modA, download it, and copy it to WEB-INF/lib without deleting > older snapshot version. There are three of modA jar files now. > This behavier is different from that of dependey-plugin. 'mvn > dependency:copy-dependencies' will copy files to target directory, changing > timestamp value of filename to 'SNAPSHOT'. There is duplicated dependent > library problem. > I think maven-war-plugin's copying behavier should be like dependent-plugin. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MWAR-296) maven-war-plugin can cause multiple dependent lib files with same snapshot version.
[ https://jira.codehaus.org/browse/MWAR-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hayarobi Park updated MWAR-296: --- Attachment: MWAR-296.patch copy targetName to baseVersion(eg. lib-0.1-SNAPSHOT.jar), not version (lib-0.1-20130101.01-1.jar) > maven-war-plugin can cause multiple dependent lib files with same snapshot > version. > --- > > Key: MWAR-296 > URL: https://jira.codehaus.org/browse/MWAR-296 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Hayarobi Park > Attachments: MWAR-296.patch > > > maven-war-plugin copies jar files of dependent artifacts to WEB-INF/lib > directory. with filename as is. It could make trouble when the version of > depenedent artifact is snapshot. > If the artifact was downloaded from remote repository, the jar filename in > local repository contains timestamp value. (eg. > deplib-1.0.0-20121220.074535-93.jar ) > If the artifact was built in workspace, the jar file in local repository > contains 'SNAPSHOT'. (eg. deplib-1.0.0-SNAPSHOT.jar ) > Guess multimodule project MyProject which has submodules modA and modWAR, > where modWAR is dependent to modA. > MyProject |-- modA > |-- modWAR > When I built just modWAR in my PC, maven (maybe war plugin) looks for > repository, and then find modA-0.1-20130101.074535-93.jar, copy this file to > WEB-INF/lib with same filename. > Then, I 'mvn install' upper moudule MyProject, the submodules will be built. > modA is built and copied to local repository with filename > modA-0.1-SNAPSHOT.jar, and war plugin will copy modA-0.1-SNAPSHOT.jar to > WEB-INF/lib when submodule modWAR is built. Now, there are two modA jar files > in WEB-INF/lib directory of modWAR; modA-0.1-20130101.074535-93.jar and > modA-0.1-SNAPSHOT.jar. > If co-work developer build modA and deploy next day in his PC, the lastest > snapshot file will look like modA-0.1-20130102.11-1.jar > I build modWAR without cleaning modWAR beforehand. maven will find newer > snapshot of modA, download it, and copy it to WEB-INF/lib without deleting > older snapshot version. There are three of modA jar files now. > This behavier is different from that of dependey-plugin. 'mvn > dependency:copy-dependencies' will copy files to target directory, changing > timestamp value of filename to 'SNAPSHOT'. There is duplicated dependent > library problem. > I think maven-war-plugin's copying behavier should be like dependent-plugin. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5185) Improve "missing dependency" error message when _maven.repositories conflict
[
https://jira.codehaus.org/browse/MNG-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier reopened MNG-5185:
--
Reopen as there is a discussion in progress about the proposed fix :
http://maven.40175.n5.nabble.com/Pain-with-MNG-5181-maven-repositories-td5743021.html
> Improve "missing dependency" error message when _maven.repositories conflict
>
>
> Key: MNG-5185
> URL: https://jira.codehaus.org/browse/MNG-5185
> Project: Maven 2 & 3
> Issue Type: Improvement
>Affects Versions: 3.0.2, 3.0.3, 3.0.4
>Reporter: Mark Derricutt
>Assignee: Olivier Lamy
> Fix For: 3.1.0
>
> Attachments:
> 0001-MNG-5185-Warn-about-artifacts-present-but-not-availa.patch
>
>
> Based on a discussion on the users list [1], Maven 3 has changed how it
> resolves artifacts from custom repositories. Unfortunately, when conflicts
> arise ( GAV is in local repo, but POM has no matching repository id declared
> ) Maven just tells the user that the artifact could not be resolved.
> This leads to confusion from users who find the .jar files in their local
> repository, and they just get frustrated and complain that "maven sucks".
> It would be good if Maven was updated with some improved error messages along
> the lines of:
> "The {GAV} artifact was found in your local repository, but came from the
> undeclared repository "xxx", either configure this in your pom with {insert
> sample XML block in error message}, or in your "yyy" mirror."
> The "mirror" section of the error message should be included -if- the current
> ~/.m2/settings.xml declares a mirror. By improving the messages here we can
> help the users move on to building software, rather than pulling out their
> hair :)
> [1]
> http://maven.40175.n5.nabble.com/Maven-3-maven-repositories-and-lastUpdated-td4927537.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-240) PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin
Martin Gainty created MPLUGIN-240: - Summary: PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin Key: MPLUGIN-240 URL: https://jira.codehaus.org/browse/MPLUGIN-240 Project: Maven 2.x Plugin Tools Issue Type: Bug Components: Metadata Model Environment: maven 3.0.2 modello-maven-plugin-1.5 Reporter: Martin Gainty -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-240) PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin
[
https://jira.codehaus.org/browse/MPLUGIN-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318476#comment-318476
]
Martin Gainty commented on MPLUGIN-240:
---
Test-harness
org.codehaus.modello
modello-maven-plugin
1.1
generate-sources
java
1.0.0
src/main/mdo/pluginRequirements.mdo
src/main/mdo/pluginRequirements.mdo
true
true
${project.build.directory}/generated-sources/modello
${project.build.sourceEncoding}
false
The error generated from test-harness:
org.codehaus.modello.maven.AbstractModelloGeneratorMojo
org.apache.maven.plugin.MojoExecutionException: Error generating: No such
plugin: java at
org.codehaus.modello.maven.AbstractModelloGeneratorMojo.doExecute(AbstractModelloGeneratorMojo.java:324)
plugin.xml contains:
Modello Maven Plugin
Modello Maven Plugin enables the use of Modello in Maven
builds.
org.codehaus.modello
modello-maven-plugin
1.1
modello
false
true
java
generates java sources from mdo
false
false
false
false
false
true
org.codehaus.modello.maven.ModelloJavaMojo
java
per-lookup
once-per-session
false
modelFile
java.lang.String
false
true
the model file
outputType
java.lang.String
true
true
Output type
outputDirectory
java.io.File
true
true
Output Directory
modelVersion
java.lang.String
true
true
version
packageWithVersion
java.lang.String
true
true
packgeWithVersion
useJava5
java.lang.String
true
true
useJava5
args
java.lang.String
false
true
model outputType output-directory modelVersion
packageWithVersion useJava5 encoding
${modelFile}
${outputType}
${outputDirectory}
${modelVersion}
${packageWithVersion}
${useJava5}
${args}
this is the class that the PluginManager locates..
Presumably because this is the only class which extends AbstractMojo
/**
* @author mailto:tryg...@inamo.no";>Trygve Laugstøl
* @version $Id$
* @threadSafe
*/
public abstract class AbstractModelloGeneratorMojo
extends org.apache.maven.plugin.AbstractMojo
{
public abstract void execute() {...}
}
//notice there is no @goal because this is an abstract class
//pluginManager does NOT use implementation class but backtraces to locate
//which class extends AbstractMojo
/*solution for plugin is to place all
functionality into concrete implementor
which contains @goal e.g. */
/*** Echos an object string to the output screen.
* @goal java
* @requiresProject false
@Mojo(name "java")
*/
public class ModelloJavaMojo extends AbstractMojo implements
org.codehaus.modello.core.ModelloCore
{ public void execute()
}
Questions or comments on why PluginManager is locating Abstract class which
extends AbstractMojo and not locating implementation Java class are eagerly
solicited
Martin
> PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin
> ---
>
> Key: MPLUGIN-240
> URL: https://jira.codehaus.org/browse/MPLUGIN-240
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: Metadata Model
> Environment: maven 3.0.2 modello-maven-plugin-1.5
>Reporter: Martin Gainty
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-240) PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin
[ https://jira.codehaus.org/browse/MPLUGIN-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318477#comment-318477 ] Stuart McCulloch commented on MPLUGIN-240: -- Please attach a zip of the test project that recreates the problem. Also note that the exception stack trace shows it is actually being thrown from shared code in AbstractModelloGeneratorMojo, not the plugin manager which suggests that mojo has been found and executed and the issue is actually something that happens during execution of the mojo. Do you have the complete stack trace available? > PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin > --- > > Key: MPLUGIN-240 > URL: https://jira.codehaus.org/browse/MPLUGIN-240 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Metadata Model > Environment: maven 3.0.2 modello-maven-plugin-1.5 >Reporter: Martin Gainty > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5185) Improve "missing dependency" error message when _maven.repositories conflict
[
https://jira.codehaus.org/browse/MNG-5185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318479#comment-318479
]
Jeff MAURY commented on MNG-5185:
-
The main problem with this "feature" is that it is not documented thus I
can't explain the real reason why Maven download several times released
artifacts and this causes members of the Maven bashing group to grow
See
http://maven.40175.n5.nabble.com/Pain-with-MNG-5181-maven-repositories-tp5743021p5745327.html
> Improve "missing dependency" error message when _maven.repositories conflict
>
>
> Key: MNG-5185
> URL: https://jira.codehaus.org/browse/MNG-5185
> Project: Maven 2 & 3
> Issue Type: Improvement
>Affects Versions: 3.0.2, 3.0.3, 3.0.4
>Reporter: Mark Derricutt
>Assignee: Olivier Lamy
> Fix For: 3.1.0
>
> Attachments:
> 0001-MNG-5185-Warn-about-artifacts-present-but-not-availa.patch
>
>
> Based on a discussion on the users list [1], Maven 3 has changed how it
> resolves artifacts from custom repositories. Unfortunately, when conflicts
> arise ( GAV is in local repo, but POM has no matching repository id declared
> ) Maven just tells the user that the artifact could not be resolved.
> This leads to confusion from users who find the .jar files in their local
> repository, and they just get frustrated and complain that "maven sucks".
> It would be good if Maven was updated with some improved error messages along
> the lines of:
> "The {GAV} artifact was found in your local repository, but came from the
> undeclared repository "xxx", either configure this in your pom with {insert
> sample XML block in error message}, or in your "yyy" mirror."
> The "mirror" section of the error message should be included -if- the current
> ~/.m2/settings.xml declares a mirror. By improving the messages here we can
> help the users move on to building software, rather than pulling out their
> hair :)
> [1]
> http://maven.40175.n5.nabble.com/Maven-3-maven-repositories-and-lastUpdated-td4927537.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-311) Basedir property in archetype:generate cannot be overriden
[ https://jira.codehaus.org/browse/ARCHETYPE-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318480#comment-318480 ] Anders Hammar commented on ARCHETYPE-311: - I can reproduce this with Maven 3.0.4 and version 2.2 of the plugin. It doesn't seem to be possible to override 'basedir'. Maybe renaming the param is the way to solve this? > Basedir property in archetype:generate cannot be overriden > -- > > Key: ARCHETYPE-311 > URL: https://jira.codehaus.org/browse/ARCHETYPE-311 > Project: Maven Archetype > Issue Type: Bug > Environment: Windows XP, maven 2.2.0 >Reporter: Samuli Saarinen > Attachments: patch.txt > > > Following is the output when trying to execute archetype:generate using > alternative directory for basedir > D:\tmp>mvn -o -npr archetype:generate *-Dbasedir=d:/foo* > > [INFO] > > [INFO] Using following parameters for creating OldArchetype: > maven-archetype-quickstart:RELEASE > [INFO] > > [INFO] Parameter: groupId, Value: test > [INFO] Parameter: packageName, Value: test > [INFO] Parameter: package, Value: test > [INFO] Parameter: artifactId, Value: test > [INFO] Parameter: basedir, Value: *D:\tmp* > [INFO] Parameter: version, Value: 1.0-SNAPSHOT > [INFO] * End of debug info from resources from generated > POM *** > [INFO] OldArchetype created in dir: D:\tmp\test > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 8 seconds > [INFO] Finished at: Fri Apr 16 10:53:06 EEST 2010 > [INFO] Final Memory: 10M/19M > [INFO] > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.
[
https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318481#comment-318481
]
Robert Scholte commented on MINSTALL-94:
What I don't like about the {{failIf}} option, is that when an artifact should
have been available the build should break, but by defining this option these
build-failures are ignored. So the best way would be to define it per module,
making it equivalent to the skip-parameter.
AFAIK you need to run {{package}} in order to run {{install}} or {{deploy}},
because that's when the jar/war/ear is bound to the {{MavenProject}}, so the
next goals know what to install or deploy.
If you want to confirm that the whole multimodule can be compiled, {{mvn
compile}} is enough with Maven3. For inner-multimodule dependencies the
classes-directory will be used instead of the jar.
Have you thought about the evil options {{maven.test.skip}} and {{skipTests}}?
> Optional: limit install to packaging x and or make install plugin not fail if
> no artifacts were created for some modules.
> -
>
> Key: MINSTALL-94
> URL: https://jira.codehaus.org/browse/MINSTALL-94
> Project: Maven 2.x Install Plugin
> Issue Type: Improvement
>Reporter: Henning Gross
> Attachments: MINSTALL-94.patch
>
>
> Background: I am working in a huge project with a lot of modules having a lot
> of javascript-optimization and stuff happening in lifecycle-steps after
> compile. This results in bad performance on jenkins. I would like to run
> mvn compile install:install as I only need the jars/libs to be installed and
> not the wars (and more important I do not need them to be built).
> Please introduce Parameters like
> war
> or
> false<...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.
[ https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318482#comment-318482 ] Henning Gross commented on MINSTALL-94: --- Someone at some point thought that the build should break on test failure as well. Someone did have a valid use-case and that when the option to not fail the build on test failure was added. Some time later (not long ago) surefire introduced another parameter to not fail if not tests werde found for a specified filter. Just to proof thath making behaviour configurable is not that uncommon. What you say about package seems to be true. I thought so before, then did a test run which succeeded and I did not question why. Maybe I simply forgot to run clean (me idiot). I just set up a test project and it was as expected and stated by you. The maven3-Feature you named does only work with direct dependencies I guess. I added a zip to demonstrate the issue. It will fail when running mvn clean test. Anyway. I was mistaken and you may close this issue. We need to find another way. Either by making sure that there are only direct inner-module-dependencies or by making sure that those libs are built independently. > Optional: limit install to packaging x and or make install plugin not fail if > no artifacts were created for some modules. > - > > Key: MINSTALL-94 > URL: https://jira.codehaus.org/browse/MINSTALL-94 > Project: Maven 2.x Install Plugin > Issue Type: Improvement >Reporter: Henning Gross > Attachments: MINSTALL-94.patch, MINSTALL-94.zip > > > Background: I am working in a huge project with a lot of modules having a lot > of javascript-optimization and stuff happening in lifecycle-steps after > compile. This results in bad performance on jenkins. I would like to run > mvn compile install:install as I only need the jars/libs to be installed and > not the wars (and more important I do not need them to be built). > Please introduce Parameters like > war > or > false<... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.
[ https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Gross updated MINSTALL-94: -- Attachment: MINSTALL-94.zip > Optional: limit install to packaging x and or make install plugin not fail if > no artifacts were created for some modules. > - > > Key: MINSTALL-94 > URL: https://jira.codehaus.org/browse/MINSTALL-94 > Project: Maven 2.x Install Plugin > Issue Type: Improvement >Reporter: Henning Gross > Attachments: MINSTALL-94.patch, MINSTALL-94.zip > > > Background: I am working in a huge project with a lot of modules having a lot > of javascript-optimization and stuff happening in lifecycle-steps after > compile. This results in bad performance on jenkins. I would like to run > mvn compile install:install as I only need the jars/libs to be installed and > not the wars (and more important I do not need them to be built). > Please introduce Parameters like > war > or > false<... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.
[ https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Gross updated MINSTALL-94: -- Attachment: MINSTALL-94.zip > Optional: limit install to packaging x and or make install plugin not fail if > no artifacts were created for some modules. > - > > Key: MINSTALL-94 > URL: https://jira.codehaus.org/browse/MINSTALL-94 > Project: Maven 2.x Install Plugin > Issue Type: Improvement >Reporter: Henning Gross > Attachments: MINSTALL-94.patch, MINSTALL-94.zip, MINSTALL-94.zip > > > Background: I am working in a huge project with a lot of modules having a lot > of javascript-optimization and stuff happening in lifecycle-steps after > compile. This results in bad performance on jenkins. I would like to run > mvn compile install:install as I only need the jars/libs to be installed and > not the wars (and more important I do not need them to be built). > Please introduce Parameters like > war > or > false<... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-949) Create forkCount parameter
[
https://jira.codehaus.org/browse/SUREFIRE-949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318483#comment-318483
]
Karl Pietrzak commented on SUREFIRE-949:
@[~agudian]: I like the idea of deprecating {{forkMode}} and instead using
{{fork}}, {{reuseForks}}, and {{forkCount}}. The use of thread and fork
vocabulary together was a tad confusing to the untrained eye.
> Create forkCount parameter
> --
>
> Key: SUREFIRE-949
> URL: https://jira.codehaus.org/browse/SUREFIRE-949
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Plugin
>Reporter: Kristian Rosenvold
>Assignee: Kristian Rosenvold
> Fix For: 2.14
>
>
> The "threadCount" parameter is overloaded to the extent that it is becoming
> problematic. A forkCount parameter would be nice, maybe supporting the same
> style as maven-core "1.5C" for 1.5 x number of cores.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPIR-260) No translation for report.dependency-info.* in several resource bundles
[ https://jira.codehaus.org/browse/MPIR-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thorsten Heit updated MPIR-260: --- Attachment: project-info-report_de.propertis.patch This patch provides German translations for the mentioned three missing property strings. > No translation for report.dependency-info.* in several resource bundles > --- > > Key: MPIR-260 > URL: https://jira.codehaus.org/browse/MPIR-260 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Bug > Components: dependency-info >Affects Versions: 2.5 > Environment: n/a >Reporter: Anders Hammar >Priority: Minor > Attachments: project-info-report_de.propertis.patch > > > Need to add the report.dependency-info.* props in several of the resource > bundles: > * de > * cs > * es > * gl > * hu > * it (lacking several other props as well) > * ja > * ko > * lt > * nl (lacking several other props as well) > * no > * pl (lacking some others as well) > * pt_BR > * pt > * ru > * sk > * sv > * tr > * zh_CN > * zh_TW > It's these props: > report.dependency-info.name > report.dependency-info.title > report.dependency-info.description -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.
[
https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MINSTALL-94.
--
Resolution: Won't Fix
Assignee: Robert Scholte
If you take a good look at the message, you should see that Maven is looking
for
{{MINSTALL-94:mi94-some-commons-module:jar:1.0-SNAPSHOT}}, but that project has
packaging-type {{pom}}, so no wonder it wasn't found. Removing the packaging
type makes the build succeed.
> Optional: limit install to packaging x and or make install plugin not fail if
> no artifacts were created for some modules.
> -
>
> Key: MINSTALL-94
> URL: https://jira.codehaus.org/browse/MINSTALL-94
> Project: Maven 2.x Install Plugin
> Issue Type: Improvement
>Reporter: Henning Gross
>Assignee: Robert Scholte
> Attachments: MINSTALL-94.patch, MINSTALL-94.zip, MINSTALL-94.zip
>
>
> Background: I am working in a huge project with a lot of modules having a lot
> of javascript-optimization and stuff happening in lifecycle-steps after
> compile. This results in bad performance on jenkins. I would like to run
> mvn compile install:install as I only need the jars/libs to be installed and
> not the wars (and more important I do not need them to be built).
> Please introduce Parameters like
> war
> or
> false<...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPIR-260) No translation for report.dependency-info.* in several resource bundles
[ https://jira.codehaus.org/browse/MPIR-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318488#comment-318488 ] Anders Hammar commented on MPIR-260: German translation patch applied in [r1441447|http://svn.apache.org/r1441447]. Thanks! > No translation for report.dependency-info.* in several resource bundles > --- > > Key: MPIR-260 > URL: https://jira.codehaus.org/browse/MPIR-260 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Bug > Components: dependency-info >Affects Versions: 2.5 > Environment: n/a >Reporter: Anders Hammar >Priority: Minor > Attachments: project-info-report_de.propertis.patch > > > Need to add the report.dependency-info.* props in several of the resource > bundles: > * de > * cs > * es > * gl > * hu > * it (lacking several other props as well) > * ja > * ko > * lt > * nl (lacking several other props as well) > * no > * pl (lacking some others as well) > * pt_BR > * pt > * ru > * sk > * sv > * tr > * zh_CN > * zh_TW > It's these props: > report.dependency-info.name > report.dependency-info.title > report.dependency-info.description -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.
[ https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318489#comment-318489 ] Henning Gross commented on MINSTALL-94: --- Actually I dont get the behaviour with the pom-packaging because the pom needs to be interpreted anyway. Feels like a bug to me. But has nothing to do with mvn-install. You have been a great help. Thank you. > Optional: limit install to packaging x and or make install plugin not fail if > no artifacts were created for some modules. > - > > Key: MINSTALL-94 > URL: https://jira.codehaus.org/browse/MINSTALL-94 > Project: Maven 2.x Install Plugin > Issue Type: Improvement >Reporter: Henning Gross >Assignee: Robert Scholte > Attachments: MINSTALL-94.patch, MINSTALL-94.zip, MINSTALL-94.zip > > > Background: I am working in a huge project with a lot of modules having a lot > of javascript-optimization and stuff happening in lifecycle-steps after > compile. This results in bad performance on jenkins. I would like to run > mvn compile install:install as I only need the jars/libs to be installed and > not the wars (and more important I do not need them to be built). > Please introduce Parameters like > war > or > false<... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-427) Archetype catalog should be retrieved from all defined remote repositories and not only central
Anders Hammar created ARCHETYPE-427: --- Summary: Archetype catalog should be retrieved from all defined remote repositories and not only central Key: ARCHETYPE-427 URL: https://jira.codehaus.org/browse/ARCHETYPE-427 Project: Maven Archetype Issue Type: Improvement Components: Generator Affects Versions: 2.2 Environment: n/a Reporter: Anders Hammar Instead of just retrieving the catalog from the central repo (hard-coded url), it should use all defined remote repositories (in settings.xml and possibly even an existing pom.xml). This is useful in a more advanced environment where there might be several repositories involved, which all could contain (different) archetype catalogs. On top of this, mirror, proxy, and authentication info from settings.xml should be honored. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-427) Archetype catalog should be retrieved from all defined remote repositories and not only central
[ https://jira.codehaus.org/browse/ARCHETYPE-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar reassigned ARCHETYPE-427: --- Assignee: Anders Hammar > Archetype catalog should be retrieved from all defined remote repositories > and not only central > --- > > Key: ARCHETYPE-427 > URL: https://jira.codehaus.org/browse/ARCHETYPE-427 > Project: Maven Archetype > Issue Type: Improvement > Components: Generator >Affects Versions: 2.2 > Environment: n/a >Reporter: Anders Hammar >Assignee: Anders Hammar > > Instead of just retrieving the catalog from the central repo (hard-coded > url), it should use all defined remote repositories (in settings.xml and > possibly even an existing pom.xml). This is useful in a more advanced > environment where there might be several repositories involved, which all > could contain (different) archetype catalogs. > On top of this, mirror, proxy, and authentication info from settings.xml > should be honored. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-358) Following mirror configuration from settings.xml
[
https://jira.codehaus.org/browse/ARCHETYPE-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318490#comment-318490
]
Anders Hammar commented on ARCHETYPE-358:
-
I've created ARCHETYPE-427 which is about changing the current behavior with
one hard-coded repo url.
> Following mirror configuration from settings.xml
>
>
> Key: ARCHETYPE-358
> URL: https://jira.codehaus.org/browse/ARCHETYPE-358
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator, Plugin
>Affects Versions: 2.1
>Reporter: Grégory Joseph
>Assignee: Anders Hammar
> Fix For: 2.3
>
> Attachments: patch.txt
>
>
> It looks like the current snapshot of the plugin does not follow the mirror
> configuration from my settings.xml when I do {{mvn archetype:generate}}. I
> would expect it to grab the catalog from
> {{http://nexus.magnolia-cms.com/content/groups/all/archetype-catalog.xml}}
> instead of the central one.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-334) Can not generate class-path from Manifest
[
https://jira.codehaus.org/browse/MASSEMBLY-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318491#comment-318491
]
Dmitry Katsubo commented on MASSEMBLY-334:
--
{{true}} does not work for me for v2.4.
> Can not generate class-path from Manifest
> -
>
> Key: MASSEMBLY-334
> URL: https://jira.codehaus.org/browse/MASSEMBLY-334
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Components: manifest
>Affects Versions: 2.2-beta-2
> Environment: Pc - Windows XP sp2
>Reporter: Damien
>
> I have a maven's projet multi-module.
> I have a problem when i launch mvn package assembly:assembly
> In the Manifest file, the class path does not generated.
> Pom project
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> com.ipsis.pacha
> Pacha
> pom
> 1.0-SNAPSHOT
> PACHA
>
>
>
>
>
> maven-antrun-plugin
>
>
>
> print-maven-runtime-classpath
> compile
>
>
>name="runtime-classpath"
>
> refid="maven.runtime.classpath" />
>
> message="maven.runtime.classpath=${runtime-classpath}" />
>
>
>
> run
>
>
>
>
> print-maven-test-classpath
> test-compile
>
>
>name="test-classpath"
>
> refid="maven.test.classpath" />
>
> message="maven.test.classpath=${test-classpath}" />
>
>
>
> run
>
>
>
>
>
>
> maven-compiler-plugin
>
>
> 1.6
> 1.6
> 512m
> 1024m
> true
> true
> true
>
> ${JAVA_HOME}\bin\javac.exe
> 1.6
>
>
>
>
>
> true
> maven-deploy-plugin
>
>
> true
>
>
>
>
> org.apache.maven.plugins
> maven-release-plugin
>
> deploy
>
>
>
>
> maven-surefire-plugin
>
>
>
> maven-eclipse-plugin
>
>
[jira] (MINSTALL-78) install:install should remove leftovers from local repository
[
https://jira.codehaus.org/browse/MINSTALL-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MINSTALL-78.
--
Resolution: Won't Fix
Assignee: Robert Scholte
I'd say this can be achieved with
[dependency:purge-local-repository|http://maven.apache.org/plugins/maven-dependency-plugin/purge-local-repository-mojo.html].
> install:install should remove leftovers from local repository
> -
>
> Key: MINSTALL-78
> URL: https://jira.codehaus.org/browse/MINSTALL-78
> Project: Maven 2.x Install Plugin
> Issue Type: Bug
> Components: install:install
>Affects Versions: 2.3.1
>Reporter: Petr Kozelka
>Assignee: Robert Scholte
> Attachments: pom.xml
>
>
> It sometimes happens that we need to change the set of output artifacts. When
> this happens, the install mojo does not bother to remove older artifacts that
> are no longer produced by this module.
> The bad effect is, that other modules depending on the obsolete artifacts can
> still use it - and later there comes a surprise.
> Much better behavior in this situation would be, to remove the obsolete files
> from the local repository's directory dedicated for given module.
> h4. reproducing the problem
> # download the sample pom to an empty directory
> # execute {{mvn clean install -Dc=obsolete-demo}} - this represents the
> "older version" of a module
> # execute {{mvn clean install}} - this represents the "newer version" of a
> module, after changing the classifier
> # now, look in the local repo using {{ls -1
> $HOME/.m2/repository/demo/sample-zip-module/1-SNAPSHOT}} - you will see this:
> {quote}
> maven-metadata-local.xml
> sample-zip-module-1-SNAPSHOT-demo.zip
> {color:red}sample-zip-module-1-SNAPSHOT-obsolete-demo.zip{color}
> sample-zip-module-1-SNAPSHOT.pom
> {quote}
> h4. possible solutions
> I see two approaches
> # *drop the installdir first* - straightforward
> # *list installdir, install, drop leftovers* - slightly more complicated but
> maximizes the time of installed module existence (if that matters)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-959) ArrayIndexOutOfBoundsException is thrown occasionally at the end of TestNG test
[ https://jira.codehaus.org/browse/SUREFIRE-959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318503#comment-318503 ] Julien Graglia commented on SUREFIRE-959: - I'm facing the same problem here with surefire 2.13 and JUnit 4.10. A successfull workaround is to downgrade surefire plugin to 2.12. > ArrayIndexOutOfBoundsException is thrown occasionally at the end of TestNG > test > > > Key: SUREFIRE-959 > URL: https://jira.codehaus.org/browse/SUREFIRE-959 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.13 >Reporter: Kobi Kisos > > java.lang.ArrayIndexOutOfBoundsException: 0 > at > org.apache.maven.surefire.report.SmartStackTraceParser.rootIsInclass(SmartStackTraceParser.java:176) > at > org.apache.maven.surefire.report.SmartStackTraceParser.getString(SmartStackTraceParser.java:131) > at > org.apache.maven.surefire.report.PojoStackTraceWriter.smartTrimmedStackTrace(PojoStackTraceWriter.java:61) > at > org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:328) > at > org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:312) > at > org.apache.maven.surefire.booter.ForkingRunListener.toString(ForkingRunListener.java:258) > at > org.apache.maven.surefire.booter.ForkingRunListener.testFailed(ForkingRunListener.java:137) > at > org.apache.maven.surefire.testng.TestNGReporter.onTestFailure(TestNGReporter.java:105) > at org.testng.internal.Invoker.runTestListeners(Invoker.java:1895) > at org.testng.internal.Invoker.runTestListeners(Invoker.java:1879) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:778) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > at > org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291) > at org.testng.SuiteRunner.run(SuiteRunner.java:240) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1198) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1123) > at org.testng.TestNG.run(TestNG.java:1031) > at > org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77) > at > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirectoryTestSuite.java:189) > at > org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:105) > at > org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:117) > 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.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) > at > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:158) > at > org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-386) build failure with jdk 1.7
[ https://jira.codehaus.org/browse/WAGON-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed WAGON-386. -- Resolution: Fixed Fix Version/s: 2.4 Assignee: Olivier Lamy > build failure with jdk 1.7 > -- > > Key: WAGON-386 > URL: https://jira.codehaus.org/browse/WAGON-386 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http, wagon-http-lightweight >Affects Versions: 2.4 > Environment: jdk 1.7 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.4 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-386) build failure with jdk 1.7
[ https://jira.codehaus.org/browse/WAGON-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318506#comment-318506 ] Oleg Kalnichevski commented on WAGON-386: - I am getting similar build failures with the latest master and JRE 7.0.07. Can these be related? --- Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Maven home: /opt/maven Java version: 1.7.0_07, vendor: Oracle Corporation Java home: /opt/oracle-jdk-1.7.0.07/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "3.5.0-22-generic", arch: "amd64", family: "unix" --- --- [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ wagon-http-lightweight --- [INFO] Surefire report directory: /home/oleg/src/apache.org/maven/maven-wagon/wagon-providers/wagon-http-lightweight/target/surefire-reports --- T E S T S --- Running org.apache.maven.wagon.providers.http.TckTest Tests run: 40, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 62.712 sec Running org.apache.maven.wagon.providers.http.LightweightHttpWagonTest Tests run: 52, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 16.288 sec Running org.apache.maven.wagon.providers.http.LightweightHttpsWagonTest Tests run: 52, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 17.023 sec <<< FAILURE! testStreamingWagon(org.apache.maven.wagon.providers.http.LightweightHttpsWagonTest) Time elapsed: 0.045 sec <<< FAILURE! junit.framework.AssertionFailedError: Unexpected method call transferProgress(TransferEvent[GET|PROGRESS|Repository[https://localhost:34892/]|null|test-resource[len = 18; mod = 1359741625000]], [B@239de86, 17): transferProgress(TransferEvent[GET|PROGRESS|Repository[https://localhost:34892/]|null|test-resource[len = 18; mod = 1359741625000]], [B@23bdce67, 0): expected: 1, actual: 2 at org.easymock.MockControl$4.invoke(MockControl.java:148) at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:44) at $Proxy12.transferProgress(Unknown Source) at org.apache.maven.wagon.events.TransferEventSupport.fireTransferProgress(TransferEventSupport.java:121) at org.apache.maven.wagon.AbstractWagon.fireTransferProgress(AbstractWagon.java:515) at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:500) at org.apache.maven.wagon.AbstractWagon.getTransfer(AbstractWagon.java:339) at org.apache.maven.wagon.StreamWagon.getIfNewerToStream(StreamWagon.java:227) at org.apache.maven.wagon.StreamWagon.getToStream(StreamWagon.java:242) at org.apache.maven.wagon.StreamingWagonTestCase.getStream(StreamingWagonTestCase.java:292) at org.apache.maven.wagon.StreamingWagonTestCase.streamRoundTripTesting(StreamingWagonTestCase.java:218) at org.apache.maven.wagon.StreamingWagonTestCase.testStreamingWagon(StreamingWagonTestCase.java:50) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:243) at junit.framework.TestSuite.run(TestSuite.java:238) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
[jira] (WAGON-386) build failure with jdk 1.7
[ https://jira.codehaus.org/browse/WAGON-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318511#comment-318511 ] Olivier Lamy commented on WAGON-386: similar fix apply here too. > build failure with jdk 1.7 > -- > > Key: WAGON-386 > URL: https://jira.codehaus.org/browse/WAGON-386 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http, wagon-http-lightweight >Affects Versions: 2.4 > Environment: jdk 1.7 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.4 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-386) build failure with jdk 1.7
[ https://jira.codehaus.org/browse/WAGON-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318516#comment-318516 ] Oleg Kalnichevski commented on WAGON-386: - Now webdav tests ;-) --- [INFO] Surefire report directory: /home/oleg/src/apache.org/maven/maven-wagon/wagon-providers/wagon-webdav-jackrabbit/target/surefire-reports --- T E S T S --- Running org.apache.maven.wagon.providers.webdav.WebDavWagonTest Tests run: 63, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 18.694 sec Running org.apache.maven.wagon.providers.webdav.PathNavigatorTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec Running org.apache.maven.wagon.providers.webdav.WebDavsWagonTest Tests run: 63, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 18.929 sec <<< FAILURE! testStreamingWagon(org.apache.maven.wagon.providers.webdav.WebDavsWagonTest) Time elapsed: 0.048 sec <<< FAILURE! junit.framework.AssertionFailedError: Unexpected method call transferProgress(TransferEvent[GET|PROGRESS|Repository[https://localhost:37816/newfolder/folder2/]|null|test-resource[len = 18; mod = 1359751683000]], [B@2b358b73, 17): transferProgress(TransferEvent[GET|PROGRESS|Repository[https://localhost:37816/newfolder/folder2/]|null|test-resource[len = 18; mod = 1359751683000]], [B@394047fa, 0): expected: 1, actual: 2 at org.easymock.MockControl$4.invoke(MockControl.java:148) at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:44) at $Proxy0.transferProgress(Unknown Source) at org.apache.maven.wagon.events.TransferEventSupport.fireTransferProgress(TransferEventSupport.java:121) at org.apache.maven.wagon.AbstractWagon.fireTransferProgress(AbstractWagon.java:515) at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:500) at org.apache.maven.wagon.AbstractWagon.getTransfer(AbstractWagon.java:339) at org.apache.maven.wagon.StreamWagon.getIfNewerToStream(StreamWagon.java:227) at org.apache.maven.wagon.StreamWagon.getToStream(StreamWagon.java:242) at org.apache.maven.wagon.StreamingWagonTestCase.getStream(StreamingWagonTestCase.java:292) at org.apache.maven.wagon.StreamingWagonTestCase.streamRoundTripTesting(StreamingWagonTestCase.java:218) at org.apache.maven.wagon.StreamingWagonTestCase.testStreamingWagon(StreamingWagonTestCase.java:50) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:243) at junit.framework.TestSuite.run(TestSuite.java:238) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) testWagonGetIfNewerToStreamIsOlder(org.apache.maven.wagon.providers.webdav.WebDavsWagonTest) Time elapsed: 0.062 sec <<< FAILURE! junit.framework.AssertionFailedError: Unexpected method call transferProgress(TransferEvent[GET|PROGRESS|Repository[https://localhost:45027/newfolder/folder2/]|null|test-resource[len = 18; mod = 1359751683000]], [B@6ed27650, 17)
[jira] (WAGON-386) build failure with jdk 1.7
[ https://jira.codehaus.org/browse/WAGON-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318517#comment-318517 ] Olivier Lamy commented on WAGON-386: *sigh* :-) must be better now. > build failure with jdk 1.7 > -- > > Key: WAGON-386 > URL: https://jira.codehaus.org/browse/WAGON-386 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http, wagon-http-lightweight >Affects Versions: 2.4 > Environment: jdk 1.7 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.4 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-386) build failure with jdk 1.7
[ https://jira.codehaus.org/browse/WAGON-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318518#comment-318518 ] Oleg Kalnichevski commented on WAGON-386: - All tests pass for me now. Many thanks. Oleg > build failure with jdk 1.7 > -- > > Key: WAGON-386 > URL: https://jira.codehaus.org/browse/WAGON-386 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http, wagon-http-lightweight >Affects Versions: 2.4 > Environment: jdk 1.7 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.4 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-387) Remove default easy ssl mode
[ https://jira.codehaus.org/browse/WAGON-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated WAGON-387: --- Fix Version/s: 2.4 Assignee: Olivier Lamy > Remove default easy ssl mode > > > Key: WAGON-387 > URL: https://jira.codehaus.org/browse/WAGON-387 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 2.2, 2.3 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.4 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-387) Remove default easy ssl mode
Olivier Lamy created WAGON-387: -- Summary: Remove default easy ssl mode Key: WAGON-387 URL: https://jira.codehaus.org/browse/WAGON-387 Project: Maven Wagon Issue Type: Bug Components: wagon-http Affects Versions: 2.3, 2.2 Reporter: Olivier Lamy -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-240) PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin
[ https://jira.codehaus.org/browse/MPLUGIN-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Gainty updated MPLUGIN-240: -- Attachment: pom.xml Attached pom.xml from commons-feedparser pluginmanager doesnt locate the plugin as the pluginmanaager looks only at classes from classpath which extend AbstractMojo the implementation from plugin.xml in next attachment is ignored to reproduce >mvn generate-sources > PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin > --- > > Key: MPLUGIN-240 > URL: https://jira.codehaus.org/browse/MPLUGIN-240 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Metadata Model > Environment: maven 3.0.2 modello-maven-plugin-1.5 >Reporter: Martin Gainty > Attachments: pom.xml > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-240) PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin
[ https://jira.codehaus.org/browse/MPLUGIN-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Gainty updated MPLUGIN-240: -- Attachment: plugin.xml maven-modello-plugin\target\classes\META-INF\maven\plugin.xml contains java.class implementation is ignored by pluginmanager > PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin > --- > > Key: MPLUGIN-240 > URL: https://jira.codehaus.org/browse/MPLUGIN-240 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Metadata Model > Environment: maven 3.0.2 modello-maven-plugin-1.5 >Reporter: Martin Gainty > Attachments: plugin.xml, pom.xml > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-240) PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin
[ https://jira.codehaus.org/browse/MPLUGIN-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Gainty updated MPLUGIN-240: -- Attachment: DumpScreenshot.jpg Screenshot of commons-feedparser PluginManager not able to locate @goal java in modello-maven-plugin > PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin > --- > > Key: MPLUGIN-240 > URL: https://jira.codehaus.org/browse/MPLUGIN-240 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Metadata Model > Environment: maven 3.0.2 modello-maven-plugin-1.5 >Reporter: Martin Gainty > Attachments: DumpScreenshot.jpg, plugin.xml, pom.xml > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-240) PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin
[
https://jira.codehaus.org/browse/MPLUGIN-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318522#comment-318522
]
Stuart McCulloch commented on MPLUGIN-240:
--
If I use 'mvn generate-sources' with that pom.xml I get the following error:
{code}
[ERROR] Failed to execute goal
org.codehaus.modello:modello-maven-plugin:1.1:java (default) on project
commons-feedparser: Couldn't find file.
/private/tmp/src/main/mdo/pluginRequirements.mdo (No such file or directory) ->
[Help 1]
{code}
I assume you have a modified version of the commons-feedparser project, if so
could you please upload a complete zip of your local project tree or point to
the relevant branch on svn, thanks.
> PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin
> ---
>
> Key: MPLUGIN-240
> URL: https://jira.codehaus.org/browse/MPLUGIN-240
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: Metadata Model
> Environment: maven 3.0.2 modello-maven-plugin-1.5
>Reporter: Martin Gainty
> Attachments: DumpScreenshot.jpg, plugin.xml, pom.xml
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-240) PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin
[
https://jira.codehaus.org/browse/MPLUGIN-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318522#comment-318522
]
Stuart McCulloch edited comment on MPLUGIN-240 at 2/1/13 6:33 PM:
--
If I use 'mvn generate-sources' with that pom.xml I get the following error
because it's looking for other files that weren't attached to this issue:
{code}
[ERROR] Failed to execute goal
org.codehaus.modello:modello-maven-plugin:1.1:java (default) on project
commons-feedparser: Couldn't find file.
/private/tmp/src/main/mdo/pluginRequirements.mdo (No such file or directory) ->
[Help 1]
{code}
I assume you have a modified version of the commons-feedparser project, if so
could you please upload a complete zip of your local project tree or point to
the relevant branch on svn, thanks. Basically I need to have the exact same
setup that you used with 'mvn generate-sources' to recreate this issue.
was (Author: mcculls):
If I use 'mvn generate-sources' with that pom.xml I get the following error:
{code}
[ERROR] Failed to execute goal
org.codehaus.modello:modello-maven-plugin:1.1:java (default) on project
commons-feedparser: Couldn't find file.
/private/tmp/src/main/mdo/pluginRequirements.mdo (No such file or directory) ->
[Help 1]
{code}
I assume you have a modified version of the commons-feedparser project, if so
could you please upload a complete zip of your local project tree or point to
the relevant branch on svn, thanks.
> PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin
> ---
>
> Key: MPLUGIN-240
> URL: https://jira.codehaus.org/browse/MPLUGIN-240
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: Metadata Model
> Environment: maven 3.0.2 modello-maven-plugin-1.5
>Reporter: Martin Gainty
> Attachments: DumpScreenshot.jpg, plugin.xml, pom.xml
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-240) PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin
[ https://jira.codehaus.org/browse/MPLUGIN-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318523#comment-318523 ] Stuart McCulloch commented on MPLUGIN-240: -- Also looking at that stacktrace it's actually failing to find the component with role=ModelloGenerator and hint=java (this lookup is made from inside modello code), which has nothing to do with the Maven plugin manager and AbstractMojo. It's just that modello uses the term 'plugin' in its error message which confuses the matter, while it's really just doing a simple Plexus lookup of a component. Now I can't say for sure why the lookup fails until I get that zip of your project tree, but looking at your pom.xml I see you've added the modello plugin as a dependency to various other Maven plugins (such as compiler and surefire). This doesn't seem right and could be messing up the classloader space causing the lookup failure (because they'll likely end up with a local copy of those classes rather than importing them). Try removing all those dependencies you've added directly to the compiler and surefire plugin configurations and see if that helps. > PluginManager cannot locate @goal in Abstract Class in modello-maven-plugin > --- > > Key: MPLUGIN-240 > URL: https://jira.codehaus.org/browse/MPLUGIN-240 > Project: Maven 2.x Plugin Tools > Issue Type: Bug > Components: Metadata Model > Environment: maven 3.0.2 modello-maven-plugin-1.5 >Reporter: Martin Gainty > Attachments: DumpScreenshot.jpg, plugin.xml, pom.xml > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
