[jira] Created: (MRELEASE-546) regression introduced in MRELEASE-261
regression introduced in MRELEASE-261
-
Key: MRELEASE-546
URL: http://jira.codehaus.org/browse/MRELEASE-546
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: perform
Affects Versions: 2.0
Reporter: nicolas de loof
Using hierachical projet structure, when the parent project is not first one in
the reactor, getCommonBasedir fails to detect the common basedir
{code}
public void
testGetCommonBasedirOfRegularMultiModuleRootNotBeeingFirstInReactor()
throws Exception
{
assertEquals( "/working/directory/flat-multi-module",
ReleaseUtil.getCommonBasedir( Arrays.asList(
new MavenProject[]{
createProject( "/working/directory/flat-multi-module/core" ),
createProject( "/working/directory/flat-multi-module" ),
createProject( "/working/directory/flat-multi-module/webapp" )}
), '/' ) );
}
{code}
--
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] Work started: (MRELEASE-546) regression introduced in MRELEASE-261
[
http://jira.codehaus.org/browse/MRELEASE-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MRELEASE-546 started by nicolas de loof.
> regression introduced in MRELEASE-261
> -
>
> Key: MRELEASE-546
> URL: http://jira.codehaus.org/browse/MRELEASE-546
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.0
>Reporter: nicolas de loof
>Assignee: nicolas de loof
>
> Using hierachical projet structure, when the parent project is not first one
> in the reactor, getCommonBasedir fails to detect the common basedir
> {code}
> public void
> testGetCommonBasedirOfRegularMultiModuleRootNotBeeingFirstInReactor()
> throws Exception
> {
> assertEquals( "/working/directory/flat-multi-module",
> ReleaseUtil.getCommonBasedir( Arrays.asList(
> new MavenProject[]{
> createProject( "/working/directory/flat-multi-module/core" ),
> createProject( "/working/directory/flat-multi-module" ),
> createProject( "/working/directory/flat-multi-module/webapp"
> )} ), '/' ) );
> }
> {code}
--
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: (MRELEASE-546) regression introduced in MRELEASE-261
[
http://jira.codehaus.org/browse/MRELEASE-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nicolas de loof closed MRELEASE-546.
Resolution: Fixed
Fix Version/s: 2.1
Committed at rev 933531.
> regression introduced in MRELEASE-261
> -
>
> Key: MRELEASE-546
> URL: http://jira.codehaus.org/browse/MRELEASE-546
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: perform
>Affects Versions: 2.0
>Reporter: nicolas de loof
>Assignee: nicolas de loof
> Fix For: 2.1
>
>
> Using hierachical projet structure, when the parent project is not first one
> in the reactor, getCommonBasedir fails to detect the common basedir
> {code}
> public void
> testGetCommonBasedirOfRegularMultiModuleRootNotBeeingFirstInReactor()
> throws Exception
> {
> assertEquals( "/working/directory/flat-multi-module",
> ReleaseUtil.getCommonBasedir( Arrays.asList(
> new MavenProject[]{
> createProject( "/working/directory/flat-multi-module/core" ),
> createProject( "/working/directory/flat-multi-module" ),
> createProject( "/working/directory/flat-multi-module/webapp"
> )} ), '/' ) );
> }
> {code}
--
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: (SUREFIRE-612) Create documentation on Junit providers
Create documentation on Junit providers --- Key: SUREFIRE-612 URL: http://jira.codehaus.org/browse/SUREFIRE-612 Project: Maven Surefire Issue Type: Improvement Components: JUnit 3.x support, Junit 4.x support Affects Versions: 2.5 Reporter: Kristian Rosenvold There are now three different junit providers in surefire, and there needs to be some high-level documentation explaining how these are selected and their similarity/differences. -- 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: (SUREFIRE-612) Create documentation on Junit providers
[ http://jira.codehaus.org/browse/SUREFIRE-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217747#action_217747 ] Kristian Rosenvold commented on SUREFIRE-612: - First version in r933530, may add some more info before closing > Create documentation on Junit providers > --- > > Key: SUREFIRE-612 > URL: http://jira.codehaus.org/browse/SUREFIRE-612 > Project: Maven Surefire > Issue Type: Improvement > Components: JUnit 3.x support, Junit 4.x support >Affects Versions: 2.5 >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > > There are now three different junit providers in surefire, and there needs to > be some high-level documentation explaining how these are selected and their > similarity/differences. -- 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] Issue Comment Edited: (SUREFIRE-612) Create documentation on Junit providers
[ http://jira.codehaus.org/browse/SUREFIRE-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217747#action_217747 ] Kristian Rosenvold edited comment on SUREFIRE-612 at 4/13/10 5:23 AM: -- First version in r933532, may add some more info before closing was (Author: krosenvold): First version in r933530, may add some more info before closing > Create documentation on Junit providers > --- > > Key: SUREFIRE-612 > URL: http://jira.codehaus.org/browse/SUREFIRE-612 > Project: Maven Surefire > Issue Type: Improvement > Components: JUnit 3.x support, Junit 4.x support >Affects Versions: 2.5 >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > > There are now three different junit providers in surefire, and there needs to > be some high-level documentation explaining how these are selected and their > similarity/differences. -- 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: (MWAR-221) Concurrency issue with XStream when running with parallel m3
Concurrency issue with XStream when running with parallel m3 Key: MWAR-221 URL: http://jira.codehaus.org/browse/MWAR-221 Project: Maven 2.x WAR Plugin Issue Type: Bug Reporter: Kristian Rosenvold XStream initialization is not thread safe, and concurrent use of the war plugin fails. -- 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: (MWAR-221) Concurrency issue with XStream when running with parallel m3
[ http://jira.codehaus.org/browse/MWAR-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MWAR-221. --- Resolution: Fixed Fix Version/s: 2.1-beta-2 Fixed in r933530 and r933534 > Concurrency issue with XStream when running with parallel m3 > > > Key: MWAR-221 > URL: http://jira.codehaus.org/browse/MWAR-221 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > Fix For: 2.1-beta-2 > > > XStream initialization is not thread safe, and concurrent use of the war > plugin fails. -- 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: (MNG-4632) Class loading is not thread-safe
Class loading is not thread-safe
Key: MNG-4632
URL: http://jira.codehaus.org/browse/MNG-4632
Project: Maven 2 & 3
Issue Type: Bug
Components: Class Loading
Affects Versions: 3.0-alpha-7
Reporter: Benjamin Bentmann
During his work on parallel build execution, Kristian Rosenvold discovered
{noformat}
Caused by: java.lang.LinkageError: loader (instance of
org/codehaus/plexus/classworlds/realm/ClassRealm): attempted duplicate class
definition for name: "antlr/TokenWithIndex"
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:386)
at
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
at antlr.Utils.loadClass(Utils.java:18)
at antlr.CharScanner.setTokenObjectClass(CharScanner.java:335)
at org.antlr.tool.Grammar.parseAndBuildAST(Grammar.java:608)
at org.antlr.Tool.getRootGrammar(Tool.java:612)
at
org.antlr.tool.BuildDependencyGenerator.(BuildDependencyGenerator.java:89)
at org.antlr.Tool.buildRequired(Tool.java:359)
at org.antlr.Tool.process(Tool.java:423)
at org.antlr.mojo.antlr3.Antlr3Mojo.execute(Antlr3Mojo.java:391)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105)
... 14 more
{noformat}
He also provided a patch for classworlds that was already applied
[r8689|http://fisheye.codehaus.org/changelog/plexus/?cs=8689].
--
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] Updated: (MNG-4632) Class loading is not thread-safe
[
http://jira.codehaus.org/browse/MNG-4632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4632:
---
Fix Version/s: 3.0-beta-1
> Class loading is not thread-safe
>
>
> Key: MNG-4632
> URL: http://jira.codehaus.org/browse/MNG-4632
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.0-alpha-7
>Reporter: Benjamin Bentmann
> Fix For: 3.0-beta-1
>
>
> During his work on parallel build execution, Kristian Rosenvold discovered
> {noformat}
> Caused by: java.lang.LinkageError: loader (instance of
> org/codehaus/plexus/classworlds/realm/ClassRealm): attempted duplicate class
> definition for name: "antlr/TokenWithIndex"
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
> at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:386)
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
> at antlr.Utils.loadClass(Utils.java:18)
> at antlr.CharScanner.setTokenObjectClass(CharScanner.java:335)
> at org.antlr.tool.Grammar.parseAndBuildAST(Grammar.java:608)
> at org.antlr.Tool.getRootGrammar(Tool.java:612)
> at
> org.antlr.tool.BuildDependencyGenerator.(BuildDependencyGenerator.java:89)
> at org.antlr.Tool.buildRequired(Tool.java:359)
> at org.antlr.Tool.process(Tool.java:423)
> at org.antlr.mojo.antlr3.Antlr3Mojo.execute(Antlr3Mojo.java:391)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105)
> ... 14 more
> {noformat}
> He also provided a patch for classworlds that was already applied
> [r8689|http://fisheye.codehaus.org/changelog/plexus/?cs=8689].
--
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] Updated: (MRELEASE-83) Wrong username during release:prepare tagging
[ http://jira.codehaus.org/browse/MRELEASE-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raphael Ackermann updated MRELEASE-83: -- Attachment: AbstractCvsCheckInCommand.java.patch The attached patch fixes this issue for me when using CVS (the all java cvs client) I get the same result that the first Login and also the update cvs commands work, but the checkin and tag commands won't work. As others have commented before, it uses the username defined in the CVS/Root file. Debugging the code I found out that it always checks the CVS/Root file, but if there is a -d option that takes precedence. -d cvs_root_directory Use cvs_root_directory as the root directory pathname of the reposi- tory. Overrides the setting of the $CVSROOT environment variable. See `Repository' in the CVS manual. A change in revision 518698 changed the behaviour to not include the -d option when generating the tag, checkin, update and branch cvs commands. The comment for that revision indicates that this was a problem for the update command. I think that maybe it should have only be changed for the update command while leaving the tag and checkin behaviour to include the -d option. See the comment for rev 518698 below: Revision: 518698 Author: evenisse Date: 3/15/07 6:17 PM Comment: Remove cvsroot from the command when it isn't needed. It fix some pb with update when files are updated only on the root directory and not detected. > Wrong username during release:prepare tagging > - > > Key: MRELEASE-83 > URL: http://jira.codehaus.org/browse/MRELEASE-83 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm >Reporter: Niclas Hedhman > Attachments: AbstractCvsCheckInCommand.java.patch > > > If I my Svn repository requires a different username than the login name, and > I issue >mvn -dmaven.username=nic...@hedhman.org release:prepare > The first phase (checking in modified POMs) will succeed with that username. > Then somewhere between that point and writing out the release.properties > file, the user name falls back to the login name (in my case "niclas"), which > is written into the release.properties file, and used during the tagging of > the repository. > Now, looking at the source, I think that is unwise to keep a username both in > the ReleaseProgressTracker as well as in the ScmHelper, and I suspect that > there is some type of sequencing problem in there. > WORKAROUND; > Before starting the release:prepare, create a release.properties file > manually which contains > maven.username=nic...@hedhman.org > and everything will work. -- 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: (WAGON-60) wagon-webdav fails with commons-logging classloader issues
[
http://jira.codehaus.org/browse/WAGON-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217786#action_217786
]
David Pilato commented on WAGON-60:
---
As Lorenzo said :
{quote}
We are having this problem with maven 2.2.1, wagon-webdav 1.0-beta-2,
maven-site-plugin:2.1 on mvn site:deploy.
Reverting to maven-site-plugin:2.0 worked around the issue.
{quote}
Same issue for me with maven 2.2.1 and maven-site-plugin:2.1.
Here is the context :
Multimodule project :
A : pom
B : jar
C : war
1) When I run mvn site from A, it works.
2) When I run mvn install from A, it works.
3) When I run mvn install site from A, it fails during the site phase for
module C.
4) When I run mvn install site from C, it works.
It seems that the classpath for the first test includes commons-logging 1.0.4
(or 1.0.6)
For the second test, it uses commons-logging 1.1.1
The third test add the two libs in classpath so it fails.
Is there a way to force maven to only use commons-logging 1.1.1 (for build,
plugins, dependencies, ...) ?
Thanks
> wagon-webdav fails with commons-logging classloader issues
> --
>
> Key: WAGON-60
> URL: http://jira.codehaus.org/browse/WAGON-60
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-webdav
>Affects Versions: 1.0-beta-1
> Environment: maven 2.0.4
>Reporter: Yuri Schimke
>Priority: Critical
>
> I tried it with a build extension and also putting jars in $M2_HOME/lib, but
> both ways I get classloader issues with commons-logging.
> My project uses commons logging and I've seen at least one other report that
> it can be a problem.
> with things in lib:
> Caused by: org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException: Invalid class loader
> hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by
> org.apache.commons.logging.LogConfigurationException: Invalid class loader
> hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.) (Caused by
> org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException: Invalid class loader
> hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by
> org.apache.commons.logging.LogConfigurationException: Invalid class loader
> hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.))
> at
> org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543)
> at
> org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
> at
> org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209)
> at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
> at
> org.apache.commons.httpclient.HttpClient.(HttpClient.java:69)
> ... 30 more
> Caused by: org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException: Invalid class loader
> hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by
> org.apache.commons.logging.LogConfigurationException: Invalid class loader
> hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.)
> at
> org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:397)
> at
> org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
> ... 34 more
> Caused by: org.apache.commons.logging.LogConfigurationException: Invalid
> class loader hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.
> at
> org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:385)
> using build extension:
> java.lang.ExceptionInInitializerError
> at
> org.apache.webdav.lib.WebdavSession.getSessionInstance(WebdavSession.java:145)
> at
> org.apache.webdav.lib.WebdavSession.getSessionInstance(WebdavSession.java:127)
> at
> org.apache.webdav.lib.WebdavResource.setClient(WebdavResource.java:1273)
> at
> org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1298)
> at
> org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1320)
> at
> org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1408)
> at
> org.apache.webdav.lib.WebdavResource.(WebdavResource.java
[jira] Created: (MRELEASE-547) Wrong version (2.0-beta-8) downloading from repo
Wrong version (2.0-beta-8) downloading from repo Key: MRELEASE-547 URL: http://jira.codehaus.org/browse/MRELEASE-547 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-8 Environment: Maven 2.2.1, Windows, Java 1.6 Reporter: Edward Staub (This probably isn't a problem with the plugin itself - but I'm not sure, and can't think where else to post.) When I try to run mvn release:update-versions I'm getting 2.0-beta-8, when I should get 2.0 according to both and in the metadata. The "update-versions" target isn't even in beta-8, so it blows up. I can't get the correct version of the release plugin to download from the the repository. I can't find any dependencies that point at beta-8 in my local repo. If I try to use the update-versions goal, I get the WRONG version. But if I run the help:describe target on the release plugin, it fetches the RIGHT version, 2.0. I haven't touched settings.xml. I get this behavior even in a directory with no POM, so I know it's not being trigger by something in the POM. -- 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] Issue Comment Edited: (WAGON-60) wagon-webdav fails with commons-logging classloader issues
[
http://jira.codehaus.org/browse/WAGON-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217786#action_217786
]
David Pilato edited comment on WAGON-60 at 4/13/10 10:40 AM:
-
As Lorenzo said :
{quote}
We are having this problem with maven 2.2.1, wagon-webdav 1.0-beta-2,
maven-site-plugin:2.1 on mvn site:deploy.
Reverting to maven-site-plugin:2.0 worked around the issue.
{quote}
Same issue for me with maven 2.2.1 and maven-site-plugin:2.1.
Here is the context :
Multimodule project :
A : pom
B : jar
C : war
1) When I run mvn site from A, it doesn't work.
2) When I run mvn install from A, it works.
3) When I run mvn install site from A, it fails during the site phase for
module C.
4) When I run mvn install site from C, it works.
It seems that the classpath for the first test includes commons-logging 1.0.4
(or 1.0.6) and commons-logging 1.1.1
For the second test, it uses only commons-logging 1.1.1
The third test add the two libs in classpath so it fails.
Is there a way to force maven to only use commons-logging 1.1.1 (for build,
plugins, dependencies, ...) ?
Thanks
was (Author: dpilato):
As Lorenzo said :
{quote}
We are having this problem with maven 2.2.1, wagon-webdav 1.0-beta-2,
maven-site-plugin:2.1 on mvn site:deploy.
Reverting to maven-site-plugin:2.0 worked around the issue.
{quote}
Same issue for me with maven 2.2.1 and maven-site-plugin:2.1.
Here is the context :
Multimodule project :
A : pom
B : jar
C : war
1) When I run mvn site from A, it works.
2) When I run mvn install from A, it works.
3) When I run mvn install site from A, it fails during the site phase for
module C.
4) When I run mvn install site from C, it works.
It seems that the classpath for the first test includes commons-logging 1.0.4
(or 1.0.6)
For the second test, it uses commons-logging 1.1.1
The third test add the two libs in classpath so it fails.
Is there a way to force maven to only use commons-logging 1.1.1 (for build,
plugins, dependencies, ...) ?
Thanks
> wagon-webdav fails with commons-logging classloader issues
> --
>
> Key: WAGON-60
> URL: http://jira.codehaus.org/browse/WAGON-60
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-webdav
>Affects Versions: 1.0-beta-1
> Environment: maven 2.0.4
>Reporter: Yuri Schimke
>Priority: Critical
>
> I tried it with a build extension and also putting jars in $M2_HOME/lib, but
> both ways I get classloader issues with commons-logging.
> My project uses commons logging and I've seen at least one other report that
> it can be a problem.
> with things in lib:
> Caused by: org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException: Invalid class loader
> hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by
> org.apache.commons.logging.LogConfigurationException: Invalid class loader
> hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.) (Caused by
> org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException: Invalid class loader
> hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by
> org.apache.commons.logging.LogConfigurationException: Invalid class loader
> hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.))
> at
> org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543)
> at
> org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
> at
> org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209)
> at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
> at
> org.apache.commons.httpclient.HttpClient.(HttpClient.java:69)
> ... 30 more
> Caused by: org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException: Invalid class loader
> hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by
> org.apache.commons.logging.LogConfigurationException: Invalid class loader
> hierarchy. You have more than one version of
> 'org.apache.commons.logging.Log' visible, which is not allowed.)
> at
> org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:397)
> at
> org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
> ... 34
[jira] Created: (MNGSITE-114) Standard Directory Layout does not mention NOTICE.txt
Standard Directory Layout does not mention NOTICE.txt - Key: MNGSITE-114 URL: http://jira.codehaus.org/browse/MNGSITE-114 Project: Maven 2 Project Web Site Issue Type: Bug Environment: http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html Reporter: SebbASF Priority: Minor http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html does not mention NOTICE.txt alongside LICENSE.txt. It would be helpful if it did. -- 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: (MRELEASE-547) Wrong version (2.0-beta-8) downloading from repo
[ http://jira.codehaus.org/browse/MRELEASE-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217805#action_217805 ] Dennis Lundberg commented on MRELEASE-547: -- Do you specify the maven-release-plugin version in your POM? If not - then you should. > Wrong version (2.0-beta-8) downloading from repo > > > Key: MRELEASE-547 > URL: http://jira.codehaus.org/browse/MRELEASE-547 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-8 > Environment: Maven 2.2.1, Windows, Java 1.6 >Reporter: Edward Staub > > (This probably isn't a problem with the plugin itself - but I'm not sure, and > can't think where else to post.) > When I try to run > mvn release:update-versions > I'm getting 2.0-beta-8, when I should get 2.0 according to both and > in the metadata. > The "update-versions" target isn't even in beta-8, so it blows up. > I can't get the correct version of the release plugin to download from the > the repository. > I can't find any dependencies that point at beta-8 in my local repo. > If I try to use the update-versions goal, I get the WRONG version. > But if I run the help:describe target on the release plugin, it fetches the > RIGHT version, 2.0. > I haven't touched settings.xml. > I get this behavior even in a directory with no POM, so I know it's not being > trigger by something in the POM. -- 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: (MRELEASE-547) Wrong version (2.0-beta-8) downloading from repo
[ http://jira.codehaus.org/browse/MRELEASE-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217810#action_217810 ] Edward Staub commented on MRELEASE-547: --- Sorry, you're right... I didn't RTFM well enough. But why does this plugin need special treatment? Or... why does it want to grab the wrong one? > Wrong version (2.0-beta-8) downloading from repo > > > Key: MRELEASE-547 > URL: http://jira.codehaus.org/browse/MRELEASE-547 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-8 > Environment: Maven 2.2.1, Windows, Java 1.6 >Reporter: Edward Staub > > (This probably isn't a problem with the plugin itself - but I'm not sure, and > can't think where else to post.) > When I try to run > mvn release:update-versions > I'm getting 2.0-beta-8, when I should get 2.0 according to both and > in the metadata. > The "update-versions" target isn't even in beta-8, so it blows up. > I can't get the correct version of the release plugin to download from the > the repository. > I can't find any dependencies that point at beta-8 in my local repo. > If I try to use the update-versions goal, I get the WRONG version. > But if I run the help:describe target on the release plugin, it fetches the > RIGHT version, 2.0. > I haven't touched settings.xml. > I get this behavior even in a directory with no POM, so I know it's not being > trigger by something in the POM. -- 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: (ARCHETYPE-295) When site archetypes (16,17) are built, the index file omits much of the generated output
When site archetypes (16,17) are built, the index file omits much of the generated output - Key: ARCHETYPE-295 URL: http://jira.codehaus.org/browse/ARCHETYPE-295 Project: Maven Archetype Issue Type: Bug Components: Generator Reporter: SebbASF Use mvn archetype:generate to build site (type 16) Run mvn site. The site home page that is created in target/site/index.html does not include any of the generated reports. Similarly for site type 17. -- 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: (ARCHETYPE-296) Non-ascii characters not handled correctly in French faq.html (generated from faq.fml)
Non-ascii characters not handled correctly in French faq.html (generated from faq.fml) -- Key: ARCHETYPE-296 URL: http://jira.codehaus.org/browse/ARCHETYPE-296 Project: Maven Archetype Issue Type: Bug Components: Generator Reporter: SebbASF Use mvn archetype:generate to create a site type 17. Most of the French pages are generated with the correct accents, but faq.html has "?" instead of "u-grave". Dunno whether this is a configuration problem or a plugin problem. -- 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: (SCM-546) release:perform pushes tag to origin rather than repository specified in POM
release:perform pushes tag to origin rather than repository specified in POM
Key: SCM-546
URL: http://jira.codehaus.org/browse/SCM-546
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-git
Affects Versions: 1.1
Environment: Maven 2.2.1, Windows 7
Reporter: Alex Anderson
The release:perform performs "git push" rather than "git push
http://example.com/repository";. This causes problems if the "origin" remote is
not the same as the scm.connection defined in the POM.
Here is my Maven output:
[INFO] Checking in modified POMs...
[INFO] Executing: cmd.exe /X /C "git add pom.xml"
[INFO] Working directory: c:\dev\workspace-32bit\jetpackager
[INFO] Executing: cmd.exe /X /C "git status"
[INFO] Working directory: c:\dev\workspace-32bit\jetpackager
[INFO] Executing: cmd.exe /X /C "git commit --verbose -F
C:\Users\aga\AppData\Local\Temp\maven-scm-2078623183.commit pom.xml"
[INFO] Working directory: c:\dev\workspace-32bit\jetpackager
[INFO] Executing: cmd.exe /X /C "git push"
[INFO] Working directory: c:\dev\workspace-32bit\jetpackager
[INFO] Tagging release with the label jetpackager-0.0.5...
[INFO] Executing: cmd.exe /X /C "git tag -F
C:\Users\aga\AppData\Local\Temp\maven-scm-1285436859.commit jetpackager-0.0.5"
[INFO] Working directory: c:\dev\workspace-32bit\jetpackager
[INFO] Executing: cmd.exe /X /C "git push origin jetpackager-0.0.5"
[INFO] Working directory: c:\dev\workspace-32bit\jetpackager
[INFO] Executing: cmd.exe /X /C "git ls-files"
[INFO] Working directory: c:\dev\workspace-32bit\jetpackager
[INFO] Transforming 'JetPackager'...
[INFO] Not removing release POMs
[INFO] Checking in modified POMs...
[INFO] Executing: cmd.exe /X /C "git add pom.xml"
[INFO] Working directory: c:\dev\workspace-32bit\jetpackager
[INFO] Executing: cmd.exe /X /C "git status"
[INFO] Working directory: c:\dev\workspace-32bit\jetpackager
[INFO] Executing: cmd.exe /X /C "git commit --verbose -F
C:\Users\aga\AppData\Local\Temp\maven-scm-882097787.commit pom.xml"
[INFO] Working directory: c:\dev\workspace-32bit\jetpackager
[INFO] Executing: cmd.exe /X /C "git push"
[INFO] Working directory: c:\dev\workspace-32bit\jetpackager
[INFO] Release preparation complete.
[INFO] [release:perform {execution: default-cli}]
[INFO] Checking out the project to perform the release ...
[INFO] Executing: cmd.exe /X /C "git clone
git://github.com/alexandergeorge/jetpackager-maven-plugin.git
c:\dev\workspace-32bit\jetpackager\target\checkout"
[INFO] Working directory: c:\dev\workspace-32bit\jetpackager\target
[INFO] Executing: cmd.exe /X /C "git pull
git://github.com/alexandergeorge/jetpackager-maven-plugin.git tag
jetpackager-0.0.5"
[INFO] Working directory: c:\dev\workspace-32bit\jetpackager\target\checkout
[ERROR] The git-pull command failed.
[INFO]
[ERROR] BUILD FAILURE
[INFO]
And here is my pom.xml:
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schem
http://maven.apache.org/maven-v4_0_0.xsd";>
...
scm:git:git://g...@github.com/alexandergeorge/jetpackager-maven-plugin.git
...
--
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: (MNG-4632) Class loading is not thread-safe
[
http://jira.codehaus.org/browse/MNG-4632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed MNG-4632.
---
Resolution: Fixed
Fixed in r933714
Fixed problem where ClassWorld was missing a synchronized.
Also code-reviewed synchronization in ClassWorld vs ClassLoader and discovered
no other problems.
> Class loading is not thread-safe
>
>
> Key: MNG-4632
> URL: http://jira.codehaus.org/browse/MNG-4632
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.0-alpha-7
>Reporter: Benjamin Bentmann
> Fix For: 3.0-beta-1
>
>
> During his work on parallel build execution, Kristian Rosenvold discovered
> {noformat}
> Caused by: java.lang.LinkageError: loader (instance of
> org/codehaus/plexus/classworlds/realm/ClassRealm): attempted duplicate class
> definition for name: "antlr/TokenWithIndex"
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
> at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:386)
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
> at antlr.Utils.loadClass(Utils.java:18)
> at antlr.CharScanner.setTokenObjectClass(CharScanner.java:335)
> at org.antlr.tool.Grammar.parseAndBuildAST(Grammar.java:608)
> at org.antlr.Tool.getRootGrammar(Tool.java:612)
> at
> org.antlr.tool.BuildDependencyGenerator.(BuildDependencyGenerator.java:89)
> at org.antlr.Tool.buildRequired(Tool.java:359)
> at org.antlr.Tool.process(Tool.java:423)
> at org.antlr.mojo.antlr3.Antlr3Mojo.execute(Antlr3Mojo.java:391)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105)
> ... 14 more
> {noformat}
> He also provided a patch for classworlds that was already applied
> [r8689|http://fisheye.codehaus.org/changelog/plexus/?cs=8689].
--
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] Updated: (MNG-4632) Class loading is not thread-safe
[
http://jira.codehaus.org/browse/MNG-4632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4632:
---
Assignee: Kristian Rosenvold
> Class loading is not thread-safe
>
>
> Key: MNG-4632
> URL: http://jira.codehaus.org/browse/MNG-4632
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.0-alpha-7
>Reporter: Benjamin Bentmann
>Assignee: Kristian Rosenvold
> Fix For: 3.0-beta-1
>
>
> During his work on parallel build execution, Kristian Rosenvold discovered
> {noformat}
> Caused by: java.lang.LinkageError: loader (instance of
> org/codehaus/plexus/classworlds/realm/ClassRealm): attempted duplicate class
> definition for name: "antlr/TokenWithIndex"
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
> at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:386)
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
> at antlr.Utils.loadClass(Utils.java:18)
> at antlr.CharScanner.setTokenObjectClass(CharScanner.java:335)
> at org.antlr.tool.Grammar.parseAndBuildAST(Grammar.java:608)
> at org.antlr.Tool.getRootGrammar(Tool.java:612)
> at
> org.antlr.tool.BuildDependencyGenerator.(BuildDependencyGenerator.java:89)
> at org.antlr.Tool.buildRequired(Tool.java:359)
> at org.antlr.Tool.process(Tool.java:423)
> at org.antlr.mojo.antlr3.Antlr3Mojo.execute(Antlr3Mojo.java:391)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105)
> ... 14 more
> {noformat}
> He also provided a patch for classworlds that was already applied
> [r8689|http://fisheye.codehaus.org/changelog/plexus/?cs=8689].
--
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: (SCM-546) release:perform pushes tag to origin rather than repository specified in POM
[
http://jira.codehaus.org/browse/SCM-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217816#action_217816
]
Alex Anderson commented on SCM-546:
---
Looks like this is working in version 1.3; sorry for wasting your time.
> release:perform pushes tag to origin rather than repository specified in POM
>
>
> Key: SCM-546
> URL: http://jira.codehaus.org/browse/SCM-546
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.1
> Environment: Maven 2.2.1, Windows 7
>Reporter: Alex Anderson
> Fix For: 1.3
>
>
> The release:perform performs "git push" rather than "git push
> http://example.com/repository";. This causes problems if the "origin" remote
> is not the same as the scm.connection defined in the POM.
> Here is my Maven output:
> [INFO] Checking in modified POMs...
> [INFO] Executing: cmd.exe /X /C "git add pom.xml"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager
> [INFO] Executing: cmd.exe /X /C "git status"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager
> [INFO] Executing: cmd.exe /X /C "git commit --verbose -F
> C:\Users\aga\AppData\Local\Temp\maven-scm-2078623183.commit pom.xml"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager
> [INFO] Executing: cmd.exe /X /C "git push"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager
> [INFO] Tagging release with the label jetpackager-0.0.5...
> [INFO] Executing: cmd.exe /X /C "git tag -F
> C:\Users\aga\AppData\Local\Temp\maven-scm-1285436859.commit jetpackager-0.0.5"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager
> [INFO] Executing: cmd.exe /X /C "git push origin jetpackager-0.0.5"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager
> [INFO] Executing: cmd.exe /X /C "git ls-files"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager
> [INFO] Transforming 'JetPackager'...
> [INFO] Not removing release POMs
> [INFO] Checking in modified POMs...
> [INFO] Executing: cmd.exe /X /C "git add pom.xml"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager
> [INFO] Executing: cmd.exe /X /C "git status"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager
> [INFO] Executing: cmd.exe /X /C "git commit --verbose -F
> C:\Users\aga\AppData\Local\Temp\maven-scm-882097787.commit pom.xml"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager
> [INFO] Executing: cmd.exe /X /C "git push"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager
> [INFO] Release preparation complete.
> [INFO] [release:perform {execution: default-cli}]
> [INFO] Checking out the project to perform the release ...
> [INFO] Executing: cmd.exe /X /C "git clone
> git://github.com/alexandergeorge/jetpackager-maven-plugin.git
> c:\dev\workspace-32bit\jetpackager\target\checkout"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager\target
> [INFO] Executing: cmd.exe /X /C "git pull
> git://github.com/alexandergeorge/jetpackager-maven-plugin.git tag
> jetpackager-0.0.5"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager\target\checkout
> [ERROR] The git-pull command failed.
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> And here is my pom.xml:
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schem
> http://maven.apache.org/maven-v4_0_0.xsd";>
> ...
>
>
> scm:git:git://g...@github.com/alexandergeorge/jetpackager-maven-plugin.git
>
> ...
>
--
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: (SCM-546) release:perform pushes tag to origin rather than repository specified in POM
[
http://jira.codehaus.org/browse/SCM-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Anderson closed SCM-546.
-
Resolution: Fixed
Fix Version/s: 1.3
> release:perform pushes tag to origin rather than repository specified in POM
>
>
> Key: SCM-546
> URL: http://jira.codehaus.org/browse/SCM-546
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-git
>Affects Versions: 1.1
> Environment: Maven 2.2.1, Windows 7
>Reporter: Alex Anderson
> Fix For: 1.3
>
>
> The release:perform performs "git push" rather than "git push
> http://example.com/repository";. This causes problems if the "origin" remote
> is not the same as the scm.connection defined in the POM.
> Here is my Maven output:
> [INFO] Checking in modified POMs...
> [INFO] Executing: cmd.exe /X /C "git add pom.xml"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager
> [INFO] Executing: cmd.exe /X /C "git status"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager
> [INFO] Executing: cmd.exe /X /C "git commit --verbose -F
> C:\Users\aga\AppData\Local\Temp\maven-scm-2078623183.commit pom.xml"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager
> [INFO] Executing: cmd.exe /X /C "git push"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager
> [INFO] Tagging release with the label jetpackager-0.0.5...
> [INFO] Executing: cmd.exe /X /C "git tag -F
> C:\Users\aga\AppData\Local\Temp\maven-scm-1285436859.commit jetpackager-0.0.5"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager
> [INFO] Executing: cmd.exe /X /C "git push origin jetpackager-0.0.5"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager
> [INFO] Executing: cmd.exe /X /C "git ls-files"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager
> [INFO] Transforming 'JetPackager'...
> [INFO] Not removing release POMs
> [INFO] Checking in modified POMs...
> [INFO] Executing: cmd.exe /X /C "git add pom.xml"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager
> [INFO] Executing: cmd.exe /X /C "git status"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager
> [INFO] Executing: cmd.exe /X /C "git commit --verbose -F
> C:\Users\aga\AppData\Local\Temp\maven-scm-882097787.commit pom.xml"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager
> [INFO] Executing: cmd.exe /X /C "git push"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager
> [INFO] Release preparation complete.
> [INFO] [release:perform {execution: default-cli}]
> [INFO] Checking out the project to perform the release ...
> [INFO] Executing: cmd.exe /X /C "git clone
> git://github.com/alexandergeorge/jetpackager-maven-plugin.git
> c:\dev\workspace-32bit\jetpackager\target\checkout"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager\target
> [INFO] Executing: cmd.exe /X /C "git pull
> git://github.com/alexandergeorge/jetpackager-maven-plugin.git tag
> jetpackager-0.0.5"
> [INFO] Working directory: c:\dev\workspace-32bit\jetpackager\target\checkout
> [ERROR] The git-pull command failed.
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> And here is my pom.xml:
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schem
> http://maven.apache.org/maven-v4_0_0.xsd";>
> ...
>
>
> scm:git:git://g...@github.com/alexandergeorge/jetpackager-maven-plugin.git
>
> ...
>
--
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] Issue Comment Edited: (MNG-4632) Class loading is not thread-safe
[
http://jira.codehaus.org/browse/MNG-4632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217813#action_217813
]
Kristian Rosenvold edited comment on MNG-4632 at 4/13/10 12:54 PM:
---
Fixed in r933714
Fixed problem where ClassRealm was missing a synchronized.
Also code-reviewed synchronization in ClassRealm vs ClassLoader and discovered
no other problems.
was (Author: krosenvold):
Fixed in r933714
Fixed problem where ClassWorld was missing a synchronized.
Also code-reviewed synchronization in ClassWorld vs ClassLoader and discovered
no other problems.
> Class loading is not thread-safe
>
>
> Key: MNG-4632
> URL: http://jira.codehaus.org/browse/MNG-4632
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.0-alpha-7
>Reporter: Benjamin Bentmann
>Assignee: Kristian Rosenvold
> Fix For: 3.0-beta-1
>
>
> During his work on parallel build execution, Kristian Rosenvold discovered
> {noformat}
> Caused by: java.lang.LinkageError: loader (instance of
> org/codehaus/plexus/classworlds/realm/ClassRealm): attempted duplicate class
> definition for name: "antlr/TokenWithIndex"
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
> at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:386)
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
> at antlr.Utils.loadClass(Utils.java:18)
> at antlr.CharScanner.setTokenObjectClass(CharScanner.java:335)
> at org.antlr.tool.Grammar.parseAndBuildAST(Grammar.java:608)
> at org.antlr.Tool.getRootGrammar(Tool.java:612)
> at
> org.antlr.tool.BuildDependencyGenerator.(BuildDependencyGenerator.java:89)
> at org.antlr.Tool.buildRequired(Tool.java:359)
> at org.antlr.Tool.process(Tool.java:423)
> at org.antlr.mojo.antlr3.Antlr3Mojo.execute(Antlr3Mojo.java:391)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105)
> ... 14 more
> {noformat}
> He also provided a patch for classworlds that was already applied
> [r8689|http://fisheye.codehaus.org/changelog/plexus/?cs=8689].
--
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: (MNG-4633) Make weave mode work reliably
Make weave mode work reliably - Key: MNG-4633 URL: http://jira.codehaus.org/browse/MNG-4633 Project: Maven 2 & 3 Issue Type: Improvement Affects Versions: 3.0-beta-1 Reporter: Kristian Rosenvold m3 trunk currently contains two different concurrent-build implementations; parallel and weave. The main target for m3 is for production quality "parallel" to be ready; there are numerous plugins that will need to adjust to this functionality. Alongside this activity weave mode will also be fine-tuned and evaluated; due to the generally tighter concurrency in this model, weave mode is more likely to reveal concurrency related issues in both maven, plugins, libraries and the jdk. This task is used to collect all commits related to making weave mode work reliably. The final evaluation of weave mode will be taken at a later stage. In the event that Weave mode is to be abandoned, the class LifecycleWeaveBuilder contains instructions on how/what can be removed from m3 core. -- 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] Work started: (MNG-4633) Make weave mode work reliably
[ http://jira.codehaus.org/browse/MNG-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MNG-4633 started by Kristian Rosenvold. > Make weave mode work reliably > - > > Key: MNG-4633 > URL: http://jira.codehaus.org/browse/MNG-4633 > Project: Maven 2 & 3 > Issue Type: Improvement >Affects Versions: 3.0-beta-1 >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > > m3 trunk currently contains two different concurrent-build implementations; > parallel and weave. The main target for m3 is for production quality > "parallel" to be ready; there are numerous plugins that will need to adjust > to this functionality. > Alongside this activity weave mode will also be fine-tuned and evaluated; due > to the generally tighter concurrency in this model, weave mode is more likely > to reveal concurrency related issues in both maven, plugins, libraries and > the jdk. > This task is used to collect all commits related to making weave mode work > reliably. The final evaluation of weave mode will be taken at a later stage. > In the event that Weave mode is to be abandoned, the class > LifecycleWeaveBuilder contains instructions on how/what can be removed from > m3 core. -- 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: (MJAVADOC-275) Creation of Javadoc attachments fails in multi-module project where modules have never been installed/deployed
[
http://jira.codehaus.org/browse/MJAVADOC-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MJAVADOC-275.
---
Resolution: Fixed
Fix Version/s: 2.7
> Creation of Javadoc attachments fails in multi-module project where modules
> have never been installed/deployed
> --
>
> Key: MJAVADOC-275
> URL: http://jira.codehaus.org/browse/MJAVADOC-275
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.6.1
>Reporter: Benjamin Bentmann
>Assignee: John Casey
>Priority: Critical
> Fix For: 2.7
>
> Attachments: MJAVADOC-275.zip
>
>
> Running the commands
> {noformat}
> mvn clean
> mvn verify
> {noformat}
> will fail on the attached demo project with
> {noformat}
> [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.6.1:javadoc'
> has not be previously called for the project:
> 'org.apache.maven.its.javadoc:mod-b:jar:0.1'.
> Trying to invoke it...
> [ERROR] MavenInvocationException: Error when invoking Maven, consult the
> invoker log file:
> M:\MJAVADOC\mod-a\target\invoker\maven-javadoc-plugin625147587.txt
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] MavenReportException: Error while creating archive:
> Error when invoking Maven, consult the invoker log file:
> M:\MJAVADOC\mod-a\target\invoker\maven-javadoc-plugin625147587.txt
> {noformat}
> The command {{mvn clean verify}} as usually used during releases will also
> fail, but starts working after repeated invocations.
--
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: (MJAVADOC-276) Initial builds of a multi-module project fail
[
http://jira.codehaus.org/browse/MJAVADOC-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MJAVADOC-276.
---
Resolution: Duplicate
Fix Version/s: 2.7
Assignee: John Casey
Duplicates MJAVADOC-275
> Initial builds of a multi-module project fail
> -
>
> Key: MJAVADOC-276
> URL: http://jira.codehaus.org/browse/MJAVADOC-276
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.6.1
> Environment: Java jdk1.6.0_16, Maven 2.2.1, Windows Vista 64-bit
> Java jdk1.6.0_05, Maven 2.0.9, Windows XP 32-bit
>Reporter: Anthony Whitford
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.7
>
> Attachments: bug.zip
>
>
> I ran into a problem using Maven Javadoc Plugin 2.6.1 right after I
> released... I went from version 1.15 to 1.16-SNAPSHOT, and my 1.16-SNAPSHOT
> build failed ({{mvn clean install site}}) because Javadoc fails when run from
> the top-level parent. When it is building _module A_, the javadoc complains
> that _module B_ and _module C_ are missing -- of course they are, they
> haven't been built yet. Note that running {{mvn clean install}} from _module
> A_ works fine -- the behavior is limited to running from the top-level parent
> -- AND, if you run a {{mvn install}} for _module B_ and _module C_, then you
> have given it what it needs and so you won't see the error.
> The attached example exhibits the problem. It was created from the
> _j2ee-simple_ archetype -- I only added the explicit javadoc plugin
> declaration to the top level pom to control the version being used. To
> recreate the problem, unzip and simply: {{mvn clean install site}}. You
> will get an error message like:
> {noformat}
> [INFO] Unable to find resource 'root.project.projects:logging:jar:1.0' in
> repository central (http://repo1.maven.org/maven2)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) root.project.projects:logging:jar:1.0
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=root.project.projects
> -DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file -DgroupId=root.project.projects
> -DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
> -Durl=[url] -DrepositoryId=
> [id]
> Path to dependency:
> 1) root.project:primary-source:jar:1.0
> 2) root.project.projects:logging:jar:1.0
> --
> 1 required artifact is missing.
> for artifact:
> root.project:primary-source:jar:1.0
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> {noformat}
> As you can see, it seems to think that a submodule (in this case
> {{root.project.projects:logging:jar:1.0}}) is necessary to build the javadoc
> for the project... Since this is the first time that this is being built,
> the submodule does not exist (yet).
> I have replicated this problem on two different computing environments, so
> I'm convinced that the Maven version is not relevant.
> (It is unclear to me if this problem also existed with Javadoc 2.6, but I
> don't think so.)
--
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: (MINSTALL-74) CLONE -Don't create checksums for gpg signature files
CLONE -Don't create checksums for gpg signature files - Key: MINSTALL-74 URL: http://jira.codehaus.org/browse/MINSTALL-74 Project: Maven 2.x Install Plugin Issue Type: Improvement Affects Versions: 2.2 Reporter: SebbASF Assignee: Wendy Smoak Priority: Minor Fix For: 2.3 If the gpg plugin is configured and the install plugin configured to create checksums - then it ends up creating checksums for the signature files as well as the actual artifacts being installed. Attaching a patch which stops checksums being created for files ending in ".asc" -- 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] Updated: (MJAVADOC-274) Regression in 2.6.1 - modules with no sources cause an error
[ http://jira.codehaus.org/browse/MJAVADOC-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MJAVADOC-274: Attachment: MJAVADOC-274.zip I created a test for this issue, but cannot get it to fail using version 2.6.1. Can someone who's experiencing this issue please take a look and tell me where I've gone wrong? I can't get this fixed until we have a test to verify the problem, so I'm sure when I have it fixed. > Regression in 2.6.1 - modules with no sources cause an error > > > Key: MJAVADOC-274 > URL: http://jira.codehaus.org/browse/MJAVADOC-274 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6.1 >Reporter: Andrey Razumovsky >Assignee: John Casey > Attachments: MJAVADOC-274.zip > > > After upgrading from 2.6 to 2.6.1 our Apache Cayenne builds got broken. The > problem is in module with no public or protected sources (there's only a > package-private class). Now, after infamous message > "'org.apache.maven.plugins:maven-javadoc-plugin:2.6:javadoc' has not be > previously called for the project ..." build fails and creates an error > report. In the report: > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An error has occurred in JavaDocs report generation: > Exit code: 1 - javadoc: error - No public or protected classes found to > document. > Command line was: C:\Progra~1\Java\jdk1.6.0_13\jre\..\bin\javadoc.exe > @options @packages > Refer to the generated Javadoc files in > 'C:\Project\cayenne-parent\framework\cayenne-jdk1.6-unpublished\target\site\apidocs' > dir. -- 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: (MINSTALL-74) CLONE -Don't create checksums for gpg signature files
[ http://jira.codehaus.org/browse/MINSTALL-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217836#action_217836 ] SebbASF commented on MINSTALL-74: - The comments on MINSTALL-48 say that it was fixed in version 2.3, and so did the announcement message. However, what seems to have happened is that the code was refactored, and the patch was only applied to the install:file goal, rather than being applied to all goals that create a checksum hash. Please could this be fixed? > CLONE -Don't create checksums for gpg signature files > - > > Key: MINSTALL-74 > URL: http://jira.codehaus.org/browse/MINSTALL-74 > Project: Maven 2.x Install Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: SebbASF >Assignee: Wendy Smoak >Priority: Minor > Fix For: 2.3 > > > If the gpg plugin is configured and the install plugin configured to create > checksums - then it ends up creating checksums for the signature files as > well as the actual artifacts being installed. > Attaching a patch which stops checksums being created for files ending in > ".asc" -- 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-274) Regression in 2.6.1 - modules with no sources cause an error
[ http://jira.codehaus.org/browse/MJAVADOC-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217837#action_217837 ] Andrey Razumovsky commented on MJAVADOC-274: I'm not sure I remember the issue properly, but for your test, try to make App class package-private > Regression in 2.6.1 - modules with no sources cause an error > > > Key: MJAVADOC-274 > URL: http://jira.codehaus.org/browse/MJAVADOC-274 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6.1 >Reporter: Andrey Razumovsky >Assignee: John Casey > Attachments: MJAVADOC-274.zip > > > After upgrading from 2.6 to 2.6.1 our Apache Cayenne builds got broken. The > problem is in module with no public or protected sources (there's only a > package-private class). Now, after infamous message > "'org.apache.maven.plugins:maven-javadoc-plugin:2.6:javadoc' has not be > previously called for the project ..." build fails and creates an error > report. In the report: > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An error has occurred in JavaDocs report generation: > Exit code: 1 - javadoc: error - No public or protected classes found to > document. > Command line was: C:\Progra~1\Java\jdk1.6.0_13\jre\..\bin\javadoc.exe > @options @packages > Refer to the generated Javadoc files in > 'C:\Project\cayenne-parent\framework\cayenne-jdk1.6-unpublished\target\site\apidocs' > dir. -- 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] Issue Comment Edited: (MINSTALL-74) CLONE -Don't create checksums for gpg signature files
[ http://jira.codehaus.org/browse/MINSTALL-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217836#action_217836 ] SebbASF edited comment on MINSTALL-74 at 4/13/10 3:32 PM: -- The comments on MINSTALL-48 say that it was fixed in version 2.3, and so did the announcement message. However, the plugin still creates hashes for .asc files, so something went wrong with the fix. I used the following command (on Commons Compress): mvn -Prc package deploy -DaltDeploymentRepository=id::default::file:target -DskipTests was (Author: sebbasf): The comments on MINSTALL-48 say that it was fixed in version 2.3, and so did the announcement message. However, what seems to have happened is that the code was refactored, and the patch was only applied to the install:file goal, rather than being applied to all goals that create a checksum hash. Please could this be fixed? > CLONE -Don't create checksums for gpg signature files > - > > Key: MINSTALL-74 > URL: http://jira.codehaus.org/browse/MINSTALL-74 > Project: Maven 2.x Install Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: SebbASF >Assignee: Wendy Smoak >Priority: Minor > Fix For: 2.3 > > > If the gpg plugin is configured and the install plugin configured to create > checksums - then it ends up creating checksums for the signature files as > well as the actual artifacts being installed. > Attaching a patch which stops checksums being created for files ending in > ".asc" -- 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: (MINSTALL-74) CLONE -Don't create checksums for gpg signature files
[ http://jira.codehaus.org/browse/MINSTALL-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217839#action_217839 ] SebbASF commented on MINSTALL-74: - Further info - seems to only happen with the deploy plugin. mvn -Prc install -DskipTests does not create the unnecessary checksums > CLONE -Don't create checksums for gpg signature files > - > > Key: MINSTALL-74 > URL: http://jira.codehaus.org/browse/MINSTALL-74 > Project: Maven 2.x Install Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: SebbASF >Assignee: Wendy Smoak >Priority: Minor > Fix For: 2.3 > > > If the gpg plugin is configured and the install plugin configured to create > checksums - then it ends up creating checksums for the signature files as > well as the actual artifacts being installed. > Attaching a patch which stops checksums being created for files ending in > ".asc" -- 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: (MINSTALL-74) CLONE -Don't create checksums for gpg signature files
[ http://jira.codehaus.org/browse/MINSTALL-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MINSTALL-74. - Resolution: Duplicate Fix Version/s: (was: 2.3) Assignee: Benjamin Bentmann (was: Wendy Smoak) > CLONE -Don't create checksums for gpg signature files > - > > Key: MINSTALL-74 > URL: http://jira.codehaus.org/browse/MINSTALL-74 > Project: Maven 2.x Install Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: SebbASF >Assignee: Benjamin Bentmann >Priority: Minor > > If the gpg plugin is configured and the install plugin configured to create > checksums - then it ends up creating checksums for the signature files as > well as the actual artifacts being installed. > Attaching a patch which stops checksums being created for files ending in > ".asc" -- 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: (MINSTALL-74) CLONE -Don't create checksums for gpg signature files
[ http://jira.codehaus.org/browse/MINSTALL-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217841#action_217841 ] Benjamin Bentmann commented on MINSTALL-74: --- bq. mvn -Prc package deploy BTW, unless you have the need to run your build twice, "mvn deploy" is sufficient. > CLONE -Don't create checksums for gpg signature files > - > > Key: MINSTALL-74 > URL: http://jira.codehaus.org/browse/MINSTALL-74 > Project: Maven 2.x Install Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: SebbASF >Assignee: Benjamin Bentmann >Priority: Minor > > If the gpg plugin is configured and the install plugin configured to create > checksums - then it ends up creating checksums for the signature files as > well as the actual artifacts being installed. > Attaching a patch which stops checksums being created for files ending in > ".asc" -- 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] Updated: (ARCHETYPE-281) Update to plexus-velocity 1.1.8 and Velocity 1.5
[ http://jira.codehaus.org/browse/ARCHETYPE-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated ARCHETYPE-281: Summary: Update to plexus-velocity 1.1.8 and Velocity 1.5 (was: Update to Velocity 1.5) > Update to plexus-velocity 1.1.8 and Velocity 1.5 > > > Key: ARCHETYPE-281 > URL: http://jira.codehaus.org/browse/ARCHETYPE-281 > Project: Maven Archetype > Issue Type: Improvement > Components: Generator >Affects Versions: 2.0-alpha-4 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) > Java version: 1.5.0_17 > Default locale: fr_FR, platform encoding: Cp1252 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Khaled LABIDI >Priority: Minor > > Hi, > I'm using version 2.0-alpha-4 of archetype-plugin and noticed that some > velocity features are not supported (leading to parser erreor) particularily > the HashMap declaration within a template (Actually, my POM includes some VTL > statements) > This is because the archetype-plugin 2.0-apha-4 depends on archetype-common > 2.0-alpha-4 wich depends on plexus-velocity 1.1.3 which depends on velocity > 1.4 and the later become quite "old" (current version is 1.6) > The plexus-velocity version 1.1.8 has been released since Nov.2009 and it > updated to use velocity 1.5. > Is upgrading archetype-common dependency on plexus-velocity (from 1.1.3 to > 1.1.8) planned for archetype-plugin 2.0-apha-5 ? > By the way, when does the archetype-plugin 2.0-apha-5 release planned ? > Best regards, > K.L -- 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: (ARCHETYPE-281) Update to plexus-velocity 1.1.8 and Velocity 1.5
[ http://jira.codehaus.org/browse/ARCHETYPE-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed ARCHETYPE-281. --- Resolution: Fixed Fix Version/s: 2.0-alpha-5 Assignee: Herve Boutemy upgraded plexus-velocity to 1.1.8 in r933781. FYI, Velocity version was already 1.5... > Update to plexus-velocity 1.1.8 and Velocity 1.5 > > > Key: ARCHETYPE-281 > URL: http://jira.codehaus.org/browse/ARCHETYPE-281 > Project: Maven Archetype > Issue Type: Improvement > Components: Generator >Affects Versions: 2.0-alpha-4 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) > Java version: 1.5.0_17 > Default locale: fr_FR, platform encoding: Cp1252 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Khaled LABIDI >Assignee: Herve Boutemy >Priority: Minor > Fix For: 2.0-alpha-5 > > > Hi, > I'm using version 2.0-alpha-4 of archetype-plugin and noticed that some > velocity features are not supported (leading to parser erreor) particularily > the HashMap declaration within a template (Actually, my POM includes some VTL > statements) > This is because the archetype-plugin 2.0-apha-4 depends on archetype-common > 2.0-alpha-4 wich depends on plexus-velocity 1.1.3 which depends on velocity > 1.4 and the later become quite "old" (current version is 1.6) > The plexus-velocity version 1.1.8 has been released since Nov.2009 and it > updated to use velocity 1.5. > Is upgrading archetype-common dependency on plexus-velocity (from 1.1.3 to > 1.1.8) planned for archetype-plugin 2.0-apha-5 ? > By the way, when does the archetype-plugin 2.0-apha-5 release planned ? > Best regards, > K.L -- 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: (MAVENUPLOAD-2766) Upload log4j 1.2.16 to central
Upload log4j 1.2.16 to central -- Key: MAVENUPLOAD-2766 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2766 Project: Maven Upload Requests Issue Type: Task Reporter: Guillaume Nodet See http://permalink.gmane.org/gmane.comp.apache.logging/1274 for the vote thread and reference to the artifacts -- 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: (ARCHETYPE-85) Generated POM.xml should keep comments
[ http://jira.codehaus.org/browse/ARCHETYPE-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed ARCHETYPE-85. -- Resolution: Fixed Fix Version/s: 2.0-alpha-1 Assignee: Raphaël Piéroni > Generated POM.xml should keep comments > -- > > Key: ARCHETYPE-85 > URL: http://jira.codehaus.org/browse/ARCHETYPE-85 > Project: Maven Archetype > Issue Type: Improvement > Components: Generator >Affects Versions: 1.0-alpha-4 > Environment: Win XP, Maven 2.0.7 >Reporter: Ludovic Claude >Assignee: Raphaël Piéroni >Priority: Minor > Fix For: 2.0-alpha-1 > > > I'm writting some custom archetype for my projects. In the POM.xml template > file, I want to put some comments that would be useful for those developers > who don't know Maven and to guide them. > Something like: > > [...] > > > > > Unfortunately, the whole tag is removed from the generated > pom.xml file. It would be nice to have a templating mechanism that's able to > keep those comments. > Thanks, > Ludovic -- 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: (ARCHETYPE-134) archetype:create strips out comments from the template pom.xml..
[ http://jira.codehaus.org/browse/ARCHETYPE-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed ARCHETYPE-134. --- Resolution: Fixed Fix Version/s: 2.0-alpha-1 Assignee: Raphaël Piéroni > archetype:create strips out comments from the template pom.xml.. > > > Key: ARCHETYPE-134 > URL: http://jira.codehaus.org/browse/ARCHETYPE-134 > Project: Maven Archetype > Issue Type: Bug > Environment: maven-archetype-plugin 1.0-alpha-4 (as stated on IRC) >Reporter: Prasad Kashyap >Assignee: Raphaël Piéroni > Fix For: 2.0-alpha-1 > > > archetype:create strips out comments from the template pom.xml. > comments and license headers from the template pom.xml are gone in the newly > created project -- 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] Updated: (ARCHETYPE-295) When site archetypes (16,17) are built, the index file omits much of the generated output
[ http://jira.codehaus.org/browse/ARCHETYPE-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated ARCHETYPE-295: Component/s: (was: Generator) Archetypes > When site archetypes (16,17) are built, the index file omits much of the > generated output > - > > Key: ARCHETYPE-295 > URL: http://jira.codehaus.org/browse/ARCHETYPE-295 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes >Reporter: SebbASF > > Use mvn archetype:generate to build site (type 16) > Run mvn site. > The site home page that is created in target/site/index.html does not include > any of the generated reports. > Similarly for site type 17. -- 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] Updated: (ARCHETYPE-256) maven-archetype-webapp is not creating java path
[ http://jira.codehaus.org/browse/ARCHETYPE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated ARCHETYPE-256: Component/s: (was: Generator) Archetypes > maven-archetype-webapp is not creating java path > > > Key: ARCHETYPE-256 > URL: http://jira.codehaus.org/browse/ARCHETYPE-256 > Project: Maven Archetype > Issue Type: Improvement > Components: Archetypes >Reporter: Glen Mazza >Priority: Minor > > The maven-archetype-webapp asks us for the default package name, which we > enter as (say) com.mycompany.mywebapp. But it isn't doing anything with this > information. It would be good if it created the > src/java/com/mycompany/mywebapp folder for the user so he would not need to > manually create this folder structure afterwards. > Glen -- 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] Updated: (ARCHETYPE-296) Non-ascii characters not handled correctly in French faq.html (generated from faq.fml)
[ http://jira.codehaus.org/browse/ARCHETYPE-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated ARCHETYPE-296: Component/s: (was: Generator) Archetypes > Non-ascii characters not handled correctly in French faq.html (generated from > faq.fml) > -- > > Key: ARCHETYPE-296 > URL: http://jira.codehaus.org/browse/ARCHETYPE-296 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes >Reporter: SebbASF > > Use mvn archetype:generate to create a site type 17. > Most of the French pages are generated with the correct accents, but faq.html > has "?" instead of "u-grave". > Dunno whether this is a configuration problem or a plugin problem. -- 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] Updated: (ARCHETYPE-228) site missing module in maven-archetype-j2ee-simple archetype plugin
[ http://jira.codehaus.org/browse/ARCHETYPE-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated ARCHETYPE-228: Component/s: (was: Generator) Archetypes > site missing module in maven-archetype-j2ee-simple archetype plugin > --- > > Key: ARCHETYPE-228 > URL: http://jira.codehaus.org/browse/ARCHETYPE-228 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes >Reporter: Esteban DUGUEPEROUX >Priority: Minor > Attachments: ARCHETYPE-228-j2ee.diff, ARCHETYPE-228-part1.diff > > > Hi, > When I create a j2ee-simple project from archetype n°10 the main pom.xml > specify a site module but without site directory. > Then at each j2ee project creation I need to delete the relevant line in > pom.xml. > Can we have a site directory generated or the relevant line in pom.xml > deleted. > Regards. -- 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: (ARCHETYPE-227) spring-osgi-bundle-archetype generates incorrect pom
[
http://jira.codehaus.org/browse/ARCHETYPE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed ARCHETYPE-227.
---
Resolution: Won't Fix
Assignee: Herve Boutemy
this archetype isn't maintained by Maven team, but by SpringSource
Maven team can't do anything to fix this archetype
> spring-osgi-bundle-archetype generates incorrect pom
>
>
> Key: ARCHETYPE-227
> URL: http://jira.codehaus.org/browse/ARCHETYPE-227
> Project: Maven Archetype
> Issue Type: Bug
> Components: Archetypes
> Environment: Tested on Windows using Maven 2.0.9 and 2.0.10 and
> Ubuntu 8.10 using Maven 2.0.9
>Reporter: Mike Haney
>Assignee: Herve Boutemy
>Priority: Minor
> Attachments: package_out.txt
>
>
> Running 'mvn archetype:generate' and choosing spring-osgi-bundle-archetype
> (currently #24) generates code that results in build errors with subsequent
> runs of 'mvn package'. Attached is the output of a run showing the error and
> stack trace (package_out.txt).
> Upon investigation, it appears that the generated pom.xml is specifying
> version 1.0.0 of the maven-bundle-plugin as such:
> {code:xml}
>
> org.apache.felix
> maven-bundle-plugin
> true
> 1.0.0
>
> META-INF
>
>
> !com.example.spring.osgi.impl,com.example.spring.osgi*
>*
>
>src/main/resources
>
>
>
> {code}
> Manually removing the version specification (or less-elegantly, hardcoding
> the current version) resolves this issue so that the build can complete.
> It would be nice to modify the generator plugin so that the pom.xml is
> generated WITHOUT the version specification for the maven-bundle-plugin.
--
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] Updated: (ARCHETYPE-227) spring-osgi-bundle-archetype generates incorrect pom
[
http://jira.codehaus.org/browse/ARCHETYPE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated ARCHETYPE-227:
Component/s: (was: Generator)
Archetypes
> spring-osgi-bundle-archetype generates incorrect pom
>
>
> Key: ARCHETYPE-227
> URL: http://jira.codehaus.org/browse/ARCHETYPE-227
> Project: Maven Archetype
> Issue Type: Bug
> Components: Archetypes
> Environment: Tested on Windows using Maven 2.0.9 and 2.0.10 and
> Ubuntu 8.10 using Maven 2.0.9
>Reporter: Mike Haney
>Priority: Minor
> Attachments: package_out.txt
>
>
> Running 'mvn archetype:generate' and choosing spring-osgi-bundle-archetype
> (currently #24) generates code that results in build errors with subsequent
> runs of 'mvn package'. Attached is the output of a run showing the error and
> stack trace (package_out.txt).
> Upon investigation, it appears that the generated pom.xml is specifying
> version 1.0.0 of the maven-bundle-plugin as such:
> {code:xml}
>
> org.apache.felix
> maven-bundle-plugin
> true
> 1.0.0
>
> META-INF
>
>
> !com.example.spring.osgi.impl,com.example.spring.osgi*
>*
>
>src/main/resources
>
>
>
> {code}
> Manually removing the version specification (or less-elegantly, hardcoding
> the current version) resolves this issue so that the build can complete.
> It would be nice to modify the generator plugin so that the pom.xml is
> generated WITHOUT the version specification for the maven-bundle-plugin.
--
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: (ARCHETYPE-243) archetype:create-from-project generates xnl file, not xml
[ http://jira.codehaus.org/browse/ARCHETYPE-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed ARCHETYPE-243. --- Resolution: Fixed Fix Version/s: 2.0-alpha-5 Assignee: Herve Boutemy generating archetype.xml was suppressed in ARCHETYPE-292 > archetype:create-from-project generates xnl file, not xml > - > > Key: ARCHETYPE-243 > URL: http://jira.codehaus.org/browse/ARCHETYPE-243 > Project: Maven Archetype > Issue Type: Bug > Components: Creator >Affects Versions: 2.0-alpha-4 > Environment: OS X / MBP >Reporter: Doug Hughes >Assignee: Herve Boutemy > Fix For: 2.0-alpha-5 > > > If you use archetype:create-from-project to create a new archetype from an > existing project a file named "archetype.xnl" (note the n, instead of an m) > is created in the directory > "target/generated-sources/archetype/src/main/resources/archetype-resources/src/main/resources/META-INF". > > This appears to cause archetype:generate to ignore the archetype-metadata.xml > file. -- 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] Reopened: (MINSTALL-74) CLONE -Don't create checksums for gpg signature files
[ http://jira.codehaus.org/browse/MINSTALL-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SebbASF reopened MINSTALL-74: - Yes, I realised afterwards that the package was superfluous. Re-opening because the original issue has not been fully solved, and I cannot re-open MINSTALL-48. > CLONE -Don't create checksums for gpg signature files > - > > Key: MINSTALL-74 > URL: http://jira.codehaus.org/browse/MINSTALL-74 > Project: Maven 2.x Install Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: SebbASF >Assignee: Benjamin Bentmann >Priority: Minor > > If the gpg plugin is configured and the install plugin configured to create > checksums - then it ends up creating checksums for the signature files as > well as the actual artifacts being installed. > Attaching a patch which stops checksums being created for files ending in > ".asc" -- 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: (ARCHETYPE-262) Allow empty properties in generated pom.xml
[ http://jira.codehaus.org/browse/ARCHETYPE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed ARCHETYPE-262. --- Resolution: Fixed Fix Version/s: 2.0-alpha-5 Assignee: Herve Boutemy fixed manually checked with r933794 > Allow empty properties in generated pom.xml > --- > > Key: ARCHETYPE-262 > URL: http://jira.codehaus.org/browse/ARCHETYPE-262 > Project: Maven Archetype > Issue Type: Bug > Components: Creator >Affects Versions: 2.0-alpha-4 >Reporter: Matt Raible >Assignee: Herve Boutemy > Fix For: 2.0-alpha-5 > > > http://www.nabble.com/Issues-with-archetype%3Acreate-from-project-to23286970.html#a23427955 > When I have an empty property (e.g. ), it's > removed from the resulting pom.xml. -- 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: (MINSTALL-74) CLONE -Don't create checksums for gpg signature files
[ http://jira.codehaus.org/browse/MINSTALL-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MINSTALL-74. - Resolution: Duplicate Unless you can provide an example project that shows that the *Maven Install Plugin* creates those checksums, the issue is resolved. You might want to vote on MDEPLOY-73 instead. > CLONE -Don't create checksums for gpg signature files > - > > Key: MINSTALL-74 > URL: http://jira.codehaus.org/browse/MINSTALL-74 > Project: Maven 2.x Install Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: SebbASF >Assignee: Benjamin Bentmann >Priority: Minor > > If the gpg plugin is configured and the install plugin configured to create > checksums - then it ends up creating checksums for the signature files as > well as the actual artifacts being installed. > Attaching a patch which stops checksums being created for files ending in > ".asc" -- 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] Updated: (ARCHETYPE-111) Incorrect generation of POM when using maven-archetype-archetype
[
http://jira.codehaus.org/browse/ARCHETYPE-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated ARCHETYPE-111:
Component/s: Archetypes
> Incorrect generation of POM when using maven-archetype-archetype
>
>
> Key: ARCHETYPE-111
> URL: http://jira.codehaus.org/browse/ARCHETYPE-111
> Project: Maven Archetype
> Issue Type: Bug
> Components: Archetypes
>Reporter: Steve Hodson
>Priority: Minor
>
> I recently followed the 'Guide to Creating Archetypes' and I noticed that the
> generated pom.xml in
> src/main/resources/archetype-resources
> displays
> 4.0.0
> $test.archetype
> $test
> $1.0-SNAPSHOT
>
>
> junit
> which is then used as the project pom when this archetype is run.
> It seems to be using the groupId, artifactId and version of the archetype and
> not generating ${groupId} et al. A workaround is to amend the file manually.
--
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: (MINSTALL-74) CLONE -Don't create checksums for gpg signature files
[ http://jira.codehaus.org/browse/MINSTALL-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217864#action_217864 ] SebbASF commented on MINSTALL-74: - Sorry, did not realise that the deploy plugin creates hashes. Before re-opening the issue, I had a look at the Maven deploy plugin documentation, and did not notice any reference to it creating checksums. I've just had another look, and still cannot find any documentation to say that it creates checksums. The only reference I could find to hashes is: bq. As a repository contains more than the artifacts (POMs, the metadata, MD5 and SHA1 hash files...), deploying means not only copying the artifacts which suggests that the hashes are generated elsewhere and merely copied by the plugin. > CLONE -Don't create checksums for gpg signature files > - > > Key: MINSTALL-74 > URL: http://jira.codehaus.org/browse/MINSTALL-74 > Project: Maven 2.x Install Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: SebbASF >Assignee: Benjamin Bentmann >Priority: Minor > > If the gpg plugin is configured and the install plugin configured to create > checksums - then it ends up creating checksums for the signature files as > well as the actual artifacts being installed. > Attaching a patch which stops checksums being created for files ending in > ".asc" -- 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: (MDEPLOY-73) Don't add checksums on gpg signature files
[ http://jira.codehaus.org/browse/MDEPLOY-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217865#action_217865 ] SebbASF commented on MDEPLOY-73: I think this should be classified as a bug, rather than a wish. > Don't add checksums on gpg signature files > -- > > Key: MDEPLOY-73 > URL: http://jira.codehaus.org/browse/MDEPLOY-73 > Project: Maven 2.x Deploy Plugin > Issue Type: Wish >Affects Versions: 2.3 >Reporter: Wendy Smoak >Priority: Minor > Attachments: DefaultWagonManager.patch > > > Similar to MINSTALL-48, don't create checksums when deploying a gpg signature > file along with the artifact. > Currently we end up with filename.asc, filename.asc.md5 and filename.asc.sha1 > in the remote repository, and only filename.asc 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: (MDEPLOY-122) Deploy documentation is misleading about hashes
Deploy documentation is misleading about hashes --- Key: MDEPLOY-122 URL: http://jira.codehaus.org/browse/MDEPLOY-122 Project: Maven 2.x Deploy Plugin Issue Type: Bug Reporter: SebbASF Priority: Minor The deploy website does not say that the plugin creates hashes. The only mention of hashes is on the Introduction page which says: bq. As a repository contains more than the artifacts (POMs, the metadata, MD5 and SHA1 hash files...), deploying means not only copying the artifacts, ... This suggests that the hash files are merely copied by the plugin, whereas in fact the plugin creates them. Please could the docs be updated to clarify that the plugin actually creates the hashes? -- 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] Reopened: (MPIR-188) Maven constructs wrong classpath element
[ http://jira.codehaus.org/browse/MPIR-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Biesack reopened MPIR-188: I am reopening this issue because I am still getting build failures due to a bad classpath, even though the maven-project-info-reports-plugin is being resolved with the 2.1 version. I'll attach a new MPIR-188.tar that contains two maven projects, a and b and mvn.log which shows the failure cd a mvn -X clean site-deploy deploy install cd ./b mvn -X help:effective-pom clean site-deploy deploy The classpath is wrong: [DEBUG] Classpath: [DEBUG] U:\dev\maven-bugs\MPIR-188\b\target\test-classes [DEBUG] U:\dev\maven-bugs\MPIR-188\b\target\classes [DEBUG] C:\Documents and Settings\sasdjb\.m2\repository\mypackage\a\0.1-SNAPSHOT\a-0.1-SNAPSHOT.jar [DEBUG] C:\Documents and Settings\sasdjb\.m2\repository\mypackage\a\0.1-SNAPSHOT\a-0.1-SNAPSHOT.jar even though we have: [DEBUG] Plugin dependencies for: org.apache.maven.plugins:maven-project-info-reports-plugin:2.1 This report said to run maven with 2.1.2 of the plugin, but I don't know how to do that; I do not know what other Maven piece brings that it or how to override Maven's defaults to load 2.1.2 instead of 2.1. > Maven constructs wrong classpath element > > > Key: MPIR-188 > URL: http://jira.codehaus.org/browse/MPIR-188 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Bug > Components: dependencies >Affects Versions: 2.1 >Reporter: David Biesack >Assignee: Benjamin Bentmann > Attachments: MNG-4613.tar > > > We run Maven 2 builds from Cruise Control; the projects each build with the > same targets: > clean jar:test-jar site-deploy deploy > Unfortunately, this causes the unit tests to run twice, once for site-deploy > (surefire reports) and once for deploy. > Under 2.0.9 this was not a problem, but we recently switched to 2.2.1 and > some tests were failing > because the test classpath constructed for the first set of test runs differs > from the classpath for the second. > In the pom file, there is a dependency from the current project to both the > normal jar *and* the test jar of > another project: > > com.sas.other > sas.other > 1.0-SNAPSHOT > test-jar > test > > > com.sas.other > sas.other > 1.0-SNAPSHOT > > The first test run contains > [DEBUG] > /u/acladmin/.m2/repository/com/sas/other/sas.other/1.0-SNAPSHOT/sas.other-1.0-SNAPSHOT-tests.jar > ... > [DEBUG] > /u/acladmin/.m2/repository/com/sas/other/sas.other/1.0-SNAPSHOT/sas.other-1.0-SNAPSHOT.jar > However, when we build with Maven 2.2.1, the classpath of the second test run > is different: > [DEBUG] > /u/acladmin/.m2/repository/com/sas/other/sas.other/1.0-SNAPSHOT/sas.other-1.0-SNAPSHOT.jar > ... > [DEBUG] > /u/acladmin/.m2/repository/com/sas/other/sas.other/1.0-SNAPSHOT/sas.other-1.0-SNAPSHOT.jar > Because the classpath is missing a jar, the tests fail, and hence the entire > build fails. > If we run the targets separately > mvn clean deploy > mvn site-deploy > then maven only runs the tests once per run, with the correct classpath, so > the test and the entire build passes. > This looks like a regression between 2.0.9 and 2.2.1. Sorry, we did not > install/test other intermediate releases. -- 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] Updated: (MPIR-188) Maven constructs wrong classpath element
[ http://jira.codehaus.org/browse/MPIR-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Biesack updated MPIR-188: --- Attachment: MPIR-188.tar See previous comment. > Maven constructs wrong classpath element > > > Key: MPIR-188 > URL: http://jira.codehaus.org/browse/MPIR-188 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Bug > Components: dependencies >Affects Versions: 2.1 >Reporter: David Biesack >Assignee: Benjamin Bentmann > Attachments: MNG-4613.tar, MPIR-188.tar > > > We run Maven 2 builds from Cruise Control; the projects each build with the > same targets: > clean jar:test-jar site-deploy deploy > Unfortunately, this causes the unit tests to run twice, once for site-deploy > (surefire reports) and once for deploy. > Under 2.0.9 this was not a problem, but we recently switched to 2.2.1 and > some tests were failing > because the test classpath constructed for the first set of test runs differs > from the classpath for the second. > In the pom file, there is a dependency from the current project to both the > normal jar *and* the test jar of > another project: > > com.sas.other > sas.other > 1.0-SNAPSHOT > test-jar > test > > > com.sas.other > sas.other > 1.0-SNAPSHOT > > The first test run contains > [DEBUG] > /u/acladmin/.m2/repository/com/sas/other/sas.other/1.0-SNAPSHOT/sas.other-1.0-SNAPSHOT-tests.jar > ... > [DEBUG] > /u/acladmin/.m2/repository/com/sas/other/sas.other/1.0-SNAPSHOT/sas.other-1.0-SNAPSHOT.jar > However, when we build with Maven 2.2.1, the classpath of the second test run > is different: > [DEBUG] > /u/acladmin/.m2/repository/com/sas/other/sas.other/1.0-SNAPSHOT/sas.other-1.0-SNAPSHOT.jar > ... > [DEBUG] > /u/acladmin/.m2/repository/com/sas/other/sas.other/1.0-SNAPSHOT/sas.other-1.0-SNAPSHOT.jar > Because the classpath is missing a jar, the tests fail, and hence the entire > build fails. > If we run the targets separately > mvn clean deploy > mvn site-deploy > then maven only runs the tests once per run, with the correct classpath, so > the test and the entire build passes. > This looks like a regression between 2.0.9 and 2.2.1. Sorry, we did not > install/test other intermediate releases. -- 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: (MCHANGES-190) HTML in changes.xml stopped working
[ http://jira.codehaus.org/browse/MCHANGES-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217872#action_217872 ] SebbASF commented on MCHANGES-190: -- Note that version 2.0 also allowed HTML markup which was not in a CDATA section. This has also been used, e.g. to add links and emphasis, both of which would also be useful in PDF output. == As to announcements, these are processed using a Velocity template. Velocity is powerful enough to be able to handle markup so surely it ought to be possible to fix this somehow? > HTML in changes.xml stopped working > --- > > Key: MCHANGES-190 > URL: http://jira.codehaus.org/browse/MCHANGES-190 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: changes-report >Affects Versions: 2.3 > Environment: Maven version: 2.0.10 > Java version: 1.5.0_17 > OS name: "linux" version: "2.6.32-686" arch: "i386" Family: "unix" >Reporter: Christian Schulte >Priority: Critical > Attachments: changes.xml, changes.xml, MCHANGES-190.zip > > > The fix for MCHANGES-189 does not seem to be correct. A changes.xml file > containing HTML-Tags got rendered correctly using version 2.2. Starting with > version 2.3, HTML-Tags will be encoded using HTML entities for the '<' and > '>' characters leading to the actual tags getting shown in the report. See > the attached example changes.xml file containing HTML no longer working with > version 2.3. -- 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: (MAVENUPLOAD-2766) Upload log4j 1.2.16 to central
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217873#action_217873 ] Brett Porter commented on MAVENUPLOAD-2766: --- The log4j developers are already working on making this happen through the normal ASF channels. > Upload log4j 1.2.16 to central > -- > > Key: MAVENUPLOAD-2766 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2766 > Project: Maven Upload Requests > Issue Type: Task >Reporter: Guillaume Nodet > > See http://permalink.gmane.org/gmane.comp.apache.logging/1274 for the vote > thread and reference to the artifacts -- 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: (MCHANGES-160) Support creating a plain text version of the report
[ http://jira.codehaus.org/browse/MCHANGES-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217874#action_217874 ] SebbASF commented on MCHANGES-160: -- You can also create your own velocity template if you want to change the layout or content, but the default announcement.vm file produced by "mvn changes:announcement-generate" is pretty good as is. What you cannot change currently is the output file name (same as template name) or directory (target/announcement). Just rename the file and move it somewhere suitable. > Support creating a plain text version of the report > --- > > Key: MCHANGES-160 > URL: http://jira.codehaus.org/browse/MCHANGES-160 > Project: Maven 2.x Changes Plugin > Issue Type: New Feature >Reporter: Trygve Laugstol > > Useful when the change log is to be included in a native package or in a WAR > as documentation. -- 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: (MNG-4634) Allow custom lifecycles
Allow custom lifecycles --- Key: MNG-4634 URL: http://jira.codehaus.org/browse/MNG-4634 Project: Maven 2 & 3 Issue Type: Improvement Components: Plugins and Lifecycle Reporter: Igor Fedorenko Allow build extensions to contribute new lifecycles. Most of the required plumbing is already present, so we only need to make Lifecycle into a component. -- 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: (MNG-4634) Allow custom lifecycles
[ http://jira.codehaus.org/browse/MNG-4634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-4634. --- Resolution: Fixed Fix Version/s: 3.0-beta-1 Implemented in [r933848|http://svn.apache.org/viewvc?view=revision&revision=933848] > Allow custom lifecycles > --- > > Key: MNG-4634 > URL: http://jira.codehaus.org/browse/MNG-4634 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Plugins and Lifecycle >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.0-beta-1 > > > Allow build extensions to contribute new lifecycles. Most of the required > plumbing is already present, so we only need to make Lifecycle into a > component. -- 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
