[jira] Commented: (MRELEASE-173) Allow command line specification of versions
[ http://jira.codehaus.org/browse/MRELEASE-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131823#action_131823 ] Paul Gier commented on MRELEASE-173: Ok, I could add releaseVersion and devVersion as default versions which can be overridden by the more specific properties which include the groupId and artifactId. But being able to release a multi-module project with multiple versions is an important feature IMO. We currently have a project set up like that, so handling only single version releases would not help me. > Allow command line specification of versions > > > Key: MRELEASE-173 > URL: http://jira.codehaus.org/browse/MRELEASE-173 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-3, 2.0-beta-4, 2.0-beta-5 >Reporter: Chris Tucker >Assignee: Paul Gier > Fix For: 2.0-beta-8 > > Attachments: release-version.diff > > > It is convenient in a batchMode environment to specify the version to release > and the new version to update SNAPSHOT artifacts to. The attached patch > against maven-release-manager and maven-release-plugin provides the basic > functionality to allow this. > The maven-release-plugin will now accept two new arguments: > -DreleaseVersion= > -DdevVersion= > For example, to release version 1.2 of a project and move up to version > 2.0-SNAPSHOT one would issue: > $ mvn release:clean release:prepare -DreleaseVersion=1.2 -DdevVersion=2.0 > --batch-mode > This patch is against current trunk (471862). It currently doesn't support > resuming, so a release:clean is necessary if a previous release attempt has > been prepared. -- 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-285) Unresolved test-jar dependency during release
[ http://jira.codehaus.org/browse/MRELEASE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MRELEASE-285. -- Resolution: Fixed Fix Version/s: (was: 2.0-beta-8) 2.0 I believe this issue is now fixed with the release of the maven jar plugin 2.2. > Unresolved test-jar dependency during release > - > > Key: MRELEASE-285 > URL: http://jira.codehaus.org/browse/MRELEASE-285 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 > Environment: Maven version: 2.0.7 > Java version: 1.5.0_07 > OS name: "mac os x" version: "10.4.10" arch: "i386" >Reporter: Rod Coffin > Fix For: 2.0 > > Attachments: example.jar > > > I have a multi-module project where one project produces a normal jar and a > test-jar > (http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html). > Another submodule has a test scoped dependency on the test-jar from the first > submodule. For example, this is the structure and produced artifacts for a > small sample (attached) I built to reproduce this behavior: > release-test-jar (parent project) > project-with-test-jar (submodule) > => project-with-test-jar-1.0.jar > => project-with-test-jar-1.0-tests.jar > project-using-test-jar (submodule) > => project-user-test-jar-1.0.jar > When I run a 'clean install' the build succeeds. However, when I run a > 'release:prepare' the build fails with the following error: > 1 required artifact is missing. > for artifact: > com.rfc:project-using-test-jar:jar:1.1 > from the specified remote repositories: > central (http://repo1.maven.org/maven2) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) > 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:585) > 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) > Caused by: > org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: > Missing: > -- > 1) com.rfc:project-with-test-jar:test-jar:tests:1.1 > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=com.rfc > -DartifactId=project-with-test-jar \ > -Dversion=1.1 -Dclassifier=tests -Dpackaging=test-jar > -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file there: > mvn deploy:deploy-file -DgroupId=com.rfc > -DartifactId=project-with-test-jar \ > -Dversion=1.1 -Dclassifier=tests -Dpackaging=test-jar > -Dfile=/path/to/file \ >-Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.rfc:project-using-test-jar:jar:1.1 > 2) com.rfc:project-with-test-jar:test-jar:tests:1.1 > -- > 1 required artifact is missing. > for artifact: > com.rfc:project-using-test-jar:jar:1.1 > from the specified remote repositories: > central (http://repo1.maven.org/maven2) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:305) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) > at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) >
[jira] Updated: (MRELEASE-285) Unresolved test-jar dependency during release
[ http://jira.codehaus.org/browse/MRELEASE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MRELEASE-285: --- Fix Version/s: 2.0-beta-8 > Unresolved test-jar dependency during release > - > > Key: MRELEASE-285 > URL: http://jira.codehaus.org/browse/MRELEASE-285 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 > Environment: Maven version: 2.0.7 > Java version: 1.5.0_07 > OS name: "mac os x" version: "10.4.10" arch: "i386" >Reporter: Rod Coffin > Fix For: 2.0-beta-8 > > Attachments: example.jar > > > I have a multi-module project where one project produces a normal jar and a > test-jar > (http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html). > Another submodule has a test scoped dependency on the test-jar from the first > submodule. For example, this is the structure and produced artifacts for a > small sample (attached) I built to reproduce this behavior: > release-test-jar (parent project) > project-with-test-jar (submodule) > => project-with-test-jar-1.0.jar > => project-with-test-jar-1.0-tests.jar > project-using-test-jar (submodule) > => project-user-test-jar-1.0.jar > When I run a 'clean install' the build succeeds. However, when I run a > 'release:prepare' the build fails with the following error: > 1 required artifact is missing. > for artifact: > com.rfc:project-using-test-jar:jar:1.1 > from the specified remote repositories: > central (http://repo1.maven.org/maven2) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) > 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:585) > 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) > Caused by: > org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: > Missing: > -- > 1) com.rfc:project-with-test-jar:test-jar:tests:1.1 > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=com.rfc > -DartifactId=project-with-test-jar \ > -Dversion=1.1 -Dclassifier=tests -Dpackaging=test-jar > -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file there: > mvn deploy:deploy-file -DgroupId=com.rfc > -DartifactId=project-with-test-jar \ > -Dversion=1.1 -Dclassifier=tests -Dpackaging=test-jar > -Dfile=/path/to/file \ >-Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.rfc:project-using-test-jar:jar:1.1 > 2) com.rfc:project-with-test-jar:test-jar:tests:1.1 > -- > 1 required artifact is missing. > for artifact: > com.rfc:project-using-test-jar:jar:1.1 > from the specified remote repositories: > central (http://repo1.maven.org/maven2) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:305) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) > at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > Judging from the sta
[jira] Issue Comment Edited: (MRELEASE-173) Allow command line specification of versions
[ http://jira.codehaus.org/browse/MRELEASE-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131818#action_131818 ] genman edited comment on MRELEASE-173 at 4/22/08 10:30 PM: --- Requiring groupId and artifactId for the use case of single version releases just complicates writing scripts and using build tools. I'm against what Paul suggests, or at least I'm for a single-version solution. And honestly, I never understood the use case of releasing multiple artifacts with different versions, which just sounds like it would cause trouble. Have you seen any automated build tools that would simultaneously build a single project with N different sub versions? was (Author: genman): Requiring groupId and artifactId for the use case of single version releases just complicates writing scripts and using build tools. I'm against what Paul suggests, or at least I'm for a single-version solution. And honestly, I never understood the use case of releasing multiple artifacts with different versions, which just sounds like it would cause trouble. Have you seen any build tools that would support building a project with N different sub versions? There's now 17 votes for this trivial feature and so I wonder why nobody's taken it on... > Allow command line specification of versions > > > Key: MRELEASE-173 > URL: http://jira.codehaus.org/browse/MRELEASE-173 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-3, 2.0-beta-4, 2.0-beta-5 >Reporter: Chris Tucker >Assignee: Paul Gier > Fix For: 2.0-beta-8 > > Attachments: release-version.diff > > > It is convenient in a batchMode environment to specify the version to release > and the new version to update SNAPSHOT artifacts to. The attached patch > against maven-release-manager and maven-release-plugin provides the basic > functionality to allow this. > The maven-release-plugin will now accept two new arguments: > -DreleaseVersion= > -DdevVersion= > For example, to release version 1.2 of a project and move up to version > 2.0-SNAPSHOT one would issue: > $ mvn release:clean release:prepare -DreleaseVersion=1.2 -DdevVersion=2.0 > --batch-mode > This patch is against current trunk (471862). It currently doesn't support > resuming, so a release:clean is necessary if a previous release attempt has > been prepared. -- 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-173) Allow command line specification of versions
[ http://jira.codehaus.org/browse/MRELEASE-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131818#action_131818 ] Elias Ross commented on MRELEASE-173: - Requiring groupId and artifactId for the use case of single version releases just complicates writing scripts and using build tools. I'm against what Paul suggests, or at least I'm for a single-version solution. And honestly, I never understood the use case of releasing multiple artifacts with different versions, which just sounds like it would cause trouble. Have you seen any build tools that would support building a project with N different sub versions? There's now 17 votes for this trivial feature and so I wonder why nobody's taken it on... > Allow command line specification of versions > > > Key: MRELEASE-173 > URL: http://jira.codehaus.org/browse/MRELEASE-173 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-3, 2.0-beta-4, 2.0-beta-5 >Reporter: Chris Tucker >Assignee: Paul Gier > Fix For: 2.0-beta-8 > > Attachments: release-version.diff > > > It is convenient in a batchMode environment to specify the version to release > and the new version to update SNAPSHOT artifacts to. The attached patch > against maven-release-manager and maven-release-plugin provides the basic > functionality to allow this. > The maven-release-plugin will now accept two new arguments: > -DreleaseVersion= > -DdevVersion= > For example, to release version 1.2 of a project and move up to version > 2.0-SNAPSHOT one would issue: > $ mvn release:clean release:prepare -DreleaseVersion=1.2 -DdevVersion=2.0 > --batch-mode > This patch is against current trunk (471862). It currently doesn't support > resuming, so a release:clean is necessary if a previous release attempt has > been prepared. -- 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-321) Add support for -DdevelopmentVersion and -DreleaseVersion to facilitate command line configuration
[ http://jira.codehaus.org/browse/MRELEASE-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MRELEASE-321: --- Fix Version/s: 2.0-beta-8 > Add support for -DdevelopmentVersion and -DreleaseVersion to facilitate > command line configuration > -- > > Key: MRELEASE-321 > URL: http://jira.codehaus.org/browse/MRELEASE-321 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-7 >Reporter: Christian Nelson > Fix For: 2.0-beta-8 > > > We're about to start using the maven-release-plugin on a large project for > both branching and releasing. We found a few things that would be nice to > pass in as arguments on the command line so that the process doesn't require > user interaction. I looked to see if this was already possible and came up > blank. > *Scenario 1*: release:branch needs two pieces of information: (a) the branch > name and (b) the "new working copy version". The former can be specified > using -DbranchName but the latter isn't documented. Is there a way to > specify the new working copy version on the command line? Ideally I'd be > able to do something like this: > | $ mvn release:branch -DbranchName=release-3.1 -DdevelopmentVersion= > 3.2-SNAPSHOT > *Scenario 2*: release:prepare needs three pieces of information: (a) the > release version, (b) the release scm tag, and (c) the new development > version. According to the documentation, only the tag can be specified on the > command line using -Dtag=wombat. What about the others? > | $ mvn release:prepare -DreleaseVersion=3.1 > -Dtag=release-3.1.0-DdevelopmentVersion=3.1.1-SNAPSHOT > Note we're also using -DautoVersionSubmodules=true, which is what gets us > pretty far in being able to fire these things off in a single shot without > user interaction. > I've been meaning to code up a fix so that I can submit it with this issue, > but haven't had the time yet. I hope to find the time soon, but in the mean > time would like some feedback on the idea (e.g. is there a way to do it > already?). -- 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-100) implement release:release goal
[ http://jira.codehaus.org/browse/MRELEASE-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131814#action_131814 ] Paul Gier commented on MRELEASE-100: Arkady, you should be able to set the tag with -Dtag=my-tag on the command line. > implement release:release goal > -- > > Key: MRELEASE-100 > URL: http://jira.codehaus.org/browse/MRELEASE-100 > Project: Maven 2.x Release Plugin > Issue Type: New Feature >Reporter: Brett Porter > > a release:release goal has been requested that sequentially does the prepare > and then perform step. Generally, this would be done in batch mode to do > overnight tags/release combos using the defaults -- 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-173) Allow command line specification of versions
[ http://jira.codehaus.org/browse/MRELEASE-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131811#action_131811 ] Paul Gier commented on MRELEASE-173: I took a different approach than what was in the patch, since the patch was out of date and only handled single version releases. To set the release version from the command line, you now have to use project.rel or project.dev and the groupId and artifactId. So you end up with something like this: mvn --batch-mode -Dtag=my-proj-1.2 -Dproject.rel.org.myCompany:projectA=1.2 \ -Dproject.dev.org.myCompany:projectA=1.3-SNAPSHOT release:prepare This allows multiple versions to be passed for a multi-module release. There is now an example for this in the site docs in svn. > Allow command line specification of versions > > > Key: MRELEASE-173 > URL: http://jira.codehaus.org/browse/MRELEASE-173 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-3, 2.0-beta-4, 2.0-beta-5 >Reporter: Chris Tucker >Assignee: Paul Gier > Fix For: 2.0-beta-8 > > Attachments: release-version.diff > > > It is convenient in a batchMode environment to specify the version to release > and the new version to update SNAPSHOT artifacts to. The attached patch > against maven-release-manager and maven-release-plugin provides the basic > functionality to allow this. > The maven-release-plugin will now accept two new arguments: > -DreleaseVersion= > -DdevVersion= > For example, to release version 1.2 of a project and move up to version > 2.0-SNAPSHOT one would issue: > $ mvn release:clean release:prepare -DreleaseVersion=1.2 -DdevVersion=2.0 > --batch-mode > This patch is against current trunk (471862). It currently doesn't support > resuming, so a release:clean is necessary if a previous release attempt has > been prepared. -- 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-3541) Better JIRA organization
Better JIRA organization Key: MNG-3541 URL: http://jira.codehaus.org/browse/MNG-3541 Project: Maven 2 Issue Type: Improvement Components: Artifacts and Repositories, Errors, Sites & Reporting Reporter: Diego Plentz Priority: Critical Looking at codehaus jira, its a pain to find where you must open an issue. Look. If its a problem in repository, I must open where? - http://jira.codehaus.org/browse/MNG > Artifacts and Repositories - http://jira.codehaus.org/browse/MAVENREPOMAINT - http://jira.codehaus.org/browse/MEV - http://jira.codehaus.org/browse/MPA > repository management Or, if its a problem with the site? - http://jira.codehaus.org/browse/MNG > Sites & Reporting - http://jira.codehaus.org/browse/MNGSITE - http://jira.codehaus.org/browse/MPA > sites Cutting off some projects is a good start. -- 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-2030) Please upload maven-license-plugin 1.3.0
Please upload maven-license-plugin 1.3.0 Key: MAVENUPLOAD-2030 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2030 Project: maven-upload-requests Issue Type: Wish Reporter: Mathieu Carbou Attachments: maven-license-plugin-1.3.0-bundle.jar Hi, I am de project leader of maven-license-plugin. Please upload version 1.3.0. -- 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-173) Allow command line specification of versions
[ http://jira.codehaus.org/browse/MRELEASE-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MRELEASE-173: --- Assignee: Paul Gier Fix Version/s: 2.0-beta-8 Patch Submitted: [Yes] > Allow command line specification of versions > > > Key: MRELEASE-173 > URL: http://jira.codehaus.org/browse/MRELEASE-173 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-3, 2.0-beta-4, 2.0-beta-5 >Reporter: Chris Tucker >Assignee: Paul Gier > Fix For: 2.0-beta-8 > > Attachments: release-version.diff > > > It is convenient in a batchMode environment to specify the version to release > and the new version to update SNAPSHOT artifacts to. The attached patch > against maven-release-manager and maven-release-plugin provides the basic > functionality to allow this. > The maven-release-plugin will now accept two new arguments: > -DreleaseVersion= > -DdevVersion= > For example, to release version 1.2 of a project and move up to version > 2.0-SNAPSHOT one would issue: > $ mvn release:clean release:prepare -DreleaseVersion=1.2 -DdevVersion=2.0 > --batch-mode > This patch is against current trunk (471862). It currently doesn't support > resuming, so a release:clean is necessary if a previous release attempt has > been prepared. -- 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-2319) strange issue when trying to generate a site which uses the multi project and assembly stuff
[ http://jira.codehaus.org/browse/MNG-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131776#action_131776 ] aka3 edited comment on MNG-2319 at 4/22/08 4:12 PM: --- My experience is that install and site cannot be a one-liner mvn clean install site can fail. The site instruction seems to require dependencies before they are build (installed) So have you never build the software before the site command will try to download the nested artifacts ... and ofcause not find them. The version used was: version 2.0.5 Changing it to mvn clean install mvn site will work. was (Author: aka3): My experience is that install and site cannot be a one-liner mvn clean install site can fail. The site instruction seems to require dependencies before they are build (installed) So have you never build the software before the site command will try to download the nested artifacts ... and ofcause not find them. Changing it to mvn clean install mvn site will work. > strange issue when trying to generate a site which uses the multi project and > assembly stuff > > > Key: MNG-2319 > URL: http://jira.codehaus.org/browse/MNG-2319 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: james strachan > Fix For: 2.0.x > > > Grab a checkout of ActiveMQ and try > mvn clean install site:site -Dmaven.test.skip=true > And you get this - which seems to be related to maven's insistence on > rebuilding everything again when it tries to build the 'assembly' module. > [INFO] Preparing assembly:assembly > [INFO] > > [INFO] Building ActiveMQ > [INFO] > > [INFO] Skipping missing optional mojo: > org.apache.maven.plugins:maven-site-plugin:attach-descriptor > [INFO] No goals needed for project - skipping > [INFO] > > [INFO] Building ActiveMQ :: JAAS > [INFO] > > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.artifact.ArtifactUtils.copyArtifact(ArtifactUtils.java:109) > at org.apache.maven.project.MavenProject.(MavenProject.java:251) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:886) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:729) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:505) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > 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:585) > 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] - > If you try just to make the site via > mvn clean site:site -Dmaven.test.skip=true > then you get... > [INFO] >
[jira] Issue Comment Edited: (MNG-2319) strange issue when trying to generate a site which uses the multi project and assembly stuff
[ http://jira.codehaus.org/browse/MNG-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131776#action_131776 ] aka3 edited comment on MNG-2319 at 4/22/08 4:10 PM: --- My experience is that install and site cannot be a one-liner mvn clean install site can fail. The site instruction seems to require dependencies before they are build (installed) So have you never build the software before the site command will try to download the nested artifacts ... and ofcause not find them. Changing it to mvn clean install mvn site will work. was (Author: aka3): My experience is that install and site cannot be a one-liner mvn clean install site can fail. The site instruction seems to require dependencies before they are build (installed) Changing it to mvn clean install mvn site will work. > strange issue when trying to generate a site which uses the multi project and > assembly stuff > > > Key: MNG-2319 > URL: http://jira.codehaus.org/browse/MNG-2319 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: james strachan > Fix For: 2.0.x > > > Grab a checkout of ActiveMQ and try > mvn clean install site:site -Dmaven.test.skip=true > And you get this - which seems to be related to maven's insistence on > rebuilding everything again when it tries to build the 'assembly' module. > [INFO] Preparing assembly:assembly > [INFO] > > [INFO] Building ActiveMQ > [INFO] > > [INFO] Skipping missing optional mojo: > org.apache.maven.plugins:maven-site-plugin:attach-descriptor > [INFO] No goals needed for project - skipping > [INFO] > > [INFO] Building ActiveMQ :: JAAS > [INFO] > > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.artifact.ArtifactUtils.copyArtifact(ArtifactUtils.java:109) > at org.apache.maven.project.MavenProject.(MavenProject.java:251) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:886) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:729) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:505) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > 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:585) > 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] - > If you try just to make the site via > mvn clean site:site -Dmaven.test.skip=true > then you get... > [INFO] > > [INFO] Building ActiveMQ :: Assembly > [INFO]task-segment: [clean, site:site] > [INFO] >
[jira] Commented: (MNG-2319) strange issue when trying to generate a site which uses the multi project and assembly stuff
[ http://jira.codehaus.org/browse/MNG-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131776#action_131776 ] Anders Kr. Andersen commented on MNG-2319: -- My experience is that install and site cannot be a one-liner mvn clean install site can fail. The site instruction seems to require dependencies before they are build (installed) Changing it to mvn clean install mvn site will work. > strange issue when trying to generate a site which uses the multi project and > assembly stuff > > > Key: MNG-2319 > URL: http://jira.codehaus.org/browse/MNG-2319 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: james strachan > Fix For: 2.0.x > > > Grab a checkout of ActiveMQ and try > mvn clean install site:site -Dmaven.test.skip=true > And you get this - which seems to be related to maven's insistence on > rebuilding everything again when it tries to build the 'assembly' module. > [INFO] Preparing assembly:assembly > [INFO] > > [INFO] Building ActiveMQ > [INFO] > > [INFO] Skipping missing optional mojo: > org.apache.maven.plugins:maven-site-plugin:attach-descriptor > [INFO] No goals needed for project - skipping > [INFO] > > [INFO] Building ActiveMQ :: JAAS > [INFO] > > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.artifact.ArtifactUtils.copyArtifact(ArtifactUtils.java:109) > at org.apache.maven.project.MavenProject.(MavenProject.java:251) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:886) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:729) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:505) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > 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:585) > 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] - > If you try just to make the site via > mvn clean site:site -Dmaven.test.skip=true > then you get... > [INFO] > > [INFO] Building ActiveMQ :: Assembly > [INFO]task-segment: [clean, site:site] > [INFO] > > [INFO] snapshot incubator-activemq:maven-bundle-plugin:4.0-SNAPSHOT: checking > for updates from codehaus.snapshots > [INFO] snapshot incubator-activemq:maven-bundle-plugin:4.0-SNAPSHOT: checking > for updates from maven-csharp-plugins > [WARNING] *** CHECKSUM FAILED - Invalid checksum file - RETRYING > [WARNING] *** CHECKSUM FAILED - Invalid checksum file -
[jira] Commented: (MPXDOC-206) Including DTD breaks xdoc
[ http://jira.codehaus.org/browse/MPXDOC-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131774#action_131774 ] Lukas Theussl commented on MPXDOC-206: -- If you don't attach a small test case I will close this as 'Cannot reproduce', it works for me. > Including DTD breaks xdoc > -- > > Key: MPXDOC-206 > URL: http://jira.codehaus.org/browse/MPXDOC-206 > Project: Maven 1.x XDoc Plugin > Issue Type: Bug >Affects Versions: 1.10.1 > Environment: WindowsXP SP2 x86, JDK6 build 1.6.0_05-b13 >Reporter: Gregor B. Rosenauer >Priority: Minor > Attachments: error-report.txt > > > When including the XDoc-DTD as mentioned in issue MPXDOC-192 site generation > fails with a Jelly-Exception. > I cannot say if this is an issue with the xdoc-plugin or with jelly. > My document starts with > >"http://maven.apache.org/dtd/xdoc_1_0.dtd";> > When invoking the goal xdoc:generate-from-pom (called through a custom goal > ta30:doku) I get a Jelly-Exception (full report attached): > Caused by: org.apache.commons.jelly.JellyTagException: file:C:/Dokumente und > Einstellungen/Orth/.maven/cache/maven-xdoc-plugin-1.10.1/plugin-resources/sitemap.jsl:84:51: > Connection timed out: connect Nested exception: Connection t > imed out: connect > at > org.apache.commons.jelly.tags.xml.ParseTagSupport.parse(ParseTagSuppo > rt.java:186) > at > org.apache.commons.jelly.tags.xml.ParseTag.getXmlDocument(ParseTag.ja > va:106) > at org.apache.commons.jelly.tags.xml.ParseTag.doTag(ParseTag.java:55) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) > at > org.apache.commons.jelly.tags.util.AvailableTag.doTag(AvailableTag.ja > va:68) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) > at > org.apache.commons.jelly.tags.jsl.TemplateTag$1.run(TemplateTag.java: > 160) > at org.dom4j.rule.Mode.fireRule(Mode.java:59) > at org.dom4j.rule.Stylesheet.applyTemplates(Stylesheet.java:185) > at org.dom4j.rule.Stylesheet.applyTemplates(Stylesheet.java:159) > at > org.apache.commons.jelly.tags.jsl.ApplyTemplatesTag.doTag(ApplyTempla > tesTag.java:67) > ... 112 more > Caused by: org.dom4j.DocumentException: Connection timed out: connect Nested > exc > eption: Connection timed out: connect > at org.dom4j.io.SAXReader.read(SAXReader.java:484) > at org.dom4j.io.SAXReader.read(SAXReader.java:264) > at > org.apache.commons.jelly.tags.xml.ParseTagSupport.parse(ParseTagSuppo > rt.java:168) > ... 126 more > Leaving out the DTD "fixes" the issue, but then I cannot edit the xdoc-file > in an XML-editor like the excellent visual XMLmind-editor (with > xdoc-type-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] Created: (MNG-3540) No plugin update from a staged repository
No plugin update from a staged repository - Key: MNG-3540 URL: http://jira.codehaus.org/browse/MNG-3540 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.9 Environment: Maven 2.0.9, JDK6, both linux and windows Reporter: Raphaël Piéroni Attachments: with-nexus.txt, with-profile.txt The archetype plugin depends on other projects. One of them is staged along with the plugin in a staged repository. When i define that repository in settings.xml in a profile which is always activated (both repository and pluginRepository) and remove all references from archetype in my local repository. I then call mvn archetype:create-from-project. Maven downloads the plugin but don't download the dependencies there it fails to instantiate the first used class from these dependencies. The first attachment (with-profile.txt) holds the trace When i define the repository in nexus (grouping first the repository then central in one url) and defining that url as mirror of central in my setting, Also using a fresh repository. I call the same goal, and it works. The second attachment (with-nexus.txt) holds the trace. -- 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: (DOXIASITETOOLS-10) Adds test for docbook module
[ http://jira.codehaus.org/browse/DOXIASITETOOLS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIASITETOOLS-10. --- Assignee: Lukas Theussl Resolution: Fixed Fix Version/s: 1.0-beta-1 Applied in r650618, thanks! > Adds test for docbook module > > > Key: DOXIASITETOOLS-10 > URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-10 > Project: Maven Doxia Site Tools > Issue Type: Test > Components: Site renderer >Reporter: Max Berger >Assignee: Lukas Theussl > Fix For: 1.0-beta-1 > > Attachments: docbookTest.patch > > > This patch adds an assertion to check if a docbook page could be rendered. > Background: Maven 2.0.9 fails to render docbook pages on OS X, and I tried > reproducing this with this testcase. Unfortunately I was unable to reprocude > the error: doxia-site-tools always generates the page as it should -> Looks > like I'll have to wait for maven to use the newer doxia version. -- 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-77) Add new option to resolve snapshot dependencies when deploying
Add new option to resolve snapshot dependencies when deploying -- Key: MDEPLOY-77 URL: http://jira.codehaus.org/browse/MDEPLOY-77 Project: Maven 2.x Deploy Plugin Issue Type: New Feature Reporter: Paul Gier It would be helpful in certain cases to tie a snapshot deployment to certain snapshot dependencies. For example, I have a dependency on project A version 1.0-SNAPSHOT. When my project is deployed, I would like this to be resolved to the specific snapshot used during the build. So something like (1.0-20080201.133452-3). This way I can see exactly which dependency build was used during the build of my 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: (MNG-3539) Report plugins with inherited=false dropped by profile injector
[
http://jira.codehaus.org/browse/MNG-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-3539:
---
Attachment: MNG-3539.patch
Failing IT
> Report plugins with inherited=false dropped by profile injector
> ---
>
> Key: MNG-3539
> URL: http://jira.codehaus.org/browse/MNG-3539
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation, Profiles
>Affects Versions: 2.0.9
>Reporter: Benjamin Bentmann
>Priority: Minor
> Attachments: MNG-3539.patch, reporting-profile-merge.patch
>
>
> Consider the following POM snippet:
> {code:xml}
>
>
>
> org.apache.maven.plugins
> maven-surefire-report-plugin
> 2.3
> false
>
>
>
>
>
> extended-site
>
> ... some other plugins but excluding the surefire-report-plugin
>
>
>
> {code}
> When running "mvn site -P extended-site", the Surefire Report Plugin will be
> excluded from the site output.
> For some reason, the {{DefaultProfileInjector}} is dropping plugins which
> have {{inherited=false}}. Inheritance shouldn't matter here, it's all about
> the same POM, no parent-child play.
> Attached is a unit test to show the failure. An IT will follow now that I
> have the JIRA ticket.
--
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-316) useProjectArtifact is documented but not in schema
[ http://jira.codehaus.org/browse/MASSEMBLY-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131739#action_131739 ] Thomas Diesler commented on MASSEMBLY-316: -- [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-2:directory' --> [DEBUG] (s) appendAssemblyId = false [DEBUG] (f) attach = true [DEBUG] (s) basedir = /home/tdiesler/svn/jbossws/stack/cxf/branches/tdiesler/trunk [DEBUG] (s) descriptors = [Ljava.lang.String;@10e8647 [DEBUG] (f) dryRun = false [DEBUG] (f) executedProject = MavenProject: org.jboss.ws:jbossws-cxf:3.0.2-SNAPSHOT @ /home/tdiesler/svn/jbossws/stack/cxf/branches/tdiesler/trunk/pom.xml [DEBUG] (s) finalName = deploy-structure-jboss422 [DEBUG] (f) ignoreDirFormatExtensions = true [DEBUG] (s) ignoreMissingDescriptor = false [DEBUG] (s) includeSite = false [DEBUG] (s) localRepository = [local] -> file:///home/tdiesler/.m2/repository [DEBUG] (s) outputDirectory = /home/tdiesler/svn/jbossws/stack/cxf/branches/tdiesler/trunk/target [DEBUG] (s) reactorProjects = [MavenProject: org.jboss.ws:jbossws-cxf:3.0.2-SNAPSHOT @ /home/tdiesler/svn/jbossws/stack/cxf/branches/tdiesler/trunk/pom.xml, MavenProject: org.jboss.ws:jbossws-cxf-client:3.0.2-SNAPSHOT @ /home/tdiesler/svn/jbossws/stack/cxf/branches/tdiesler/trunk/modules/client/pom.xml] [DEBUG] (f) remoteRepositories = [[snapshots.jboss.org] -> http://snapshots.jboss.org/maven2, [repository.jboss.org] -> http://repository.jboss.org/maven2, [apache.incubating.repository] -> http://people.apache.org/repo/m2-incubating-repository, [java.net] -> http://download.java.net/maven/1/, [central] -> http://repo1.maven.org/maven2] [DEBUG] (s) siteDirectory = /home/tdiesler/svn/jbossws/stack/cxf/branches/tdiesler/trunk/target/site [DEBUG] (f) skipAssembly = false [DEBUG] (s) tarLongFileMode = warn [DEBUG] (s) tempRoot = /home/tdiesler/svn/jbossws/stack/cxf/branches/tdiesler/trunk/target/archive-tmp [DEBUG] (s) workDirectory = /home/tdiesler/svn/jbossws/stack/cxf/branches/tdiesler/trunk/target/assembly/work > useProjectArtifact is documented but not in schema > -- > > Key: MASSEMBLY-316 > URL: http://jira.codehaus.org/browse/MASSEMBLY-316 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Reporter: Thomas Diesler > > I like to include a module's dependencies, but not the projectArtifact > itself. This functionality seem to be provided by 'useProjectArtifact' > http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html > which is not defined in > http://maven.apache.org/xsd/assembly-1.1.0-SNAPSHOT.xsd > and does not seem to work anymore. -- 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: (MASSEMBLY-316) useProjectArtifact is documented but not in schema
useProjectArtifact is documented but not in schema -- Key: MASSEMBLY-316 URL: http://jira.codehaus.org/browse/MASSEMBLY-316 Project: Maven 2.x Assembly Plugin Issue Type: Bug Reporter: Thomas Diesler I like to include a module's dependencies, but not the projectArtifact itself. This functionality seem to be provided by 'useProjectArtifact' http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html which is not defined in http://maven.apache.org/xsd/assembly-1.1.0-SNAPSHOT.xsd and does not seem to work anymore. -- 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-315) outputFileNameMapping in dependencySet uses pom's artifactid
[
http://jira.codehaus.org/browse/MASSEMBLY-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131738#action_131738
]
Thomas Diesler commented on MASSEMBLY-315:
--
With this config
server/default/lib
true
false
*:jaxws-api:jar
*:jbossws-common:jar
*:jbossws-framework:jar
*:jbossws-spi:jar
*:saaj-api:jar
I get
[EMAIL PROTECTED] trunk]$ ls
target/deploy-structure-jboss422/server/default/lib/
jaxws-api-2.0.jar
jbossws-framework-3.0.2-20080418.213730-13.jar saaj-api-1.3.jar
jbossws-common-3.0.0-20080419.202718-10.jar
jbossws-spi-3.0.0-20080418.213543-7.jar
as expected, but I don't want the version extensions.
> outputFileNameMapping in dependencySet uses pom's artifactid
>
>
> Key: MASSEMBLY-315
> URL: http://jira.codehaus.org/browse/MASSEMBLY-315
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Reporter: Thomas Diesler
>
> The descriptor below incorrectly produces a single output file in
> server/default/lib
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/assembly-1.1.0-SNAPSHOT.xsd";>
>
> deploy-structure-jboss422
>
> dir
>
> false
>
>
>
>
>
> bin
> true
> true
>
> *:jbossws-framework:zip:scripts
>
>
>
>
>
> server/default/lib
>
> ${artifactId}.${extension}
> true
> false
>
> *:jaxws-api:jar
> *:jbossws-common:jar
> *:jbossws-framework:jar
> *:jbossws-spi:jar
> *:saaj-api:jar
>
>
>
>
>
>
>
>
> org.jboss.ws:jbossws-cxf-client
>
>
> client
>
> ${module.artifactId}.${module.extension}
> false
>
>
>
> ${module.artifactId}.${module.extension}
> true
>
> *:cxf-*
> *:geronimo-javamail*
> *:geronimo-ws-metadata*
> *:jaxb-api:jar
> *:jaxb-impl:jar
> *:jaxb-xjc:jar
> *:jaxws-api:jar
> *:jbossws-common:jar
> *:jbossws-framework:jar
> *:jbossws-spi:jar
> *:neethi:jar
> *:saaj-api:jar
> *:saaj-impl:jar
> *:spring-beans:jar
> *:spring-context:jar
> *:spring-core:jar
> *:stax-api:jar
> *:wsdl4j:jar
> *:xml-resolver:jar
> *:XmlSchema:jar
>
>
>
> wstx.jar
> true
>
> *:wstx-asl:jar
>
>
>
>
>
>
>
>
> [EMAIL PROTECTED] trunk]$ ls
> target/deploy-structure-jboss422/server/default/lib/
> jbossws-cxf.${extension}
--
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: (MASSEMBLY-315) outputFileNameMapping in dependencySet uses pom's artifactid
outputFileNameMapping in dependencySet uses pom's artifactid
Key: MASSEMBLY-315
URL: http://jira.codehaus.org/browse/MASSEMBLY-315
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Reporter: Thomas Diesler
The descriptor below incorrectly produces a single output file in
server/default/lib
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/assembly-1.1.0-SNAPSHOT.xsd";>
deploy-structure-jboss422
dir
false
bin
true
true
*:jbossws-framework:zip:scripts
server/default/lib
${artifactId}.${extension}
true
false
*:jaxws-api:jar
*:jbossws-common:jar
*:jbossws-framework:jar
*:jbossws-spi:jar
*:saaj-api:jar
org.jboss.ws:jbossws-cxf-client
client
${module.artifactId}.${module.extension}
false
${module.artifactId}.${module.extension}
true
*:cxf-*
*:geronimo-javamail*
*:geronimo-ws-metadata*
*:jaxb-api:jar
*:jaxb-impl:jar
*:jaxb-xjc:jar
*:jaxws-api:jar
*:jbossws-common:jar
*:jbossws-framework:jar
*:jbossws-spi:jar
*:neethi:jar
*:saaj-api:jar
*:saaj-impl:jar
*:spring-beans:jar
*:spring-context:jar
*:spring-core:jar
*:stax-api:jar
*:wsdl4j:jar
*:xml-resolver:jar
*:XmlSchema:jar
wstx.jar
true
*:wstx-asl:jar
[EMAIL PROTECTED] trunk]$ ls
target/deploy-structure-jboss422/server/default/lib/
jbossws-cxf.${extension}
--
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: (MINVOKER-22) Add feature to install plugin to a local repository.
[ http://jira.codehaus.org/browse/MINVOKER-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MINVOKER-22. - Resolution: Fixed Added site docs. > Add feature to install plugin to a local repository. > > > Key: MINVOKER-22 > URL: http://jira.codehaus.org/browse/MINVOKER-22 > Project: Maven 2.x Invoker Plugin > Issue Type: New Feature >Affects Versions: 1.1 >Reporter: Paul Gier >Assignee: Paul Gier > Fix For: 1.2 > > Attachments: MINVOKER-22-install-artifacts.patch > > > Currently if I want to test a maven plugin, I have to use the install plugin > to install the jar into a temporary repository location. It would be helpful > if there was a way that the invoker plugin could do this by itself instead of > needing to use the install 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] Reopened: (MINVOKER-22) Add feature to install plugin to a local repository.
[ http://jira.codehaus.org/browse/MINVOKER-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier reopened MINVOKER-22: --- Assignee: Paul Gier (was: Olivier Lamy) Re-opening to add some documentation for the new feature. > Add feature to install plugin to a local repository. > > > Key: MINVOKER-22 > URL: http://jira.codehaus.org/browse/MINVOKER-22 > Project: Maven 2.x Invoker Plugin > Issue Type: New Feature >Affects Versions: 1.1 >Reporter: Paul Gier >Assignee: Paul Gier > Fix For: 1.2 > > Attachments: MINVOKER-22-install-artifacts.patch > > > Currently if I want to test a maven plugin, I have to use the install plugin > to install the jar into a temporary repository location. It would be helpful > if there was a way that the invoker plugin could do this by itself instead of > needing to use the install 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] Commented: (MSITE-297) Child site.xml not used from parent + inheritance
[ http://jira.codehaus.org/browse/MSITE-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131725#action_131725 ] Rodrigo Ruiz commented on MSITE-297: This is a very annoying one. In one of my multi-module projects, with 5 child projects I have to do: [at parent] mvn site site:deploy [at child 1] mvn clean site site:deploy ... [at child 5] mvn clean site site:deploy Each sub-project has its own unit and integration testsuites, and the sites include cobertura and findbugs reports, which make the process of deploying a site extremely slow. > Child site.xml not used from parent + inheritance > - > > Key: MSITE-297 > URL: http://jira.codehaus.org/browse/MSITE-297 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module >Affects Versions: 2.0-beta-6 >Reporter: Ramon Havermans > > When using a parent child project building from the parent, the child > site.xml is not used. Instead I get the parent lay-out with menu's I don't > want and links that won't 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] Issue Comment Edited: (MPIR-35) Site Plugin should work from Template. Plugin Should not generate Markup from Java
[ http://jira.codehaus.org/browse/MPIR-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131722#action_131722 ] nodens2k edited comment on MPIR-35 at 4/22/08 9:13 AM: --- Having the ability to specify custom templates for the reports would be great. Much better than just the message properties. For example, I would like to merge the Organisation and Organisation URL columns of the Projet Team report into a single column with a link to the URL using the Organisation name as the link text (I don't know why it is not so). Such changes would be very easy to do with templates. BTW, custom templates would be a valid solution for issues MPIR-78, MPIR-86, MPIR-94 and MPIR-97. was (Author: nodens2k): Having the ability to specify custom templates for the reports would be great. Much better than just the message properties. BTW, custom templates would be a valid solution for issues MPIR-78, MPIR-86, MPIR-94 and MPIR-97. > Site Plugin should work from Template. Plugin Should not generate Markup > from Java > --- > > Key: MPIR-35 > URL: http://jira.codehaus.org/browse/MPIR-35 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: New Feature >Reporter: Tim O'Brien > Fix For: 2.x > > Attachments: maven-project-info-reports.patch, project-info-itest.zip > > > The site plugin currently generates markup from Java. There is logic in the > team list report that prints HTML and Javascript directly to a StringBuffer > and there is no facility for customization. Because of this, every single > site that uses the project info reports ends up with the same text. Google > for the text of the team-list plugin and there are at least 18,000 matching > pages. > There needs to be a facility for customization. I propose that the default > report is published from a velocity template loaded form the classpath, but > the site plugin checks for the presence of an overriding velocity template in > a know path (or from a URL). -- 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: (MPIR-35) Site Plugin should work from Template. Plugin Should not generate Markup from Java
[ http://jira.codehaus.org/browse/MPIR-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131722#action_131722 ] nodens2k edited comment on MPIR-35 at 4/22/08 9:10 AM: --- Having the ability to specify custom templates for the reports would be great. Much better than just the message properties. BTW, custom templates would be a valid solution for issues MPIR-78, MPIR-86, MPIR-94 and MPIR-97. was (Author: nodens2k): Having the ability to specify custom templates for the reports would be great. Much better than just the message properties. BTW, custom templates would be valid solutions for issues MPIR-78 MPIR-86 MPIR94 and MPIR-97. > Site Plugin should work from Template. Plugin Should not generate Markup > from Java > --- > > Key: MPIR-35 > URL: http://jira.codehaus.org/browse/MPIR-35 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: New Feature >Reporter: Tim O'Brien > Fix For: 2.x > > Attachments: maven-project-info-reports.patch, project-info-itest.zip > > > The site plugin currently generates markup from Java. There is logic in the > team list report that prints HTML and Javascript directly to a StringBuffer > and there is no facility for customization. Because of this, every single > site that uses the project info reports ends up with the same text. Google > for the text of the team-list plugin and there are at least 18,000 matching > pages. > There needs to be a facility for customization. I propose that the default > report is published from a velocity template loaded form the classpath, but > the site plugin checks for the presence of an overriding velocity template in > a know path (or from a URL). -- 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: (MPIR-35) Site Plugin should work from Template. Plugin Should not generate Markup from Java
[ http://jira.codehaus.org/browse/MPIR-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131722#action_131722 ] nodens2k edited comment on MPIR-35 at 4/22/08 9:10 AM: --- Having the ability to specify custom templates for the reports would be great. Much better than just the message properties. BTW, custom templates would be valid solutions for issues MPIR-78 MPIR-86 MPIR94 and MPIR-97. was (Author: nodens2k): Having the ability to specify custom templates for the reports would be great. Much better than just the message properties. > Site Plugin should work from Template. Plugin Should not generate Markup > from Java > --- > > Key: MPIR-35 > URL: http://jira.codehaus.org/browse/MPIR-35 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: New Feature >Reporter: Tim O'Brien > Fix For: 2.x > > Attachments: maven-project-info-reports.patch, project-info-itest.zip > > > The site plugin currently generates markup from Java. There is logic in the > team list report that prints HTML and Javascript directly to a StringBuffer > and there is no facility for customization. Because of this, every single > site that uses the project info reports ends up with the same text. Google > for the text of the team-list plugin and there are at least 18,000 matching > pages. > There needs to be a facility for customization. I propose that the default > report is published from a velocity template loaded form the classpath, but > the site plugin checks for the presence of an overriding velocity template in > a know path (or from a URL). -- 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: (MPIR-35) Site Plugin should work from Template. Plugin Should not generate Markup from Java
[ http://jira.codehaus.org/browse/MPIR-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131722#action_131722 ] Rodrigo Ruiz commented on MPIR-35: -- Having the ability to specify custom templates for the reports would be great. Much better than just the message properties. > Site Plugin should work from Template. Plugin Should not generate Markup > from Java > --- > > Key: MPIR-35 > URL: http://jira.codehaus.org/browse/MPIR-35 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: New Feature >Reporter: Tim O'Brien > Fix For: 2.x > > Attachments: maven-project-info-reports.patch, project-info-itest.zip > > > The site plugin currently generates markup from Java. There is logic in the > team list report that prints HTML and Javascript directly to a StringBuffer > and there is no facility for customization. Because of this, every single > site that uses the project info reports ends up with the same text. Google > for the text of the team-list plugin and there are at least 18,000 matching > pages. > There needs to be a facility for customization. I propose that the default > report is published from a velocity template loaded form the classpath, but > the site plugin checks for the presence of an overriding velocity template in > a know path (or from a URL). -- 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-2029) easyb 0.8 upload
easyb 0.8 upload Key: MAVENUPLOAD-2029 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2029 Project: maven-upload-requests Issue Type: Wish Reporter: Rod Coffin http://easyb.googlecode.com/files/easyb-0.8-bundle.jar http://easyb.googlecode.com/files/easyb-dbunit-plugin-0.8-bundle.jar http://easyb.googlecode.com/files/maven-parent-0.8-bundle.jar http://easyb.googlecode.com/files/maven-easyb-plugin-0.8-bundle.jar http://www.easyb.org http://code.google.com/p/easyb/ I am a developer on the easyb project and this can be verified at http://code.google.com/p/easyb/ where I (username rfciii) am listed as one of the project owners. -- 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-3539) Report plugins with inherited=false dropped by profile injector
Report plugins with inherited=false dropped by profile injector
---
Key: MNG-3539
URL: http://jira.codehaus.org/browse/MNG-3539
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation, Profiles
Affects Versions: 2.0.9
Reporter: Benjamin Bentmann
Priority: Minor
Attachments: reporting-profile-merge.patch
Consider the following POM snippet:
{code:xml}
org.apache.maven.plugins
maven-surefire-report-plugin
2.3
false
extended-site
... some other plugins but excluding the surefire-report-plugin
{code}
When running "mvn site -P extended-site", the Surefire Report Plugin will be
excluded from the site output.
For some reason, the {{DefaultProfileInjector}} is dropping plugins which have
{{inherited=false}}. Inheritance shouldn't matter here, it's all about the same
POM, no parent-child play.
Attached is a unit test to show the failure. An IT will follow now that I have
the JIRA ticket.
--
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: (DOXIA-236) Clarify Sink API
[
http://jira.codehaus.org/browse/DOXIA-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131703#action_131703
]
Lukas Theussl commented on DOXIA-236:
-
This sounds like a good idea. I'll think about it and put a proposal into
confluence.
> Clarify Sink API
>
>
> Key: DOXIA-236
> URL: http://jira.codehaus.org/browse/DOXIA-236
> Project: Maven Doxia
> Issue Type: Task
> Components: Sink API
>Affects Versions: 1.0-alpha-2
>Reporter: Benjamin Bentmann
>
> If the idea with extensibility and interchangeable input/output formats
> should be more than a nice dream, the Sink API needs a thorough specification
> (e.g. by means of more javadoc at {{Sink}}) because that's were everything
> meets. It should define
> # what rules parsers must obey when generating events and
> # what events a sink needs to be prepared to handle
> Currently, all of this is left to assumptions. Some example issues that need
> to be clarified:
> - What characters may constitute an anchor reported by {{anchor()}}?
> Arbitrary, ASCII-only, ...?
> - What format applies to the {{name}} parameter of {{link()}}? How are
> internal and external links to be distinguished (DOXIA-208)?
> - What character chunks are reported by {{text()}}? Longest consecutive
> sequence, line-by-line, arbitrary, ... (DOXIA-222)?
> - What exactly is a figure's source as reported by {{figureGraphics()}}?
> Relative/absolute path, relative to which directory? What about file
> extensions (DOXIA-99)?
> - What order of events is "reasonable" (DOXIA-132)? May parsers report table
> body and caption in a specific or arbitrary order? Must the document head
> always be reported before body or may it be postponed?
> - Is closing a sink twice acceptable or an error?
--
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: (DOXIA-237) add a way to use standard HTML4/XHTML entities like α ∞ ∇ ...
[ http://jira.codehaus.org/browse/DOXIA-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-237. --- Assignee: Lukas Theussl Resolution: Fixed Fix Version/s: 1.0-beta-1 This should be fixed in beta-1 with DOXIA-155. > add a way to use standard HTML4/XHTML entities like α ∞ ∇ > ... > --- > > Key: DOXIA-237 > URL: http://jira.codehaus.org/browse/DOXIA-237 > Project: Maven Doxia > Issue Type: Improvement > Components: Module - Xdoc, Module - Xhtml > Environment: GNU/Linux >Reporter: Luc Maisonobe >Assignee: Lukas Theussl > Fix For: 1.0-beta-1 > > > Trying to use standards entities in a xdoc file for xhtml generation seems > impossible now. > If I put the entities as is in the file, I get an error at site generation > because the entity is not known to Doxia. I did not find any way to declare > the few entities I use, and since the xhtml generated is ISO8859-1 encoded, > there would be a problem afterwards because they do not belong to this > encoding. > If I try to escape the '&' character, either by using ∇ or > , the escape works well at site generation step, but is > still there in the generated xhtml (on both cases I end up with ∇). > I would like to have some intermediate behaviour, escaping a '&' from doxia > parser but having it put verbatim in the generated xhtml file. > I am completely blocked here. -- 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-3538) Properties inside are not replaced in resulting POM
Properties inside are not replaced in resulting POM
Key: MNG-3538
URL: http://jira.codehaus.org/browse/MNG-3538
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.9
Reporter: Ondrej Par
When I use the following dependency definition, the correct classifier is used
during build; however, when the project POM file is deployed to the repository,
it still contains the property name, not the replaced value:
someGroup
someArtifact
3.3.0
${myproperty.arch}
--
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-1832) built-in property containing current timestamp
[ http://jira.codehaus.org/browse/MNG-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131689#action_131689 ] Marco Noto commented on MNG-1832: - How is this issue fixed? In version 2.0.9 isn't added any timestamp built.in propertiy... > built-in property containing current timestamp > -- > > Key: MNG-1832 > URL: http://jira.codehaus.org/browse/MNG-1832 > Project: Maven 2 > Issue Type: New Feature >Affects Versions: 2.0.1 >Reporter: Michal Stochmialek > Attachments: maven-archiver_pomDelete.patch, > maven-core_defaultExpressions.patch > > > Current timestamp (time or date) is often used while filtering resources or > creating manifest in ant builds. There is no equivalent in maven. -- 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-106) Excludes do not work as described on the Usage page
[
http://jira.codehaus.org/browse/MJAR-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131688#action_131688
]
Benjamin Bentmann commented on MJAR-106:
bq. It doesn't work.
But it works for me so there must be something about your configuration. Could
you please attach a demo project and the command lines to invoke to allow to
reproduce your problem?
bq. Why is jar:jar being invoked twice? I assume it's because I defined the
execution goal jar.
Right, you added an additional {{}} for the {{jar}} goal. The first
execution is the default execution defined by the [lifecycle for packaging
"jar"|http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Built-in_Lifecycle_Bindings].
bq. And why aren't the excludes used for the first jar:jar call??
The {{}} element inside an {{}} element applies only
to this particular execution. However as stated above, the first invocation of
the goal does not originate from the {{}} element. Compare the
section [Using executions
tag|http://maven.apache.org/guides/mini/guide-configuring-plugins.html].
> Excludes do not work as described on the Usage page
> ---
>
> Key: MJAR-106
> URL: http://jira.codehaus.org/browse/MJAR-106
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Michael Mattox
>
> The jar plugin usage page gives an example:
> {code:xml}
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
> **/service/*
>
>
>
> {code}
> If I use excludes, such as this:
> {code:xml}
>
>
>
> **/*.properties
>
>
> {code}
> It doesn't work. I get the properties in both my jar and my -tests.jar.
> However, if I add executions to the plugin configuration, like this:
> {code:xml}
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
>
> jar
>
>
>
>
> **/*.properties
>
>
>
>
>
> {code}
> Then the properties are excluded form my test jar but NOT from my regular
> jar. Here is some debug output:
> {noformat}
> [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-jar-plugin:2.2:jar'
> -->
> [DEBUG] (f) classesDirectory =
> C:\projects\company\projects\pam\workspace\mm-config\target\classes
> [DEBUG] (f) defaultManifestFile =
> C:\projects\company\projects\pam\workspace\mm-config\target\classes\META-INF\MANIFEST.MF
> [DEBUG] (f) finalName = mm-config-1.0-SNAPSHOT
> [DEBUG] (f) forceCreation = false
> [DEBUG] (f) outputDirectory =
> C:\projects\company\projects\pam\workspace\mm-config\target
> [DEBUG] (f) project = MavenProject: company:mm-config:1.0-SNAPSHOT @
> C:\projects\company\projects\pam\workspace\mm-config\pom.xml
> [DEBUG] (f) useDefaultManifestFile = false
> [DEBUG] -- end configuration --
> [INFO] [jar:jar]
> [DEBUG] isUp2date: false (Destination
> C:\projects\company\projects\pam\workspace\mm-config\target\mm-config-1.0-SNAPSHOT.jar
> not found.)
> [INFO] Building jar:
> C:\projects\company\projects\pam\workspace\mm-config\target\mm-config-1.0-SNAPSHOT.jar
> [DEBUG] adding directory META-INF/
> [DEBUG] adding entry META-INF/MANIFEST.MF
> [DEBUG] adding directory commons/
> [DEBUG] adding entry commons/applicationContext.xml
> [DEBUG] adding entry database.properties
> [DEBUG] adding entry log4j.xml
> [DEBUG] adding entry messages-exceptions-commons.properties
> [DEBUG] adding entry messages-warnings-commons.properties
> [DEBUG] adding entry mm2-rmi.properties
> [DEBUG] adding directory META-INF/maven/
> [DEBUG] adding directory META-INF/maven/company/
> [DEBUG] adding directory META-INF/maven/company/mm-config/
> [DEBUG] adding entry META-INF/maven/company/mm-config/pom.xml
> [DEBUG] adding entry META-INF/maven/company/mm-config/pom.properties
> [DEBUG] company:mm-config:jar:1.0-SNAPSHOT (selected for null)
> [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-jar-plugin:2.2:jar'
> -->
>
[jira] Commented: (MJAR-101) excluding files from jar doesn't work completely well
[
http://jira.codehaus.org/browse/MJAR-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131687#action_131687
]
Benjamin Bentmann commented on MJAR-101:
Please note that directories are not files. Your exclusions only match files,
not their directories. So why should the plugin exclude those directories if it
was not told to do so? Just because the directories are empty? Others might
want to have those empty directories.
If you want to exclude entire directories, simply tell the plugin:
{code:xml}
**/*.properties
xml/**
{code}
will exclude the directory "xml" and all files underneath it.
> excluding files from jar doesn't work completely well
> -
>
> Key: MJAR-101
> URL: http://jira.codehaus.org/browse/MJAR-101
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Windows XP, JDK 1.5
>Reporter: Patrizio Munzi
> Attachments: mavenjarplugin.bug.tar.gz
>
>
> Maven Jar Plugin exclude feature seems not to work completely well.
> It actually excludes the specified files from the built jar but creates
> however the folders path into it.
> Here's my configuration:
> {code:xml}
>
>**/*.properties
>**/*.xml
>**/*.xsd
>
> {code}
> Although all the specified files are actually excluded from the deployed
> jar, the directory paths of the excluded files are still created into
> the jar.
> I mean, if I have the following files under the resources directory:
> resources/log4j.properties
> resources/xml/file.xml
> resources/xml/schema/schema.xsd
> These files won't be included in the built jar, but I'll still have the
> following path into it:
> /xml/schema/
> Find attached a simple project test case to reproduce the problem.
> - Extract it
> - Change to the main dir
> - run: mvn compile
> - run: mvn jar:jar
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAR-106) Excludes do not work as described on the Usage page
Excludes do not work as described on the Usage page
---
Key: MJAR-106
URL: http://jira.codehaus.org/browse/MJAR-106
Project: Maven 2.x Jar Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Michael Mattox
The jar plugin usage page gives an example:
{code:xml}
org.apache.maven.plugins
maven-jar-plugin
**/service/*
{code}
If I use excludes, such as this:
{code:xml}
**/*.properties
{code}
It doesn't work. I get the properties in both my jar and my -tests.jar.
However, if I add executions to the plugin configuration, like this:
{code:xml}
org.apache.maven.plugins
maven-jar-plugin
jar
**/*.properties
{code}
Then the properties are excluded form my test jar but NOT from my regular jar.
Here is some debug output:
{noformat}
[DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-jar-plugin:2.2:jar' -->
[DEBUG] (f) classesDirectory =
C:\projects\company\projects\pam\workspace\mm-config\target\classes
[DEBUG] (f) defaultManifestFile =
C:\projects\company\projects\pam\workspace\mm-config\target\classes\META-INF\MANIFEST.MF
[DEBUG] (f) finalName = mm-config-1.0-SNAPSHOT
[DEBUG] (f) forceCreation = false
[DEBUG] (f) outputDirectory =
C:\projects\company\projects\pam\workspace\mm-config\target
[DEBUG] (f) project = MavenProject: company:mm-config:1.0-SNAPSHOT @
C:\projects\company\projects\pam\workspace\mm-config\pom.xml
[DEBUG] (f) useDefaultManifestFile = false
[DEBUG] -- end configuration --
[INFO] [jar:jar]
[DEBUG] isUp2date: false (Destination
C:\projects\company\projects\pam\workspace\mm-config\target\mm-config-1.0-SNAPSHOT.jar
not found.)
[INFO] Building jar:
C:\projects\company\projects\pam\workspace\mm-config\target\mm-config-1.0-SNAPSHOT.jar
[DEBUG] adding directory META-INF/
[DEBUG] adding entry META-INF/MANIFEST.MF
[DEBUG] adding directory commons/
[DEBUG] adding entry commons/applicationContext.xml
[DEBUG] adding entry database.properties
[DEBUG] adding entry log4j.xml
[DEBUG] adding entry messages-exceptions-commons.properties
[DEBUG] adding entry messages-warnings-commons.properties
[DEBUG] adding entry mm2-rmi.properties
[DEBUG] adding directory META-INF/maven/
[DEBUG] adding directory META-INF/maven/company/
[DEBUG] adding directory META-INF/maven/company/mm-config/
[DEBUG] adding entry META-INF/maven/company/mm-config/pom.xml
[DEBUG] adding entry META-INF/maven/company/mm-config/pom.properties
[DEBUG] company:mm-config:jar:1.0-SNAPSHOT (selected for null)
[DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-jar-plugin:2.2:jar' -->
[DEBUG] (f) classesDirectory =
C:\projects\company\projects\pam\workspace\mm-config\target\classes
[DEBUG] (f) defaultManifestFile =
C:\projects\company\projects\pam\workspace\mm-config\target\classes\META-INF\MANIFEST.MF
[DEBUG] (f) excludes = [Ljava.lang.String;@24dd07a
[DEBUG] (f) finalName = mm-config-1.0-SNAPSHOT
[DEBUG] (f) forceCreation = false
[DEBUG] (f) outputDirectory =
C:\projects\company\projects\pam\workspace\mm-config\target
[DEBUG] (f) project = MavenProject: company:mm-config:1.0-SNAPSHOT @
C:\projects\company\projects\pam\workspace\mm-config\pom.xml
[DEBUG] (f) useDefaultManifestFile = false
[DEBUG] -- end configuration --
[INFO] [jar:jar {execution: default}]
[DEBUG] isUp2date: true
[DEBUG] Archive
C:\projects\company\projects\pam\workspace\mm-config\target\mm-config-1.0-SNAPSHOT.jar
is uptodate.
[DEBUG] company:mm-config:jar:1.0-SNAPSHOT (selected for null)
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-jar-plugin:2.2:test-jar' -->
[DEBUG] (f) defaultManifestFile =
C:\projects\company\projects\pam\workspace\mm-config\target\classes\META-INF\MANIFEST.MF
[DEBUG] (f) excludes = [Ljava.lang.String;@24e7541
[DEBUG] (f) finalName = mm-config-1.0-SNAPSHOT
[DEBUG] (f) forceCreation = false
[DEBUG] (f) outputDirectory =
C:\pr
[jira] Issue Comment Edited: (MJAR-101) excluding files from jar doesn't work completely well
[
http://jira.codehaus.org/browse/MJAR-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131685#action_131685
]
cunparis edited comment on MJAR-101 at 4/22/08 4:50 AM:
--
Can you post more of your pom.xml? For me the properties go in the jar but not
in the jar of the test classes.
{code:xml}
org.apache.maven.plugins
maven-jar-plugin
jar
**/*.properties
{code}
was (Author: cunparis):
Can you post more of your pom.xml? For me the properties go in the jar but
not in the jar of the test classes.
org.apache.maven.plugins
maven-jar-plugin
jar
**/*.properties
> excluding files from jar doesn't work completely well
> -
>
> Key: MJAR-101
> URL: http://jira.codehaus.org/browse/MJAR-101
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Windows XP, JDK 1.5
>Reporter: Patrizio Munzi
> Attachments: mavenjarplugin.bug.tar.gz
>
>
> Maven Jar Plugin exclude feature seems not to work completely well.
> It actually excludes the specified files from the built jar but creates
> however the folders path into it.
> Here's my configuration:
> {code:xml}
>
>**/*.properties
>**/*.xml
>**/*.xsd
>
> {code}
> Although all the specified files are actually excluded from the deployed
> jar, the directory paths of the excluded files are still created into
> the jar.
> I mean, if I have the following files under the resources directory:
> resources/log4j.properties
> resources/xml/file.xml
> resources/xml/schema/schema.xsd
> These files won't be included in the built jar, but I'll still have the
> following path into it:
> /xml/schema/
> Find attached a simple project test case to reproduce the problem.
> - Extract it
> - Change to the main dir
> - run: mvn compile
> - run: mvn jar:jar
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MJAR-101) excluding files from jar doesn't work completely well
[
http://jira.codehaus.org/browse/MJAR-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131685#action_131685
]
cunparis edited comment on MJAR-101 at 4/22/08 4:49 AM:
--
Can you post more of your pom.xml? For me the properties go in the jar but not
in the jar of the test classes.
org.apache.maven.plugins
maven-jar-plugin
jar
**/*.properties
was (Author: cunparis):
(report updated)
> excluding files from jar doesn't work completely well
> -
>
> Key: MJAR-101
> URL: http://jira.codehaus.org/browse/MJAR-101
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Windows XP, JDK 1.5
>Reporter: Patrizio Munzi
> Attachments: mavenjarplugin.bug.tar.gz
>
>
> Maven Jar Plugin exclude feature seems not to work completely well.
> It actually excludes the specified files from the built jar but creates
> however the folders path into it.
> Here's my configuration:
> {code:xml}
>
>**/*.properties
>**/*.xml
>**/*.xsd
>
> {code}
> Although all the specified files are actually excluded from the deployed
> jar, the directory paths of the excluded files are still created into
> the jar.
> I mean, if I have the following files under the resources directory:
> resources/log4j.properties
> resources/xml/file.xml
> resources/xml/schema/schema.xsd
> These files won't be included in the built jar, but I'll still have the
> following path into it:
> /xml/schema/
> Find attached a simple project test case to reproduce the problem.
> - Extract it
> - Change to the main dir
> - run: mvn compile
> - run: mvn jar:jar
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MJAR-101) excluding files from jar doesn't work completely well
[
http://jira.codehaus.org/browse/MJAR-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131685#action_131685
]
cunparis edited comment on MJAR-101 at 4/22/08 4:48 AM:
--
(report updated)
was (Author: cunparis):
Shouldn't:
*/.properties
be:
**/*.properties
?
In either case, neither work for me. My properties are always in the JAR.
> excluding files from jar doesn't work completely well
> -
>
> Key: MJAR-101
> URL: http://jira.codehaus.org/browse/MJAR-101
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Windows XP, JDK 1.5
>Reporter: Patrizio Munzi
> Attachments: mavenjarplugin.bug.tar.gz
>
>
> Maven Jar Plugin exclude feature seems not to work completely well.
> It actually excludes the specified files from the built jar but creates
> however the folders path into it.
> Here's my configuration:
> {code:xml}
>
>**/*.properties
>**/*.xml
>**/*.xsd
>
> {code}
> Although all the specified files are actually excluded from the deployed
> jar, the directory paths of the excluded files are still created into
> the jar.
> I mean, if I have the following files under the resources directory:
> resources/log4j.properties
> resources/xml/file.xml
> resources/xml/schema/schema.xsd
> These files won't be included in the built jar, but I'll still have the
> following path into it:
> /xml/schema/
> Find attached a simple project test case to reproduce the problem.
> - Extract it
> - Change to the main dir
> - run: mvn compile
> - run: mvn jar:jar
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MJAR-101) excluding files from jar doesn't work completely well
[
http://jira.codehaus.org/browse/MJAR-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MJAR-101:
---
Description:
Maven Jar Plugin exclude feature seems not to work completely well.
It actually excludes the specified files from the built jar but creates however
the folders path into it.
Here's my configuration:
{code:xml}
**/*.properties
**/*.xml
**/*.xsd
{code}
Although all the specified files are actually excluded from the deployed
jar, the directory paths of the excluded files are still created into
the jar.
I mean, if I have the following files under the resources directory:
resources/log4j.properties
resources/xml/file.xml
resources/xml/schema/schema.xsd
These files won't be included in the built jar, but I'll still have the
following path into it:
/xml/schema/
Find attached a simple project test case to reproduce the problem.
- Extract it
- Change to the main dir
- run: mvn compile
- run: mvn jar:jar
was:
Maven Jar Plugin exclude feature seems not to work completely well.
It actually excludes the specified files from the built jar but creates however
the folders path into it.
Here's my configuration:
**/*.properties
**/*.xml
**/*.xsd
Although all the specified files are actually excluded from the deployed
jar, the directory paths of the excluded files are still created into
the jar.
I mean, if I have the following files under the resources directory:
resources/log4j.properties
resources/xml/file.xml
resources/xml/schema/schema.xsd
These files won't be included in the built jar, but I'll still have the
following path into it:
/xml/schema/
Find attached a simple project test case to reproduce the problem.
- Extract it
- Change to the main dir
- run: mvn compile
- run: mvn jar:jar
> excluding files from jar doesn't work completely well
> -
>
> Key: MJAR-101
> URL: http://jira.codehaus.org/browse/MJAR-101
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Windows XP, JDK 1.5
>Reporter: Patrizio Munzi
> Attachments: mavenjarplugin.bug.tar.gz
>
>
> Maven Jar Plugin exclude feature seems not to work completely well.
> It actually excludes the specified files from the built jar but creates
> however the folders path into it.
> Here's my configuration:
> {code:xml}
>
>**/*.properties
>**/*.xml
>**/*.xsd
>
> {code}
> Although all the specified files are actually excluded from the deployed
> jar, the directory paths of the excluded files are still created into
> the jar.
> I mean, if I have the following files under the resources directory:
> resources/log4j.properties
> resources/xml/file.xml
> resources/xml/schema/schema.xsd
> These files won't be included in the built jar, but I'll still have the
> following path into it:
> /xml/schema/
> Find attached a simple project test case to reproduce the problem.
> - Extract it
> - Change to the main dir
> - run: mvn compile
> - run: mvn jar:jar
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-101) excluding files from jar doesn't work completely well
[ http://jira.codehaus.org/browse/MJAR-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=131685#action_131685 ] Michael Mattox commented on MJAR-101: - Shouldn't: */.properties be: **/*.properties ? In either case, neither work for me. My properties are always in the JAR. > excluding files from jar doesn't work completely well > - > > Key: MJAR-101 > URL: http://jira.codehaus.org/browse/MJAR-101 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: Windows XP, JDK 1.5 >Reporter: Patrizio Munzi > Attachments: mavenjarplugin.bug.tar.gz > > > Maven Jar Plugin exclude feature seems not to work completely well. > It actually excludes the specified files from the built jar but creates > however the folders path into it. > Here's my configuration: > >**/*.properties >**/*.xml >**/*.xsd > > Although all the specified files are actually excluded from the deployed > jar, the directory paths of the excluded files are still created into > the jar. > I mean, if I have the following files under the resources directory: > resources/log4j.properties > resources/xml/file.xml > resources/xml/schema/schema.xsd > These files won't be included in the built jar, but I'll still have the > following path into it: > /xml/schema/ > Find attached a simple project test case to reproduce the problem. > - Extract it > - Change to the main dir > - run: mvn compile > - run: mvn jar:jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-375) Problems with svn export and
Problems with svn export and
--
Key: SCM-375
URL: http://jira.codehaus.org/browse/SCM-375
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-svn
Affects Versions: 1.0
Environment: Maven 2.0.8 / Linux
Reporter: Håvard Wigtil
The behaviour of for svn export seems buggy. I have three
(probably related problems):
1) Not setting exportDirectory on export results in a NPE. I can understand
that the setting is required, but I would expect an error message instead.
2) Setting exportDirectory to a relative path gets me this path twice, e.g.
setting exportDirectory to target/export results in an export in
target/export/target/export
3) Setting exportDirectory to an absoulte path, e.g. ${basedir}/target/export
results in an error from svn saying that the directory already exists:
[INFO] Executing: svn --non-interactive export
https://example.com/svn/theproject/trunk/
/home/havwig/theproject/leveranse/target/export
[INFO] Working directory: /home/havwig/theproject/leveranse/target/export
[ERROR] Provider message:
[ERROR] The svn command failed.
[ERROR] Command output:
[ERROR] svn: Destination directory exists; please remove the directory or use
--force to overwrite
svn: '/home/havwig/theproject/leveranse/target/export' already exists
I use the configuration below:
maven-scm-plugin
1.0
scm:svn:https://example.com/svn/theproject/trunk/
${basedir}/target/export
leveranse
package
export
--
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
