[jira] Created: (MAVENUPLOAD-2577) Please upload two org.igniterealtime Tinder bundles
Please upload two org.igniterealtime Tinder bundles --- Key: MAVENUPLOAD-2577 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2577 Project: Maven Upload Requests Issue Type: Wish Reporter: Guus der Kinderen http://www.igniterealtime.org/maven/tinder-1.0.0-bundle.jar http://www.igniterealtime.org/maven/tinder-1.1.0-bundle.jar http://www.igniterealtime.org/projects/tinder/ http://www.igniterealtime.org/projects/tinder/index.jsp (top right corner) I'm the project lead of Tinder (groupId org.igniterealtime). I would like the two releases listed above to be uploaded to the central maven repository. -- 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: (MRESOURCES-99) ${project.baseUri} and ${maven.build.timestamp} are not expanded by resource filtering
${project.baseUri} and ${maven.build.timestamp} are not expanded by resource
filtering
---
Key: MRESOURCES-99
URL: http://jira.codehaus.org/browse/MRESOURCES-99
Project: Maven 2.x Resources Plugin
Issue Type: Improvement
Affects Versions: 2.4, 2.3
Reporter: Thomas Champagne
When filtering resources, ${project.baseUri} and ${maven.build.timestamp} are
not expanded (remains unchanged in the output 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] Commented: (SCM-335) ability to get the current revision of the project workspace
[ http://jira.codehaus.org/browse/SCM-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188748#action_188748 ] Tomás Pollak commented on SCM-335: -- Hi, I would like to see this feature too. I'm using Mercurial. > ability to get the current revision of the project workspace > > > Key: SCM-335 > URL: http://jira.codehaus.org/browse/SCM-335 > Project: Maven SCM > Issue Type: New Feature > Components: maven-plugin > Environment: subversion >Reporter: nicolas de loof >Priority: Minor > > I'd like to add in my artifacts manifest the SVN revision number. > The scm plugin seems to be the best place to extract such info, but doesn't > seem to yet have support for this. > I'd like to see some scm:revision goal in the plugin, to set a property I can > use later. > I've found this plugin : > http://commons.ucalgary.ca/projects/maven-buildnumber-plugin/howto.html > but it has the issue of parsing the text-based svn output. As a french user, > svn is localized and doesn't return the expected "Revision" property (but > R*é*vision). > Maybe I looking in the wrong place as revision number concept is not portable > to CVS, for example, and maybe neither to other SCM tools. -- 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: (MASSEMBLY-75) Unpacked TAR dependencies do not preserve file mode nor uid/gid
[ http://jira.codehaus.org/browse/MASSEMBLY-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188746#action_188746 ] Gabe McArthur commented on MASSEMBLY-75: Tested with 2.2-beta-4, and it's still not fixed. What gives? This has supposedly been closed, but I unpackage from a ZIP archive into a TAR.GZ archive, and I get no file permissions at all. Seriously, not even read on the user level: I get '---'. How screwy is that? Why is this not tested/fixed after 8 months? > Unpacked TAR dependencies do not preserve file mode nor uid/gid > --- > > Key: MASSEMBLY-75 > URL: http://jira.codehaus.org/browse/MASSEMBLY-75 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.0.1 >Reporter: Maciej Szefler >Assignee: John Casey > Fix For: 2.2-beta-3 > > > "TAR" Assemblies generated from unpacking another TAR do not preserver the > extended file information (uid/gid/mod). For example: > if bar.tar contains an executable file "baz" and > if our .pom has the following dependency: > > foo > bar > tar > compile > > and our assembly.xml has the following: > > > > tar.gz > > > > > compile > > > foo:bar > > true > > then the generated assembly will contain "baz", but it will no longer be > executable. -- 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: (MSHARED-125) Current incremental build implementation failed when resources are removed from target folder
[ http://jira.codehaus.org/browse/MSHARED-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSHARED-125. Assignee: Olivier Lamy Resolution: Fixed Fix Version/s: maven-filtering-1.0-beta-4 fix [rev 808215|http://svn.apache.org/viewvc?rev=808215&view=rev] > Current incremental build implementation failed when resources are removed > from target folder > - > > Key: MSHARED-125 > URL: http://jira.codehaus.org/browse/MSHARED-125 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-filtering >Affects Versions: maven-filtering-1.0-beta-3 > Environment: m2e >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: maven-filtering-1.0-beta-4 > > > see related issue https://issues.sonatype.org/browse/MNGECLIPSE-1605. -- 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: (MSHARED-125) Current incremental build implementation failed when resources are removed from target folder
Current incremental build implementation failed when resources are removed from target folder - Key: MSHARED-125 URL: http://jira.codehaus.org/browse/MSHARED-125 Project: Maven Shared Components Issue Type: Bug Components: maven-filtering Affects Versions: maven-filtering-1.0-beta-3 Environment: m2e Reporter: Olivier Lamy see related issue https://issues.sonatype.org/browse/MNGECLIPSE-1605. -- 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-256) No list of the possible reports in the doc
[ http://jira.codehaus.org/browse/MJAVADOC-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MJAVADOC-256. Resolution: Won't Fix In the above page, we have a link to "Guide to Configuring Plug-ins" [1] which is enough to configure every reporting plugin with reportSets. [1] http://maven.apache.org/guides/mini/guide-configuring-plugins.html > No list of the possible reports in the doc > -- > > Key: MJAVADOC-256 > URL: http://jira.codehaus.org/browse/MJAVADOC-256 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Benson Margulies > > Reading up one side of the doc and down the other, I get the feeling that > there is a 1-1 relationship between the goals and the reports. But nothing on > the site says this in so many words. The pom doc on reporting and reportSets > seems to think that the javadoc plugin will carry the load, and vica versa. -- 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-4326) Maven should not check snapshot repositories if there is already an up to date local copy (and metadata) of the snapshot artifact
Maven should not check snapshot repositories if there is already an up to date local copy (and metadata) of the snapshot artifact - Key: MNG-4326 URL: http://jira.codehaus.org/browse/MNG-4326 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.2.1, 2.0.10 Reporter: Paul Gier If I build and install a local snapshot of an artifact, maven will still check the snapshot repository in order to update the metadata in the local repository. Instead, Maven should only check the snapshot repository when there is no up to date (according to the update policy) local artifact installation. -- 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: (MWAR-170) NPE in WebappStructure, Line 109
[
http://jira.codehaus.org/browse/MWAR-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188723#action_188723
]
Tim Harsch commented on MWAR-170:
-
The maven-war-plugin. 2.2.1 is not using the latest.
here's a basic definition you can put in your pom
{code:xml}
maven-war-plugin
2.1-beta-1
{code}
> NPE in WebappStructure, Line 109
>
>
> Key: MWAR-170
> URL: http://jira.codehaus.org/browse/MWAR-170
> Project: Maven 2.x WAR Plugin
> Issue Type: Bug
>Affects Versions: 2.1-alpha-2
> Environment: 2.1-beta-1-SNAPSHOT
> 2.1-alpha-2-SNAPSHOT
>Reporter: Corridor Software Developer
>Assignee: Olivier Lamy
> Fix For: 2.1-beta-1
>
>
> Both of these versions (see environment) introduce a NullPointerException not
> exhibited in the current release:
> java.lang.NullPointerException
> at
> org.apache.maven.plugin.war.util.WebappStructure.getDependencies(WebappStructure.java:109)
> at
> org.apache.maven.plugin.war.util.WebappStructure.analyseDependencies(WebappStructure.java:288)
> at
> org.apache.maven.plugin.war.packaging.DependenciesAnalysisPackagingTask.performPackaging(DependenciesAnalysisPackagingTask.java:46)
> at
> org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:439)
> at
> org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:375)
> at
> org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181)
> at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> [INFO]
>
> NPE's are usually self-explanatory, but if you need a pom or test case
> project, let me know...
--
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: (MWAR-170) NPE in WebappStructure, Line 109
[ http://jira.codehaus.org/browse/MWAR-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188721#action_188721 ] Paul Taylor commented on MWAR-170: -- Upgrade what exactly. I just upgraded from maven 2.0.9 to maven 2.2.1 and now I get this error, I havent specified a version of Maven War plugin > NPE in WebappStructure, Line 109 > > > Key: MWAR-170 > URL: http://jira.codehaus.org/browse/MWAR-170 > Project: Maven 2.x WAR Plugin > Issue Type: Bug >Affects Versions: 2.1-alpha-2 > Environment: 2.1-beta-1-SNAPSHOT > 2.1-alpha-2-SNAPSHOT >Reporter: Corridor Software Developer >Assignee: Olivier Lamy > Fix For: 2.1-beta-1 > > > Both of these versions (see environment) introduce a NullPointerException not > exhibited in the current release: > java.lang.NullPointerException > at > org.apache.maven.plugin.war.util.WebappStructure.getDependencies(WebappStructure.java:109) > at > org.apache.maven.plugin.war.util.WebappStructure.analyseDependencies(WebappStructure.java:288) > at > org.apache.maven.plugin.war.packaging.DependenciesAnalysisPackagingTask.performPackaging(DependenciesAnalysisPackagingTask.java:46) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:439) > at > org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:375) > at > org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:181) > at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:143) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > > NPE's are usually self-explanatory, but if you need a pom or test case > project, let me know... -- 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-83) Wrong username during release:prepare tagging
[ http://jira.codehaus.org/browse/MRELEASE-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188720#action_188720 ] Mike Dillon commented on MRELEASE-83: - Does the fix for MRELEASE-442 solve this? > 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 > Fix For: 2.0-beta-10 > > > 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: (MNG-4162) Removal of all reporting logic from the core of Maven
[ http://jira.codehaus.org/browse/MNG-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188696#action_188696 ] Olivier Lamy commented on MNG-4162: --- first part of this working. Currently only for "simple" report plugins. Now we have to work with complicated report plugins which fork lifecycle (surefire report, cobertura). > Removal of all reporting logic from the core of Maven > - > > Key: MNG-4162 > URL: http://jira.codehaus.org/browse/MNG-4162 > Project: Maven 2 > Issue Type: Improvement >Reporter: Jason van Zyl >Assignee: Benjamin Bentmann > Fix For: 3.0 > > Attachments: MNG-4162.patch > > > Any reporting implementation will be implemented as a plugin. Maven will > provide any information, APIs, and extension points to make this possible. > But the conflation of building with reporting in the core makes it almost > impossible for anyone two understand the distinction, makes it impossible to > have alternate implementations and couple many tools like Doxia directly to > the core which is unacceptable for Maven 3.x. -- 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: (MJAR-61) Manifest classpath ignores the "real" JAR filenames specified in
[
http://jira.codehaus.org/browse/MJAR-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188671#action_188671
]
Daniel Green commented on MJAR-61:
--
Thank you Darbois for the information. Is there a current workaround to this
issue?
> Manifest classpath ignores the "real" JAR filenames specified in
>
>
> Key: MJAR-61
> URL: http://jira.codehaus.org/browse/MJAR-61
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Martin Desruisseaux
>
> The manifest classpath generated by Maven ignores the "real" JAR name as
> specified in {{}}. For example the Geotools project tried the
> following configuration:
> {code:xml}
>
> gt-${artifactId}-${version}
> {code}
> but the manifest classpath generated by Maven contains only
> {{${artifactId}-${version}.jar}} entries, which are non-existent JARs.
> *Note:* this problem happen only when the JAR dependencis come from the
> repository. The manifest classpath is correct if all dependencies were
> compiled in the same "{{mvn install}}" cycle. However this workaround is
> applicable only to Geotools developpers (in our case), because users of the
> Geotools library usually download the dependencies from a repository.
> This bug may be related to MJAR-28.
--
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-477) Add a commitBeforeTag option for release:prepare to allow skipping scm-commit-release
[ http://jira.codehaus.org/browse/MRELEASE-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188661#action_188661 ] Mike Dillon commented on MRELEASE-477: -- After taking a look at what it would take to do this patch, I think a change to maven-scm would be good as well. We'd need to add a "requiresCommitBeforeTag" to the SCM provider since not all providers can do a local to remote copy from a changed working directory like SVN can. > Add a commitBeforeTag option for release:prepare to allow skipping > scm-commit-release > - > > Key: MRELEASE-477 > URL: http://jira.codehaus.org/browse/MRELEASE-477 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare >Reporter: Mike Dillon > > As detailed in this thread, there can be reproducibility problems with > committing to the source branch (e.g. trunk) before tagging: > http://www.nabble.com/Limitation-of-the-release-plugin--to20822478.html > In the now default case where remoteTagging is true, the commit to the source > branch is necessary to get the source into the right state before doing the > remote copy. However, when remoteTagging is false, the extra commit means > that between the user's initial checkout and the automatic commit to the > source branch, other changes could have been committed which will mean that > the new tag will not have been created from a single, consistent revision of > the source branch. > My proposed fix for this is to add a commitBeforeTag option that would cause > scm-commit-release to be skipped during release:prepare. It would be an error > to have commitBeforeTag=false when remoteTagging=true since the commit before > tag must be done in the remote tagging scenario. > I can provide a patch if this approach is acceptable. -- 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-477) Add a commitBeforeTag option for release:prepare to allow skipping scm-commit-release
[ http://jira.codehaus.org/browse/MRELEASE-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188656#action_188656 ] Mike Dillon commented on MRELEASE-477: -- Forgot to mention that commitBeforeTag would default to true to preserve the current behavior. > Add a commitBeforeTag option for release:prepare to allow skipping > scm-commit-release > - > > Key: MRELEASE-477 > URL: http://jira.codehaus.org/browse/MRELEASE-477 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare >Reporter: Mike Dillon > > As detailed in this thread, there can be reproducibility problems with > committing to the source branch (e.g. trunk) before tagging: > http://www.nabble.com/Limitation-of-the-release-plugin--to20822478.html > In the now default case where remoteTagging is true, the commit to the source > branch is necessary to get the source into the right state before doing the > remote copy. However, when remoteTagging is false, the extra commit means > that between the user's initial checkout and the automatic commit to the > source branch, other changes could have been committed which will mean that > the new tag will not have been created from a single, consistent revision of > the source branch. > My proposed fix for this is to add a commitBeforeTag option that would cause > scm-commit-release to be skipped during release:prepare. It would be an error > to have commitBeforeTag=false when remoteTagging=true since the commit before > tag must be done in the remote tagging scenario. > I can provide a patch if this approach is acceptable. -- 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: (MRELEASE-477) Add a commitBeforeTag option for release:prepare to allow skipping scm-commit-release
Add a commitBeforeTag option for release:prepare to allow skipping scm-commit-release - Key: MRELEASE-477 URL: http://jira.codehaus.org/browse/MRELEASE-477 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Reporter: Mike Dillon As detailed in this thread, there can be reproducibility problems with committing to the source branch (e.g. trunk) before tagging: http://www.nabble.com/Limitation-of-the-release-plugin--to20822478.html In the now default case where remoteTagging is true, the commit to the source branch is necessary to get the source into the right state before doing the remote copy. However, when remoteTagging is false, the extra commit means that between the user's initial checkout and the automatic commit to the source branch, other changes could have been committed which will mean that the new tag will not have been created from a single, consistent revision of the source branch. My proposed fix for this is to add a commitBeforeTag option that would cause scm-commit-release to be skipped during release:prepare. It would be an error to have commitBeforeTag=false when remoteTagging=true since the commit before tag must be done in the remote tagging scenario. I can provide a patch if this approach is acceptable. -- 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: (MSITE-426) Site-structure and links messed up when using inheritance and sub-sub-modules
[
http://jira.codehaus.org/browse/MSITE-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Wenig updated MSITE-426:
Attachment: demo3.zip
demo2.zip
demo1.zip
The site output
> Site-structure and links messed up when using inheritance and sub-sub-modules
> -
>
> Key: MSITE-426
> URL: http://jira.codehaus.org/browse/MSITE-426
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Environment: WindowsXP, Solaris 2.8, SLES10, Maven 2.2.0, JDK 1.6
>Reporter: Michael Wenig
> Attachments: 1.zip, 2.zip, 3.zip, demo1.zip, demo2.zip, demo3.zip
>
>
> We have a structure like this:
> pom.xml (A) (inherits from a companies-pom and acts primary as a generated
> multi-module-pom which should not be in need to be changed by developers)
> + ModuleContainer
> + pom.xml (B)
> + Module1 (which inherits from upper-pom)
> + pom.xml (C)
> + Module2 (which inherits from ProjectSuperPom)
> + pom.xml (D)
> + Module3
> + pom.xml (E)
> pom A is intended to get generated and not changed by project team (includes
> the basic settings for issue management and so on). It is a multimodule and
> includes exactly one module (ModuleContainer)
> pom B is primarly intended to define the modules of the project and is
> intended to be changed by the project team. It could also act as a SuperPom
> of the project or delegate this to a separate module
> pom C, D, and E are 'normal' modules which use as parent the
> ModuleContainer-Pom, a separate SuperPom or the pom A
> I made several tests, changed the inheritance, module definitions but did
> never achieved a site which was working (after deploying the site!).
> I achieved that the sites are stored in a sensable structure but needed to
> add a distributionManagement to each pom which is error-prone.
> But I did not achieve that the links are ok - the are everytime extrapolated
> in some strange way. The should be read out of the pom
> (or parent-pom and calculated the normal maven-way) of the module and perhaps
> extrapolated when there ist none (but then a configurable pattern
> would be better).
> I attached three samples together with the created sites (windows, JDK 1.6,
> Maven 2.2.0).
> demo1:
> The physical structure does not make sense in this case as the
> inheritance-parent-poms name AND the module artifact name is used as a suffix
> for the directory
> and has no benefit there
> demo2:
> I added a distributionManagement and url to all poms
> now the physical structure is ok
> The following problems:
> The rootPoms-site contains two links (which are syntactically correct and
> working):
> - to modules (ok)
> - to projectPom
> I either expect only a link to modules (as this is the only direct module of
> rootPom) or a link
> to all modules including the submodules of rootPom. It seems that the module
> list is build up out of the modules and the direct inherited projects
> (as rootPom is the parent-pom of projectPom) - this makes IMHO no sense!
> Neither the site of the modules nor of projectPom contains any links to the
> other modules.
> I would expect a list of projectPom, module1, module2
> demo3:
> I removed the double-multimodule and included all modules in the RootPom but
> keeping the extra projectPom
> Problems:
> - Only The projectPom is linked from RootPom
> - the structure of the different sites is different:
> demo3\Module1\0.0.1-SNAPSHOT (ok)
> demo3\projectPom\0.0.1-SNAPSHOT (ok)
> demo3\RootPom\0.0.1-SNAPSHOT (ok)
> demo3\Module2\0.0.1-SNAPSHOT\Module2 (becaus of missing
> distributionManagement which makes no sense)
> The physical structure should be that of demo2 even if the
> distributionManagement is missing in the sub-poms (it is error-prone to have
> it in every one).
> There should be a configuration-switch to deactivate ANY magic in building
> the structure and use a pattern instead.
> e.G. in a companies-pom which is a superpom of all projects and modules
> (direct or indirect):
> file:///tmp/mvn-sites/${groupId}/${artifactId}/${version}
>
>
> mysites
>
> file:///tmp/mvn-sites/${groupId}/${artifactId}/${version}
> nada
> true
> true
>
>
> and no need for any distributionManagement or url in the other poms.
> Therefore the pom of the module has to be analyzed if there is a url coming
> out.
> If not the 'old way' could be used
> and for every link the RESULTING url of the destination should be used.
--
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 i
[jira] Created: (MSITE-426) Site-structure and links messed up when using inheritance and sub-sub-modules
Site-structure and links messed up when using inheritance and sub-sub-modules
-
Key: MSITE-426
URL: http://jira.codehaus.org/browse/MSITE-426
Project: Maven 2.x Site Plugin
Issue Type: Bug
Environment: WindowsXP, Solaris 2.8, SLES10, Maven 2.2.0, JDK 1.6
Reporter: Michael Wenig
Attachments: 1.zip, 2.zip, 3.zip, demo1.zip, demo2.zip, demo3.zip
We have a structure like this:
pom.xml (A) (inherits from a companies-pom and acts primary as a generated
multi-module-pom which should not be in need to be changed by developers)
+ ModuleContainer
+ pom.xml (B)
+ Module1 (which inherits from upper-pom)
+ pom.xml (C)
+ Module2 (which inherits from ProjectSuperPom)
+ pom.xml (D)
+ Module3
+ pom.xml (E)
pom A is intended to get generated and not changed by project team (includes
the basic settings for issue management and so on). It is a multimodule and
includes exactly one module (ModuleContainer)
pom B is primarly intended to define the modules of the project and is intended
to be changed by the project team. It could also act as a SuperPom of the
project or delegate this to a separate module
pom C, D, and E are 'normal' modules which use as parent the
ModuleContainer-Pom, a separate SuperPom or the pom A
I made several tests, changed the inheritance, module definitions but did never
achieved a site which was working (after deploying the site!).
I achieved that the sites are stored in a sensable structure but needed to add
a distributionManagement to each pom which is error-prone.
But I did not achieve that the links are ok - the are everytime extrapolated in
some strange way. The should be read out of the pom
(or parent-pom and calculated the normal maven-way) of the module and perhaps
extrapolated when there ist none (but then a configurable pattern
would be better).
I attached three samples together with the created sites (windows, JDK 1.6,
Maven 2.2.0).
demo1:
The physical structure does not make sense in this case as the
inheritance-parent-poms name AND the module artifact name is used as a suffix
for the directory
and has no benefit there
demo2:
I added a distributionManagement and url to all poms
now the physical structure is ok
The following problems:
The rootPoms-site contains two links (which are syntactically correct and
working):
- to modules (ok)
- to projectPom
I either expect only a link to modules (as this is the only direct module of
rootPom) or a link
to all modules including the submodules of rootPom. It seems that the module
list is build up out of the modules and the direct inherited projects
(as rootPom is the parent-pom of projectPom) - this makes IMHO no sense!
Neither the site of the modules nor of projectPom contains any links to the
other modules.
I would expect a list of projectPom, module1, module2
demo3:
I removed the double-multimodule and included all modules in the RootPom but
keeping the extra projectPom
Problems:
- Only The projectPom is linked from RootPom
- the structure of the different sites is different:
demo3\Module1\0.0.1-SNAPSHOT (ok)
demo3\projectPom\0.0.1-SNAPSHOT (ok)
demo3\RootPom\0.0.1-SNAPSHOT (ok)
demo3\Module2\0.0.1-SNAPSHOT\Module2 (becaus of missing distributionManagement
which makes no sense)
The physical structure should be that of demo2 even if the
distributionManagement is missing in the sub-poms (it is error-prone to have it
in every one).
There should be a configuration-switch to deactivate ANY magic in building the
structure and use a pattern instead.
e.G. in a companies-pom which is a superpom of all projects and modules (direct
or indirect):
file:///tmp/mvn-sites/${groupId}/${artifactId}/${version}
mysites
file:///tmp/mvn-sites/${groupId}/${artifactId}/${version}
nada
true
true
and no need for any distributionManagement or url in the other poms. Therefore
the pom of the module has to be analyzed if there is a url coming out.
If not the 'old way' could be used
and for every link the RESULTING url of the destination should be used.
--
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-2576) lzma-java 1.0 upload request
lzma-java 1.0 upload request Key: MAVENUPLOAD-2576 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2576 Project: Maven Upload Requests Issue Type: Wish Reporter: Julien Ponge http://cloud.github.com/downloads/jponge/lzma-java/lzma-java-1.0-bundle.jar http://github.com/jponge/lzma-java/tree I guys, I developed this small LZMA compression library around the Java LZMA SDK. Thanks for considering uploading it :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-124) Dependency incorrectly reported as "Unused declared"
[
http://jira.codehaus.org/browse/MDEP-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188629#action_188629
]
Christian Schulte commented on MDEP-124:
Same happens with annotations @Retention(value=SOURCE).
{xml}
javax.annotation
jsr250-api
compile
true
{xml}
Using the @Generated annotation compilation fails without the dependency.
+1 for having the ability to configure the plugin to not print a warning in
such situations.
> Dependency incorrectly reported as "Unused declared"
>
>
> Key: MDEP-124
> URL: http://jira.codehaus.org/browse/MDEP-124
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Reporter: Olivier Dehon
>Assignee: Brian Fox
>
> When a dependency is only required for a constant in a JAR,
> dependency:analyze incorrectly reports the dependency as "Unused declared".
> Example:
> Constants.jar has 1 class called Constants.java:
> {code}
> package com.myco.util;
> public class Constants
> {
> private Constants() {};
> public static final double PI = 3.14159;
> }
> {code}
> Then App jar has App.java as:
> {code}
> package com.myco.app;
> public class App
> {
> public static void main( String[] args )
> {
> System.out.println( com.myco.util.Constants.PI );
> }
> }
> {code}
> Since the constant gets optimized away in the generated {{App.class}}, the
> dependency is not detected, even though the project won't compile without it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4325) [regression] Lifecycle overlay configuration of aggregator mojos is not properly processed when forking reactor
[regression] Lifecycle overlay configuration of aggregator mojos is not
properly processed when forking reactor
---
Key: MNG-4325
URL: http://jira.codehaus.org/browse/MNG-4325
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.2.1, 2.2.0, 2.1.0, 2.1.0-M1
Reporter: Benjamin Bentmann
Attachments: MNG-1073.log
See the attached log from the IT for MNG-1073 and note that the forked mojo
uses the same output directory for all three modules of the reactor, i.e. the
expression {{project.build.directory}} from the lifecycle overlay configuration
was not properly processed.
--
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: (MCHANGES-173) Failed to generate report when version is not the last schedule.
Failed to generate report when version is not the last schedule.
Key: MCHANGES-173
URL: http://jira.codehaus.org/browse/MCHANGES-173
Project: Maven 2.x Changes Plugin
Issue Type: Bug
Components: announcement, jira-report
Affects Versions: 2.1
Reporter: Christophe Lallement
Priority: Critical
We try to release a snapshot version (1.2.3-SNAPSHOT) but this version is not
define as last release into JIRA version.
into JIRA we have define version as this (by schedule order)
* 1.3.0
* 1.2.3
* 1.2.2
When we try to generate jira report for e version 1.2.3-SNAPSHOT we have this
error: (i don't if it occurs during jira report or annoucement)
PS: if i schedule 1.2.3 in first position into JIRa, it works fine.
{code}...
[DEBUG] Default ResourceManager initialization complete.
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Literal
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Include
[DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
[DEBUG] Created '20' parsers.
[DEBUG] Velocimacro : initialization starting.
[DEBUG] Velocimacro : allowInline = true : VMs can be defined inline in
templates
[DEBUG] Velocimacro : allowInlineToOverride = false : VMs defined inline may
NOT replace previous VM definitions
[DEBUG] Velocimacro : allowInlineLocal = false : VMs defined inline will be
global in scope if allowed.
[DEBUG] Velocimacro : autoload off : VM system will not automatically reload
global library macros
[DEBUG] Velocimacro : Velocimacro : initialization complete.
[DEBUG] RuntimeInstance successfully initialized.
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-changes-plugin:2.1:announcement-generate' -->
[DEBUG] (s) artifactId = feedapi
[DEBUG] (f) basedir = C:\HOMEWARE\eclipse-341\workspace\feedapi
[DEBUG] (s) developmentTeam = vol-domino-feedapi team
[DEBUG] (s) finalName = feedapi-1.2.3-SNAPSHOT
[DEBUG] (f) generateJiraAnnouncement = true
[DEBUG] (s) groupId = ged.domino
[DEBUG] (s) introduction = FeedAPI is a framework to send feed between
component (In and Out process) with high frequency const
aint
[DEBUG] (f) jiraMerge = false
[DEBUG] (f) jiraXML =
C:\HOMEWARE\eclipse-341\workspace\feedapi\target\jira-announcement.xml
[DEBUG] (f) maxEntries = 25
[DEBUG] (s) outputDirectory =
C:\HOMEWARE\eclipse-341\workspace\feedapi\target\announcement
[DEBUG] (s) packaging = jar
[DEBUG] (f) project = MavenProject: ged.domino:feedapi:1.2.3-SNAPSHOT @
C:\HOMEWARE\eclipse-341\workspace\feedapi\pom.xml
[DEBUG] (f) resolutionIds = Fixed
[DEBUG] (f) settings = org.apache.maven.settings.setti...@1eb62b6
[DEBUG] (f) statusIds = Closed
[DEBUG] (f) template = feedapi-announcement.vm
[DEBUG] (f) templateDirectory = our-announcements
[DEBUG] (s) url = http://frontools/maven_site/domino-parent/feedapi
[DEBUG] (s) version = 1.2.3-SNAPSHOT
[DEBUG] (s) xmlPath =
C:\HOMEWARE\eclipse-341\workspace\feedapi\src\changes\changes.xml
[DEBUG] -- end configuration --
[INFO] [changes:announcement-generate {execution: announcement-generate}]
[DEBUG] JIRA lives at: https://jtbox.fr.world.socgen/jira
[DEBUG] The JIRA URL https://jtbox.fr.world.socgen/jira/browse/TRAFEEDAPI
doesn't include a pid, trying to extract it from JIRA.
[DEBUG] Successfully reached JIRA.
26 ao¹t 2009 10:54:10 org.apache.commons.httpclient.HttpMethodBase
getResponseBody
ATTENTION: Going to buffer response body of large or unknown size. Using
getResponseBodyAsStream instead is recommended.
[DEBUG] Found the pid 10236 at
https://jtbox.fr.world.socgen/jira/browse/TRAFEEDAPI
[ERROR] maven-changes-plugin: None of the configured sortColumnNames 'null' are
correct.
[DEBUG] download jira issues from url
https://jtbox.fr.world.socgen/jira/secure/IssueNavigator.jspa?view=rss&pid=10236&statusIds=
&resolutionIds=1&tempMax=25&reset=true&decorator=none
[INFO] Downloading from JIRA at:
https://jtbox.fr.world.socgen/jira/secure/IssueNavigator.jspa?view=rss&pid=10236&statusIds=6&res
lutionIds=1&tempMax=25&reset=true&decorator=none
26 ao¹t 2009 10:54:10 org.apache.commons.httpclient.HttpMethodBase
getResponseBody
ATTENTION: Going to buffer response body of large or unknown size. Using
getResponseBodyAsStream instead is recommended.
[DEBUG] Downloading from JIRA was successful
[INFO] Creating announcement file from JIRA releases...
[DEBUG] Found 5 releases.
[DEBUG] The release: 1.1.0 has 1 actions.
[DEBUG] The release: 1.3.0 has 12 actions.
[DEBUG] The release: 1.2.1 has 6 actions.
[DEBUG] The release: 1.2.2 has 1 actions.
[DEBUG] The release: 1.2.0 has 4 actions.
[DEBUG] The release: 1.1.0 has 1 actions.
[DEBUG] The release: 1.3.0 has 12 ac
[jira] Commented: (MJAVADOC-224) CLONE -If Javadoc is set to aggregate, the build fails inside a Maven plugin module
[ http://jira.codehaus.org/browse/MJAVADOC-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188590#action_188590 ] Toni Menzel commented on MJAVADOC-224: -- +1 for re-opening this. We have failed site + releasebuilds when using maven-javadoc-plugin 2.4 + 2.5 in combination with mojos. Going back to 2.2 is a (temporary) solution. > CLONE -If Javadoc is set to aggregate, the build fails inside a Maven plugin > module > --- > > Key: MJAVADOC-224 > URL: http://jira.codehaus.org/browse/MJAVADOC-224 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Christian Schulte >Priority: Critical > Fix For: 2.4 > > > If your project contains a Maven plugin, then it is impossible to build > aggregated Javadoc. > As the output (attached) shows, Maven seems to recusively build (what's with > all those "skipping" messages?). When it reaches the plugin: > [INFO] Error during page generation > Embedded error: Error rendering Maven report: Error extracting plugin > descriptor: 'Goal: component-report already exists in the plugin descriptor > for prefix: tapestry-component-report > Existing implementation is: org.apache.tapestry.mojo.ComponentReport > Conflicting implementation is: org.apache.tapestry.mojo.ComponentReport' > I can get by this with the -fn (fail never) option. -- 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: (MSITE-425) No index.html generated
[ http://jira.codehaus.org/browse/MSITE-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lindelöf closed MSITE-425. Resolution: Not A Bug Ah this was the problem. I had configured the project-info-reports plugin to generate only some reports, and forgot to include the index. It works now, thanks. > No index.html generated > --- > > Key: MSITE-425 > URL: http://jira.codehaus.org/browse/MSITE-425 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0.1 >Reporter: David Lindelöf > > I have a pom project with several sub-modules. I have no site.xml nor any > index.* files. When I run mvn site, no index.html gets generated at all, > neither for the pom project nor for the sub-modules. Is this the normal > behavior? -- 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: (MJAR-20) Don't create empty jars
[
http://jira.codehaus.org/browse/MJAR-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=188581#action_188581
]
Rodrigo Ruiz commented on MJAR-20:
--
Hi Paul,
My patch adds a configuration option "createEmptyArchive" that can be set to
true for forcing the jar creation. I see two ways of preventing what you
describe:
1. Set the property default value to true. This means keeping the current
default behaviour, allowing the developer to modify it at will.
2. Forcing its value to true when the classifier is null (main jar). This means
changing the body of the isCreateEmptyArchive() method to:
protected boolean isCreateEmptyArchive() {
return createEmptyArchive || getClassifier() == null;
}
I would prefer the second option, because I think this is what most people
would expect as the default behaviour (no test jar if there are no tests).
> Don't create empty jars
> ---
>
> Key: MJAR-20
> URL: http://jira.codehaus.org/browse/MJAR-20
> Project: Maven 2.x Jar Plugin
> Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Carlos Sanchez
>Priority: Minor
> Attachments: MJAR-20-02.patch, MJAR-20.patch
>
>
> Creating empty jars is confusing, it should just print a warning
> use case:
> parent pom attaching test jar, some subprojects may not have tests, why
> create jars for them?
--
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
