[jira] Updated: (MNG-3221) Infinite loop in DefaultLifecycleExecutor
[
http://jira.codehaus.org/browse/MNG-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton updated MNG-3221:
-
Attachment: MNG-3221-r633352.diff
MNG-3221-maven-uml-plugin.diff
Thanks for the reminder, Brian, I totally forgot it :)
Here are the steps to reproduce it:
1) svn co
https://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/maven-uml-plugin
and do mvn install (mvn 2.0.8)
2) mvn site You will see:
{noformat}
...
[INFO] Preparing uml:uml
[INFO] Preparing uml:uml
[INFO] Preparing uml:uml
...
{noformat}
3) apply MNG-3221-r633352.diff, mvn install, unzip for instance
apache-maven-2.0.9-SNAPSHOT-bin.zip and set new M2_HOME
4) apply MNG-3221-maven-uml-plugin.diff and mvn install
5) mvn site (with new M2_HOME) should not produce the infinite loop
Hope that I don't forget anything :)
> Infinite loop in DefaultLifecycleExecutor
> -
>
> Key: MNG-3221
> URL: http://jira.codehaus.org/browse/MNG-3221
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.0.7
>Reporter: Vincent Siveton
> Fix For: 2.0.9
>
> Attachments: infinite-loop.diff, MNG-3221-maven-uml-plugin.diff,
> MNG-3221-r633352.diff
>
>
> Defining this following report:
> {code:title=MyReport.java|borderStyle=solid}
> /**
> * @goal mygoal
> * @execute phase="site"
> */
> public class MyReport
> extends AbstractMavenReport{}
> {code}
> I got this following loop:
> {noformat}
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line:
[jira] Updated: (MNG-3221) Infinite loop in DefaultLifecycleExecutor
[
http://jira.codehaus.org/browse/MNG-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton updated MNG-3221:
-
Fix Version/s: (was: 2.0.10)
2.0.9
Updated fix version since test case is provided
> Infinite loop in DefaultLifecycleExecutor
> -
>
> Key: MNG-3221
> URL: http://jira.codehaus.org/browse/MNG-3221
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.0.7
>Reporter: Vincent Siveton
> Fix For: 2.0.9
>
> Attachments: infinite-loop.diff, MNG-3221-maven-uml-plugin.diff,
> MNG-3221-r633352.diff
>
>
> Defining this following report:
> {code:title=MyReport.java|borderStyle=solid}
> /**
> * @goal mygoal
> * @execute phase="site"
> */
> public class MyReport
> extends AbstractMavenReport{}
> {code}
> I got this following loop:
> {noformat}
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 89
[jira] Issue Comment Edited: (MJAVADOC-119) Aggregate does not work for multiple module project when doing install.
[ http://jira.codehaus.org/browse/MJAVADOC-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125995 ] wsmoak edited comment on MJAVADOC-119 at 3/3/08 8:32 PM: -- I originally thought this may have been fixed along with MJAVADOC-137 by reverting the change from MJAVADOC-104 that added @aggregator, but now I see that it was reported against v2.2. was (Author: wsmoak): I believe this was fixed along with MJAVADOC-137 by reverting the change from MJAVADOC-104 that added @aggregator. > Aggregate does not work for multiple module project when doing install. > --- > > Key: MJAVADOC-119 > URL: http://jira.codehaus.org/browse/MJAVADOC-119 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: Fedora Linux, Maven 2.0.6 >Reporter: Paul Gier > Fix For: 2.4 > > > If have a multi-module project, the javadoc aggregate does not find > inter-module dependencies: > pom.xml > |-->module1 > |-->module2 > module 1 depends on module 2 > The javadoc plugin is added to the build lifecycle attached to the install > phase. When I run "mvn install" I get a "Failed to resolve artifact." error > message looking for module 2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MJAVADOC-119) Aggregate does not work for multiple module project when doing install.
[ http://jira.codehaus.org/browse/MJAVADOC-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated MJAVADOC-119: - Fix Version/s: 2.4 I believe this was fixed along with MJAVADOC-137 by reverting the change from MJAVADOC-104 that added @aggregator. > Aggregate does not work for multiple module project when doing install. > --- > > Key: MJAVADOC-119 > URL: http://jira.codehaus.org/browse/MJAVADOC-119 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: Fedora Linux, Maven 2.0.6 >Reporter: Paul Gier > Fix For: 2.4 > > > If have a multi-module project, the javadoc aggregate does not find > inter-module dependencies: > pom.xml > |-->module1 > |-->module2 > module 1 depends on module 2 > The javadoc plugin is added to the build lifecycle attached to the install > phase. When I run "mvn install" I get a "Failed to resolve artifact." error > message looking for module 2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-116) Impossible to aggregate javadoc if snapshot never built
[
http://jira.codehaus.org/browse/MJAVADOC-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125994
]
Wendy Smoak commented on MJAVADOC-116:
--
"mvn -DreleaseProfile=true clean deploy site-deploy" works for me with the
latest maven-javadoc-plugin snapshot and the attached example.
(Well, after adding -- for future examples, you can
use something like file:///tmp/repo-MJAVADOC-116 as the deployment repo url,
and likewise for the site deployment url.)
I'm not sure of the timing, but this _may_ have been fixed by along with
MJAVADOC-137 by reverting the change from MJAVADOC-104 that added @aggregator.
> Impossible to aggregate javadoc if snapshot never built
> ---
>
> Key: MJAVADOC-116
> URL: http://jira.codehaus.org/browse/MJAVADOC-116
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Damien Lecan
>Assignee: Vincent Siveton
> Fix For: 2.4
>
> Attachments: javadoc-plugin-test-case.zip, log.txt
>
>
> In a multi-module projet, I build an aggregated Javadoc for the site.
> The project is built with "mvn clean deploy site-deploy"
> When I add a new project, the next build always fails because the javadoc
> plugin can't find at least one snapshot for the new added module
> In the following example, I added a new module tele.persistance:pers-commons,
> which have never been built before.
> Maven tries to download it but it can't find it (never build before).
> {noformat} [INFO] [site:site]
> [WARNING] Unable to load parent project from repository: Could not find the
> model file '/continuum-folders/working-directory/116/../pom.xml'.
> [INFO] Skipped "About" report, file "index.html" already exists for the
> English version.
> [ERROR] VM #displayTree: error : too few arguments to macro. Wanted 2 got 0
> [ERROR] VM #menuItem: error : too few arguments to macro. Wanted 1 got 0
> [INFO] Generate "JavaDocs" report.
> [INFO] snapshot tele:commons:1.2.0-alpha-1-SNAPSHOT: checking for updates
> from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-data:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-api:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-commons:1.2.0-alpha-1-SNAPSHOT:
> checking for updates from mirror.snapshots
> Downloading:
> http://proxy/maven2-snapshots/repository/tele/persistance/pers-commons/1.2.0-alpha-1-SNAPSHOT/pers-commons-1.2.0-alpha-1-SNAPSHOT.jar
> [WARNING] Unable to get resource
> 'tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT' from repository
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=tele.persistance
> -DartifactId=pers-commons \
> -Dversion=1.2.0-alpha-1-SNAPSHOT -Dpackaging=jar
> -Dfile=/path/to/file
> Path to dependency:
> 1) tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> 2) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> {noformat}
> If I make an intermediate "install", everything works fine
--
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: (ARCHETYPE-144) Fails "archetype:create" when specify archetypeVersion
[
http://jira.codehaus.org/browse/ARCHETYPE-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125993
]
BABA,Yasuyuki commented on ARCHETYPE-144:
-
Thanks Raphael.
But, this case is the old "archetype:create".
Not "archetype:generate".
> Fails "archetype:create" when specify archetypeVersion
> --
>
> Key: ARCHETYPE-144
> URL: http://jira.codehaus.org/browse/ARCHETYPE-144
> Project: Maven Archetype
> Issue Type: Bug
>Affects Versions: 2.0-alpha-2
>Reporter: BABA,Yasuyuki
>
> We uses custom archetype and remote repository.
> http://maven.seasar.org/maven2/org/seasar/cubby/cubby-archetype/1.0.0/cubby-archetype-1.0.0.jar
> no specify "archetypeVersion" -> build successful
> {code}
> mvn archetype:create -DremoteRepositories=http://maven.seasar.org/maven2/ \
> -DgroupId=com.example.foo -DartifactId=barapp
> -DarchetypeGroupId=org.seasar.cubby \
> -DarchetypeArtifactId=cubby-archetype
> {code}
> specify "archetypeVersion" -> build error
> {code}
> mvn archetype:create -DremoteRepositories=http://maven.seasar.org/maven2/ \
> -DgroupId=com.example.foo -DartifactId=barapp
> -DarchetypeGroupId=org.seasar.cubby \
> -DarchetypeArtifactId=cubby-archetype -DarchetypeVersion=1.0.0
> {code}
> and part of log
> {code}
> [INFO] [archetype:create]
> [INFO] Defaulting package to group ID: com.example.foo
> [INFO] We are using command line specified remote repositories:
> http://maven.seasar.org/maven2/
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error creating from archetype
> Embedded error: OldArchetype does not exist.
> http://repo1.maven.org/maven2/org/seasar/cubby/cubby-archetype/1.0.0/cubby-archetype-1.0.0.jar
> ~~ expects "http://maven.seasar.org/maven2/"; !
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 2 seconds
> [INFO] Finished at: Mon Mar 03 21:16:46 JST 2008
> [INFO] Final Memory: 8M/79M
> [INFO]
>
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-141) regression: Adding "jar" execution to the parent of a multi-module javadoc plugin causes "recursive invocations" error
[ http://jira.codehaus.org/browse/MJAVADOC-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125991 ] Wendy Smoak commented on MJAVADOC-141: -- I believe this was fixed along with MJAVADOC-137 by reverting the change from MJAVADOC-104 that added @aggregator. > regression: Adding "jar" execution to the parent of a multi-module javadoc > plugin causes "recursive invocations" error > -- > > Key: MJAVADOC-141 > URL: http://jira.codehaus.org/browse/MJAVADOC-141 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Mike Youngstrom > Fix For: 2.4 > > > I have a multimodule project with the javadoc plugin declared in my parent. > > org.apache.maven.plugins > maven-javadoc-plugin > 2.3 > > true > > > > attach-javadocs > > jar > > > > > After upgrading to 2.3 and do a build I now get the error: > [WARNING] Removing: jar from forked lifecycle, to prevent recursive > invocation. > [INFO] No goals needed for project - skipping > Which then skips the processing of that module and later gives me dependency > errors because previous dependencies were not compiled. > If I remove jar processing from my plugin definition everything works fine > except no javadoc jars are created. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-161) performRelease=true breaks install/deploy with multimodule projects
[
http://jira.codehaus.org/browse/MJAVADOC-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125990
]
Wendy Smoak commented on MJAVADOC-161:
--
I believe this was fixed along with MJAVADOC-137 by reverting the change from
MJAVADOC-104 that added @aggregator.
mvn install -DperformRelease=true works for me with the latest
maven-javadoc-plugin snapshot and the attached sample project.
> performRelease=true breaks install/deploy with multimodule projects
> ---
>
> Key: MJAVADOC-161
> URL: http://jira.codehaus.org/browse/MJAVADOC-161
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Julien HENRY
> Fix For: 2.4
>
> Attachments: unTest.zip
>
>
> Hi,
> To build my project, I use:
> mvn clean install -DperformRelease=true
> In a multimodule project, it doesn't work if all dependencies are not already
> in the local repository.
> Step to reproduce:
> 1) create a multimodule project with moduleA and moduleB. moduleA depends on
> moduleB.
> 2) Hit mvn clean install: should work
> 3) Clean your local repository (remove moduleA and moduleB)
> 4) Hit mvn clean install -DperformRelease=true:
> {quote}
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] Unnamed - com.capgemini:unTest:pom:1.0-SNAPSHOT
> [INFO] Unnamed - com.capgemini:moduleB:jar:1.0-SNAPSHOT
> [INFO] Unnamed - com.capgemini:moduleA:jar:1.0-SNAPSHOT
> [INFO]
>
> [INFO] Building Unnamed - com.capgemini:unTest:pom:1.0-SNAPSHOT
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory D:\test\unTest\target
> [INFO] Deleting directory D:\test\unTest\target\classes
> [INFO] Deleting directory D:\test\unTest\target\test-classes
> [INFO] Deleting directory D:\test\unTest\target\site
> [INFO] [site:attach-descriptor]
> [INFO] Preparing source:jar
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [INFO] No goals needed for project - skipping
> [INFO] [source:jar {execution: attach-sources}]
> [INFO] Preparing javadoc:jar
> [INFO]
>
> [INFO] Building Unnamed - com.capgemini:unTest:pom:1.0-SNAPSHOT
> [INFO]
>
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [INFO] No goals needed for project - skipping
> [INFO]
>
> [INFO] Building Unnamed - com.capgemini:moduleB:jar:1.0-SNAPSHOT
> [INFO]
>
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [INFO] No goals needed for project - skipping
> [INFO]
>
> [INFO] Building Unnamed - com.capgemini:moduleA:jar:1.0-SNAPSHOT
> [INFO]
>
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [INFO] No goals needed for project - skipping
> [INFO] snapshot com.capgemini:moduleB:1.0-SNAPSHOT: checking for updates from
> illiade-maven-repository-snapshots
> Downloading:
> http://illiade.sud.capgemini.fr/maven2-snapshots/com/capgemini/moduleB/1.0-SNAPSHOT/moduleB-1.0-SNAPSHOT.jar
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) com.capgemini:moduleB:jar:1.0-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=com.capgemini -DartifactId=moduleB \
> -Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file
> Path to dependency:
> 1) com.capgemini:moduleA:jar:1.0-SNAPSHOT
> 2) com.capgemini:moduleB:jar:1.0-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> com.capgemini:moduleA:jar:1.0-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> illiade-maven-repository-snapshots
> (http://illiade
[jira] Work stopped: (MNG-3093) [maven-dependency-tree] Track range events in dependency tree nodes
[ http://jira.codehaus.org/browse/MNG-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MNG-3093 stopped by Carlos Sanchez. > [maven-dependency-tree] Track range events in dependency tree nodes > --- > > Key: MNG-3093 > URL: http://jira.codehaus.org/browse/MNG-3093 > Project: Maven 2 > Issue Type: Improvement > Components: Shared >Reporter: Mark Hobson >Assignee: Carlos Sanchez > Fix For: Shared Components > > > Need to track the following DependencyTreeResolutionListener events in nodes: > - selectVersionFromRange > - restrictRange -- 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: (MSHADE-21) NPE when calling mvn shade:shade
[ http://jira.codehaus.org/browse/MSHADE-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125989 ] Vincent Siveton commented on MSHADE-21: --- Take care of the maven-shade-plugin version > NPE when calling mvn shade:shade > > > Key: MSHADE-21 > URL: http://jira.codehaus.org/browse/MSHADE-21 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 1.0 >Reporter: Vincent Siveton > Attachments: MSHADE-20.diff > > > Take the take case for SHADE-20 and call mvn shade:shade > mvn install works fine -- 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: (MSHADE-21) NPE when calling mvn shade:shade
NPE when calling mvn shade:shade Key: MSHADE-21 URL: http://jira.codehaus.org/browse/MSHADE-21 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.0 Reporter: Vincent Siveton Attachments: MSHADE-20.diff Take the take case for SHADE-20 and call mvn shade:shade mvn install works fine -- 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: (MSHADE-20) Take care of Manifest attributes defined in maven-jar-plugin
[
http://jira.codehaus.org/browse/MSHADE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton updated MSHADE-20:
--
Attachment: MSHADE-20.diff
Here is a test case under doxia-converter [1]
[1]
https://svn.apache.org/repos/asf/maven/doxia/doxia-tools/trunk/doxia-converter
> Take care of Manifest attributes defined in maven-jar-plugin
>
>
> Key: MSHADE-20
> URL: http://jira.codehaus.org/browse/MSHADE-20
> Project: Maven 2.x Shade Plugin
> Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Vincent Siveton
> Attachments: MSHADE-20.diff
>
>
> Using the following in the POM
> {code:xml}
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
>
> MyMainClass
> ...
>
>
>
>
> {code}
> The manifest in the generated artifact has a Main-Class attribute but it is
> not present in the *uber.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: (MSHADE-20) Take care of Manifest attributes defined in maven-jar-plugin
[
http://jira.codehaus.org/browse/MSHADE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125987
]
Vincent Siveton commented on MSHADE-20:
---
As I said, it affects 1.1 so the trunk :) i.e r67
> Take care of Manifest attributes defined in maven-jar-plugin
>
>
> Key: MSHADE-20
> URL: http://jira.codehaus.org/browse/MSHADE-20
> Project: Maven 2.x Shade Plugin
> Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Vincent Siveton
>
> Using the following in the POM
> {code:xml}
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
>
> MyMainClass
> ...
>
>
>
>
> {code}
> The manifest in the generated artifact has a Main-Class attribute but it is
> not present in the *uber.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] Closed: (DOXIA-228) Create a new tool to handle module conversion
[ http://jira.codehaus.org/browse/DOXIA-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed DOXIA-228. - Resolution: Fixed added > Create a new tool to handle module conversion > - > > Key: DOXIA-228 > URL: http://jira.codehaus.org/browse/DOXIA-228 > Project: Maven Doxia > Issue Type: New Feature > Components: Doxia Tools >Reporter: Vincent Siveton >Assignee: Vincent Siveton > > See the following thread > http://www.nabble.com/Migrating-documentation-from-HTML-files-td15780490.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DOXIA-228) Create a new tool to handle module conversion
[ http://jira.codehaus.org/browse/DOXIA-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated DOXIA-228: -- Component/s: Doxia Tools > Create a new tool to handle module conversion > - > > Key: DOXIA-228 > URL: http://jira.codehaus.org/browse/DOXIA-228 > Project: Maven Doxia > Issue Type: New Feature > Components: Doxia Tools >Reporter: Vincent Siveton >Assignee: Vincent Siveton > > See the following thread > http://www.nabble.com/Migrating-documentation-from-HTML-files-td15780490.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2123) NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range
[ http://jira.codehaus.org/browse/MNG-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125985 ] Carlos Sanchez commented on MNG-2123: - The IT test shows a slightly different stack trace than the original pom uploaded In 2.0.9-SNAPSHOT java.lang.NullPointerException at org.apache.maven.artifact.resolver.ResolutionNode.getTrail(ResolutionNode.java:140) at org.apache.maven.artifact.resolver.ResolutionNode.filterTrail(ResolutionNode.java:215) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:91) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:297) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:285) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1349) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:404) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:331) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:124) at org.apache.maven.cli.MavenCli.main(MavenCli.java:285) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [INFO] Total time: 1 second [INFO] Finished at: Mon Mar 03 15:51:57 PST 2008 [INFO] Final Memory: 4M/9M [INFO] In 2.1-SNAPSHOT java.lang.NullPointerException at org.apache.maven.artifact.resolver.ResolutionNode.getTrail(ResolutionNode.java:145) at org.apache.maven.artifact.resolver.ResolutionNode.filterTrail(ResolutionNode.java:224) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:151) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:428) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:399) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:342) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1439) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:514) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:501) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentsForProject(DefaultLifecycleExecutor.java:265) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149) at org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:225) at org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1) at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:895) at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176) at org.apache.maven.cli.MavenCli.main(
[jira] Commented: (MNG-2123) NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range
[ http://jira.codehaus.org/browse/MNG-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125984 ] Carlos Sanchez commented on MNG-2123: - Tried the pom.xml I've attached the first time and the error is still present in 2.0.9 and 2.1. The expected behaviour would be to throw an OverConstrainedVersionException > NullPointerException when a dependency uses version range and another uses an > actual version incompatible with that range > - > > Key: MNG-2123 > URL: http://jira.codehaus.org/browse/MNG-2123 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.2, 2.0.3, 2.0.4 >Reporter: Carlos Sanchez >Assignee: Brian Fox > Fix For: 2.0.9 > > Attachments: MNG-2123-maven-artifact.patch, > mng2123_versionRangeDependency.tar.bz2, pom.xml > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > Struts 1.2.7 depends on commons-digester 1.6 and jasperreports 1.1.1 in [1.7,) > Build fails with a null pointer exception that is not very explanatory > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Unnamed - test:test:jar:1.0-SNAPSHOT > [INFO]task-segment: [test] > [INFO] > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] version was null for commons-digester:commons-digester > [INFO] > > [INFO] Trace > java.lang.NullPointerException: version was null for > commons-digester:commons-digester > at > org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:361) > at > org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:222) > at > org.apache.maven.artifact.resolver.ResolutionNode.getDependencyTrail(ResolutionNode.java:115) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:88) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:223) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:211) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:182) > at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1117) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:366) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > 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] > > [INFO] Total time: 1 second > [INFO] Finished at: Sun Mar 05 23:26:16 PST 2006 > [INFO] Final Memory: 3M/5M > [INFO] > --
[jira] Created: (MAVENUPLOAD-1953) Mockito upload request
Mockito upload request -- Key: MAVENUPLOAD-1953 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1953 Project: maven-upload-requests Issue Type: Wish Reporter: Igor Czechowski http://mockito.googlecode.com/svn/branches/1.1/maven/mockito-all-1.1-bundle.jar http://code.google.com/p/mockito/ http://code.google.com/u/iczechowski/ I'm a project member in Mockito and want to use the org.mockito groupId You can see my name listed in Project members section at http://code.google.com/p/mockito/ and additionally at http://code.google.com/u/iczechowski/ This bundle has no external dependencies. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-465) Add numeric option for forkmode param
Add numeric option for forkmode param - Key: SUREFIRE-465 URL: http://jira.codehaus.org/browse/SUREFIRE-465 Project: Maven Surefire Issue Type: Improvement Components: process forking Reporter: Eric Smalling Priority: Minor PermGen memory becomes very full for large sets of junits. So much so that unless I turn on pertest I have to up my MaxPermGen to over 300m (we have 2600+ tests) Since that slows the tests to a crawl, and since using that much perm space causes problems with virtual memory paging I'd like to see if an option to fork on every n-th test could be added. ie: 100 would create a new fork for every 100 tests. I'll dl the source and see if i can submit a patch here too. -- 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-3402) MavenArtifactFilterManager needs to not filtering doxia-sink-api
[ http://jira.codehaus.org/browse/MNG-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MNG-3402: -- Component/s: (was: Maven Resources Filtering) Artifacts and Repositories > MavenArtifactFilterManager needs to not filtering doxia-sink-api > > > Key: MNG-3402 > URL: http://jira.codehaus.org/browse/MNG-3402 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0.8 >Reporter: Vincent Siveton > Fix For: 2.0.9 > > Attachments: MavenArtifactFilterManager.diff > > > A plugin (like pdf-plugin) needs to use the most recent sink API and not the > API embedded 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: (MWAR-54) add targetPath support on the webResources plugin parameter
[ http://jira.codehaus.org/browse/MWAR-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125977 ] Olivier Lamy commented on MWAR-54: -- Have you try with last SNAPSHOT ? If it fail with it can you provide a simple project to reproduce the issue ? Thanks. > add targetPath support on the webResources plugin parameter > --- > > Key: MWAR-54 > URL: http://jira.codehaus.org/browse/MWAR-54 > Project: Maven 2.x War Plugin > Issue Type: New Feature >Reporter: Marvin King >Assignee: Marvin King > Fix For: 2.0.2 > > Attachments: MWAR-54-maven-war-plugin.patch > > Time Spent: 30 minutes > Remaining Estimate: 0 minutes > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINSTALL-40) install with classifier with no target/classes fails
[ http://jira.codehaus.org/browse/MINSTALL-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125974 ] Dennis Lundberg commented on MINSTALL-40: - I ran the same command that you did and compared the logs. It turns out that the war plugin that is different. Here's mine: [DEBUG] maven-war-plugin: resolved to version 2.0-beta-2 from repository central My log also shows that your version of the war plugin tries to delete more stuff during clean, than mine does. So perhaps this issue should be moved to MWAR? When I specify version 2.0 of the war plugin I get the same error as you do. Can you confirm that it works for you if you use maven-war-plugin 2.0-beta-2? > install with classifier with no target/classes fails > > > Key: MINSTALL-40 > URL: http://jira.codehaus.org/browse/MINSTALL-40 > Project: Maven 2.x Install Plugin > Issue Type: Bug >Affects Versions: 2.1, 2.2 > Environment: Maven version: 2.0.5, Winx XP pro >Reporter: Michele Lorenzini >Priority: Minor > Attachments: clean-install.log, sample-war.zip > > > The install plugin fails with the following error: > Error installing artifact: File C:\TEMP\sample-war\target\classes does not > exist > in a project where there is no class or classpath resource generation (so the > target/classes folder is not generated in the compile phase). > Suppose for example a war application with no java source code (maybe only > jar dependencies) and no classpath resource. > Installing the project as a primary artifact works fine. > Installing the project as a secondary artifact (so with "classifier" option) > with classes or resources works fine. > Installing the project as a secondary artifact without classes or resources > gives the error below. > Attached is a simple project with packaging WAR composed only by a web.xml > file. > Running "mvn install" on this project should give the error above. Commenting > the classifier tag will result in a successful install. > Also if I put a simple java file (or a resource) the compile goal will create > target/classes folder and the install works fine. > In fact I am using this kind of workaround for the moment (include a dummy > resource in the war build). > The same is with a similar jar project (although it may be less useful to > have an "empty" jar artifact). > Verified with both maven-install-plugin 2.1 and 2.2 -- 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-3219) Create a CLIRR/JarDiff setup for 2.0.x and 2.1.x
[ http://jira.codehaus.org/browse/MNG-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125973 ] Brett Porter commented on MNG-3219: --- we should run it once before the release to check the API is still compatible. This should really be automated, but that's a much bigger issue and not one for targeting at a particular release. > Create a CLIRR/JarDiff setup for 2.0.x and 2.1.x > > > Key: MNG-3219 > URL: http://jira.codehaus.org/browse/MNG-3219 > Project: Maven 2 > Issue Type: New Feature > Components: Bootstrap & Build >Reporter: Jason van Zyl > Fix For: 2.0.9 > > > It may not only be for the core but also the plugin tools that have been > separated. -- 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-3402) MavenArtifactFilterManager needs to not filtering doxia-sink-api
[ http://jira.codehaus.org/browse/MNG-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125972 ] Brett Porter commented on MNG-3402: --- I don't think shading will work as the Sink interface is passed between core and plugin. In doing this, there will be an implicit contract that the sink API can not have anything removed from it over time - though that's probably fair enough. > MavenArtifactFilterManager needs to not filtering doxia-sink-api > > > Key: MNG-3402 > URL: http://jira.codehaus.org/browse/MNG-3402 > Project: Maven 2 > Issue Type: Improvement > Components: Maven Filtering >Affects Versions: 2.0.8 >Reporter: Vincent Siveton > Fix For: 2.0.9 > > Attachments: MavenArtifactFilterManager.diff > > > A plugin (like pdf-plugin) needs to use the most recent sink API and not the > API embedded 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: (MSHADE-20) Take care of Manifest attributes defined in maven-jar-plugin
[
http://jira.codehaus.org/browse/MSHADE-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125971
]
Brett Porter commented on MSHADE-20:
what version were you using? It would be best checked against a release instead
of trunk
I just tried this on maven-core using the 1.0 release and it worked as expected.
> Take care of Manifest attributes defined in maven-jar-plugin
>
>
> Key: MSHADE-20
> URL: http://jira.codehaus.org/browse/MSHADE-20
> Project: Maven 2.x Shade Plugin
> Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Vincent Siveton
>
> Using the following in the POM
> {code:xml}
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
>
> MyMainClass
> ...
>
>
>
>
> {code}
> The manifest in the generated artifact has a Main-Class attribute but it is
> not present in the *uber.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: (MWAR-54) add targetPath support on the webResources plugin parameter
[ http://jira.codehaus.org/browse/MWAR-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125966 ] Eric Zhi Li commented on MWAR-54: - still not working in 2.0.8, please help. thanks a lot > add targetPath support on the webResources plugin parameter > --- > > Key: MWAR-54 > URL: http://jira.codehaus.org/browse/MWAR-54 > Project: Maven 2.x War Plugin > Issue Type: New Feature >Reporter: Marvin King >Assignee: Marvin King > Fix For: 2.0.2 > > Attachments: MWAR-54-maven-war-plugin.patch > > Time Spent: 30 minutes > Remaining Estimate: 0 minutes > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-262) site.xml not inherited if build run from parent
[ http://jira.codehaus.org/browse/MSITE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125960 ] Alexandre Navarro commented on MSITE-262: - I have the same problem with 2.0-beta-6. > site.xml not inherited if build run from parent > --- > > Key: MSITE-262 > URL: http://jira.codehaus.org/browse/MSITE-262 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Reporter: Cameron Jones > Attachments: MSITE-262.zip > > > I've seen that the site.xml is not being inherited in a module when the build > is run from the parent - when run from the module itself the inheritance > works correctly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3428) ${plugin.artifacts} doesn't contain maven core artifacts
[
http://jira.codehaus.org/browse/MNG-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-3428.
---
Resolution: Fixed
Fix Version/s: 2.1-alpha-1
IT is in revId: 633246
> ${plugin.artifacts} doesn't contain maven core artifacts
>
>
> Key: MNG-3428
> URL: http://jira.codehaus.org/browse/MNG-3428
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.1-alpha-1
>Reporter: John Casey
>Assignee: John Casey
> Fix For: 2.1-alpha-1
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3428) ${plugin.artifacts} doesn't contain maven core artifacts
[
http://jira.codehaus.org/browse/MNG-3428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125956
]
John Casey commented on MNG-3428:
-
Initial fix for this is in revId: 633239
I'm coding up an integration test now that will guard against this happening
again in the future.
> ${plugin.artifacts} doesn't contain maven core artifacts
>
>
> Key: MNG-3428
> URL: http://jira.codehaus.org/browse/MNG-3428
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.1-alpha-1
>Reporter: John Casey
>Assignee: John Casey
>
--
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-3428) ${plugin.artifacts} doesn't contain maven core artifacts
${plugin.artifacts} doesn't contain maven core artifacts
Key: MNG-3428
URL: http://jira.codehaus.org/browse/MNG-3428
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.1-alpha-1
Reporter: John Casey
--
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-2123) NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range
[ http://jira.codehaus.org/browse/MNG-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125943 ] Brian Fox commented on MNG-2123: The proposed fix is to return RELEASE as the version if two dependencies at the same level specify incompatible versions (ie 3.2 and (2.0,3.1.99]). Clearly we shouldn't throw an NPE, but returning the RELEASE version feels wrong. First that totally breaks repeatability of a build and second, shouldn't we notify the user with a useful exception instead of guessing anything? (discussion on @ dev: http://www.nabble.com/Comments-on-MNG-2123-%28version-specification-issues%29-td15810087s177.html) > NullPointerException when a dependency uses version range and another uses an > actual version incompatible with that range > - > > Key: MNG-2123 > URL: http://jira.codehaus.org/browse/MNG-2123 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.2, 2.0.3, 2.0.4 >Reporter: Carlos Sanchez >Assignee: Brian Fox > Fix For: 2.0.9 > > Attachments: MNG-2123-maven-artifact.patch, > mng2123_versionRangeDependency.tar.bz2, pom.xml > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > Struts 1.2.7 depends on commons-digester 1.6 and jasperreports 1.1.1 in [1.7,) > Build fails with a null pointer exception that is not very explanatory > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Unnamed - test:test:jar:1.0-SNAPSHOT > [INFO]task-segment: [test] > [INFO] > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] version was null for commons-digester:commons-digester > [INFO] > > [INFO] Trace > java.lang.NullPointerException: version was null for > commons-digester:commons-digester > at > org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:361) > at > org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:222) > at > org.apache.maven.artifact.resolver.ResolutionNode.getDependencyTrail(ResolutionNode.java:115) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:88) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:223) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:211) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:182) > at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1117) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:366) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > 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(
[jira] Commented: (MNG-3244) inherited site url not properly handling parameters
[
http://jira.codehaus.org/browse/MNG-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125941
]
Brian Fox commented on MNG-3244:
Note, dission on dev list:
http://www.nabble.com/Comments---Ideas-for-MNG-3244-td15808822s177.html#a15808822
> inherited site url not properly handling parameters
> ---
>
> Key: MNG-3244
> URL: http://jira.codehaus.org/browse/MNG-3244
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation, Sites & Reporting
>Affects Versions: 2.0.7
>Reporter: Jacob Robertson
>Assignee: Brian Fox
> Fix For: 2.0.9
>
> Attachments: fix-inherited-site-url.patch, guide-site.patch
>
>
> Here is the test case to reroduce this problem. Take the following two
> pom.xml files
>
>
> org.bar
> foo
> foo
> 1.0-SNAPSHOT
> pom
> 4.0.0
>
>
> foo-site
> file://C:/Documents and
> Settings/foo/.m2/site/${project.artifactId}
>
>
>
>
>
> org.bar
> baz
> baz
> 1.0-SNAPSHOT
> pom
> 4.0.0
>
> foo
> org.bar
> 1.0-SNAPSHOT
>
>
> And run the site-deploy goal on each. What you get under the site directory
> is this
> - site
> /- foo
> ---/site docs
> /- baz
> ---/- baz (extra directory)
> --- ---/site docs
> This is the simplest test case. In the case where I have a "grandparent"
> pom, the site directory uses the grandparent/parent as the path to the site,
> and doesn't use the actual artifactId of the artifact I'm creating the site
> for.
--
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: (MANTTASKS-107) repository defined in pom not used to download parent pom when defining pom reference
[ http://jira.codehaus.org/browse/MANTTASKS-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MANTTASKS-107. --- Assignee: Herve Boutemy Resolution: Fixed Fix Version/s: 2.0.9 fixed in r633204 > repository defined in pom not used to download parent pom when defining pom > reference > - > > Key: MANTTASKS-107 > URL: http://jira.codehaus.org/browse/MANTTASKS-107 > Project: Maven 2.x Ant Tasks > Issue Type: Bug > Components: POM Integration >Affects Versions: 2.0.8 >Reporter: Herve Boutemy >Assignee: Herve Boutemy > Fix For: 2.0.9 > > > http://www.nabble.com/Re%3A-Maven-Ant-Tasks%3A-Configured-repository-not-available-p15242329s177.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3421) artifacts not found in any repo are continually rechecked in subsequent builds
[ http://jira.codehaus.org/browse/MNG-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3421. --- Resolution: Fixed applied and verified. > artifacts not found in any repo are continually rechecked in subsequent builds > -- > > Key: MNG-3421 > URL: http://jira.codehaus.org/browse/MNG-3421 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.1-alpha-1 >Reporter: John Casey >Assignee: John Casey > Fix For: 2.1-alpha-1 > > Attachments: maven-artifact-c.diff, maven-artifact-d.patch > > > During subsequent calls to Maven, artifacts that could not be found on any > repository are continually rechecked. > Need to track attempts to resolve artifacts with timestamps and make those > attempts subject to updateInterval, not just found artifacts that may be > stale. > I'm attaching a patch sent to me by Igor Fedorenko, which I'll review and > commit if appropriate. -- 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: (MNG-3421) artifacts not found in any repo are continually rechecked in subsequent builds
[ http://jira.codehaus.org/browse/MNG-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey reopened MNG-3421: - resolver-status.properties file created in the first patch for this issue aggregates multiple artifact versions into a single file, making it difficult to manage transitions for a given artifact version when it becomes available again. I have a new patch file to apply, that corrects this by using a separate resolver-status.properties file for each artifact id (includes version), and will remove the resolver-status.properties file when the artifact becomes available. > artifacts not found in any repo are continually rechecked in subsequent builds > -- > > Key: MNG-3421 > URL: http://jira.codehaus.org/browse/MNG-3421 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.1-alpha-1 >Reporter: John Casey >Assignee: John Casey > Fix For: 2.1-alpha-1 > > Attachments: maven-artifact-c.diff, maven-artifact-d.patch > > > During subsequent calls to Maven, artifacts that could not be found on any > repository are continually rechecked. > Need to track attempts to resolve artifacts with timestamps and make those > attempts subject to updateInterval, not just found artifacts that may be > stale. > I'm attaching a patch sent to me by Igor Fedorenko, which I'll review and > commit if appropriate. -- 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-3421) artifacts not found in any repo are continually rechecked in subsequent builds
[ http://jira.codehaus.org/browse/MNG-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-3421: Attachment: maven-artifact-d.patch > artifacts not found in any repo are continually rechecked in subsequent builds > -- > > Key: MNG-3421 > URL: http://jira.codehaus.org/browse/MNG-3421 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.1-alpha-1 >Reporter: John Casey >Assignee: John Casey > Fix For: 2.1-alpha-1 > > Attachments: maven-artifact-c.diff, maven-artifact-d.patch > > > During subsequent calls to Maven, artifacts that could not be found on any > repository are continually rechecked. > Need to track attempts to resolve artifacts with timestamps and make those > attempts subject to updateInterval, not just found artifacts that may be > stale. > I'm attaching a patch sent to me by Igor Fedorenko, which I'll review and > commit if appropriate. -- 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-287) Unable to pass -DskipAssembly=true through the command line to skip the assembly plugin.
Unable to pass -DskipAssembly=true through the command line to skip the assembly plugin. Key: MASSEMBLY-287 URL: http://jira.codehaus.org/browse/MASSEMBLY-287 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-2 Reporter: Denis Sadowski Configured my assembly plugin as follows: maven-assembly-plugin target/classes/maven/assembly/assembly.xml make-assembly package attached I want to skip running this assembly plugin, so I attempted to use the -DskipAssembly=true command line parameter to no avail, the plugin still runs. I am however able to change other parameters through the command line, such as -DappendAssemblyId=false, and the change is picked up. -- 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: (MANTTASKS-107) repository defined in pom not used to download parent pom when defining pom reference
repository defined in pom not used to download parent pom when defining pom reference - Key: MANTTASKS-107 URL: http://jira.codehaus.org/browse/MANTTASKS-107 Project: Maven 2.x Ant Tasks Issue Type: Bug Components: POM Integration Affects Versions: 2.0.8 Reporter: Herve Boutemy http://www.nabble.com/Re%3A-Maven-Ant-Tasks%3A-Configured-repository-not-available-p15242329s177.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3203) maven should execute compiler:compile and :test-compile in separate executions, to allow separate configuration
[ http://jira.codehaus.org/browse/MNG-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3203: --- Fix Version/s: (was: 2.0.9) 2.0.10 > maven should execute compiler:compile and :test-compile in separate > executions, to allow separate configuration > --- > > Key: MNG-3203 > URL: http://jira.codehaus.org/browse/MNG-3203 > Project: Maven 2 > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 2.0.7 >Reporter: John Casey > Fix For: 2.0.10 > > > Currently, it's impossible to configure the two default maven-compiler-plugin > mojos in the jar lifecycle (:compile and :test-compile) separately without > the configuration for one affecting both. This is because they are both > executed in the same (default) execution. We should be assigning these to > different execution id's, to allow separate configuration. -- 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-2848) Environment variables in profile activation not working
[
http://jira.codehaus.org/browse/MNG-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125928
]
Brian Fox commented on MNG-2848:
vincent: any way to get this for 2.0.9 this week?
> Environment variables in profile activation not working
> ---
>
> Key: MNG-2848
> URL: http://jira.codehaus.org/browse/MNG-2848
> Project: Maven 2
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 2.0.4, 2.0.5
> Environment: Windows XP Professional, JDK 1.5
>Reporter: Muhammad Alsebaey
>Assignee: Vincent Siveton
> Fix For: 2.0.9
>
> Attachments: MNG-2848.patch
>
>
> When using an environment variable as a profile activation variable, it
> doesnt work, using either env.X or ${env.X} doesnt work.
> I found the same issue on the forums unresolved.
> http://www.nabble.com/profile-activation-based-on-environment-variables-tf2585492s177.html#a7208580
> Basically, the following doesnt work, where FOO is a windows environment
> variable (like PATH for example) :
> {code:xml}
>
> haroon-workstation
>
>
> env.FOO
> foo
>
>
> ...
>
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3219) Create a CLIRR/JarDiff setup for 2.0.x and 2.1.x
[ http://jira.codehaus.org/browse/MNG-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125927 ] Brian Fox commented on MNG-3219: is this resolved then? > Create a CLIRR/JarDiff setup for 2.0.x and 2.1.x > > > Key: MNG-3219 > URL: http://jira.codehaus.org/browse/MNG-3219 > Project: Maven 2 > Issue Type: New Feature > Components: Bootstrap & Build >Reporter: Jason van Zyl > Fix For: 2.0.9 > > > It may not only be for the core but also the plugin tools that have been > separated. -- 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-3221) Infinite loop in DefaultLifecycleExecutor
[
http://jira.codehaus.org/browse/MNG-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MNG-3221:
---
Fix Version/s: (was: 2.0.9)
2.0.10
Still no way to replicate, bumping again.
> Infinite loop in DefaultLifecycleExecutor
> -
>
> Key: MNG-3221
> URL: http://jira.codehaus.org/browse/MNG-3221
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.0.7
>Reporter: Vincent Siveton
> Fix For: 2.0.10
>
> Attachments: infinite-loop.diff
>
>
> Defining this following report:
> {code:title=MyReport.java|borderStyle=solid}
> /**
> * @goal mygoal
> * @execute phase="site"
> */
> public class MyReport
> extends AbstractMavenReport{}
> {code}
> I got this following loop:
> {noformat}
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 739
> DefaultLifecycleExecutor.executeGoals(List, Stack, MavenSession,
> MavenProject) line: 530
> DefaultLifecycleExecutor.executeGoalWithLifecycle(String, Stack,
> MavenSession, Map, MavenProject, Lifecycle) line: 480
> DefaultLifecycleExecutor.forkProjectLifecycle(MojoDescriptor, Stack,
> MavenSession, MavenProject) line: 896
> DefaultLifecycleExecutor.forkLifecycle(MojoDescriptor, Stac
[jira] Commented: (MNG-3402) MavenArtifactFilterManager needs to not filtering doxia-sink-api
[ http://jira.codehaus.org/browse/MNG-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125924 ] Brian Fox commented on MNG-3402: should we just shade it then? > MavenArtifactFilterManager needs to not filtering doxia-sink-api > > > Key: MNG-3402 > URL: http://jira.codehaus.org/browse/MNG-3402 > Project: Maven 2 > Issue Type: Improvement > Components: Maven Filtering >Affects Versions: 2.0.8 >Reporter: Vincent Siveton > Fix For: 2.0.9 > > Attachments: MavenArtifactFilterManager.diff > > > A plugin (like pdf-plugin) needs to use the most recent sink API and not the > API embedded 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] Closed: (MNG-3425) Required parameters of self written Mojo configured in execution part of POM are ignored and causing error
[
http://jira.codehaus.org/browse/MNG-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MNG-3425.
--
Assignee: Brian Fox
Resolution: Duplicate
Fix Version/s: (was: 2.0.9)
This issue is a duplicate of something that likely cannot be fixed in 2.0.x
> Required parameters of self written Mojo configured in execution part of POM
> are ignored and causing error
> --
>
> Key: MNG-3425
> URL: http://jira.codehaus.org/browse/MNG-3425
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
> Environment: Windows XP
>Reporter: Halil-Cem Gürsoy
>Assignee: Brian Fox
>
> Required parameters configured in execution part of POM are ignored if:
> the parameter ist set as required AND
> (no default value is set OR
> default-Value is set to "") AND
> configuration of parameter values are done in the execution element.
> Example:
> Parameter definition in Mojo:
> {code}
> /**
>* @parameter default-value="ATTENTION DEFAULT"
>* @required
>*/
> private File dummy1;
> {code}
> and snip from POM:
> {code:xml}
>
>
> myownartifact.plugin
> maven-myownartifact-plugin
> true
>
>
> extract
>
> c:/my files/test/dummy1
>
>
>extract
>
>
>
>
>
> {code}
> runs fine.
> If I change the definition of the parameter to
> {code}
> /**
>* @parameter
>* @required
>*/
> private File dummy1;
> {code}
> or
> {code}
> * @parameter default-value=""
> {code}
> then I got an error:
> [0] inside the definition for plugin: 'maven-myownartifact-plugin'specify the
> following:
>
> ...
> VALUE
> .
> In my opinion this is a bug because with @required I have already tagged this
> parameter as mandatory. So I'm already forced to configure it.
> BTW, if I configure the parameters outside the execution element evrything
> works fine as expected!
> More info:
> - the plugin is bind to the package phase
> If a runable example is needed it's possible to provide one.
--
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-3401) Plugin parameters must be specified outside an execution block when they are invoked from the command line
[
http://jira.codehaus.org/browse/MNG-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MNG-3401:
---
Summary: Plugin parameters must be specified outside an execution block
when they are invoked from the command line (was: Maven Dependency Plugin vs
Eclipse Plugin Errors caused by MVN Core)
> Plugin parameters must be specified outside an execution block when they are
> invoked from the command line
> --
>
> Key: MNG-3401
> URL: http://jira.codehaus.org/browse/MNG-3401
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.0.8
>Reporter: Michael Heß
>
> According to Brian E. Fox there is something wrong with the Maven Core which
> causes the maven-dependency-plugin to fail if it is called by the
> mvn-eclipse-plugin. I can't tell any specifics since Brian looked into it,
> and only provided me a workaround. I'm pasting our dialog from the mailing
> list in here. Any further questions regarding this should be directed to
> Brian, since I am just a user and do not have the necessary insight.
> - snip mailinglist transscript starts here
> No, this is a maven core bug and will probably have to be fixed in 2.1, but
> file an issue anyway.
> -Original Message-
> From: Michael Heß [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 14, 2008 12:57 AM
> To: Maven Users List
> Subject: RE: dependency:unpack vs. eclipse:eclipse
> Thanks Brian, for finding this out.
> I have created a workaround as suggested. Only additional thing I had to
> do, was to also bind the resources:resources to process-resources phase,
> because otherwise the filtering occured before the dependency:unpack. It's
> dirty, but at least it works now.
> Have you already taken care of filing a bug? If not, I would take care of
> this. The bug is in the dependency-plugin, right?
> bye, Michael
> Brian E. Fox schrieb:
> > I am able to reproduce this and it's an unfortunate bug in 2.0.x. The only
> > workaround I can suggest is to change the dependency plugin binding to a
> > later phase than is invoked by the eclipse plugin. According to [1] the
> > phase is generate-resources so you can bump it to process-resources.
> >
> > [1]:
> > http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html
> >
> > -Original Message-
> > From: Michael Heß [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, February 13, 2008 1:07 AM
> > To: Maven Users List
> > Subject: RE: dependency:unpack vs. eclipse:eclipse
> >
> > Sure,
> >
> > here you go, I hope it somehow survives the transfer to the list. If it's
> > completely garbled I can also send you the file directly as an attachment.
> >
> > Furthermore I'd like to add the error I'm getting when binding the
> > dependendy-plugin unpack goal to a specific phase:
> >
> > ERROR -
> > [INFO] One or more required plugin parameters are invalid/missing for
> > 'dependency:unpack'
> >
> > [0] Inside the definition for plugin 'maven-dependency-plugin' specify the
> > following:
> >
> >
> > ...
> > VALUE
> > .
> > ERROR -
> >
> > But as you can see in the pom below, I do have the wanted configuration
> > settings. Thanks for looking into this.
> >
> > bye, Michael
> >
> > ---pom starts here---
> >
> >
> > http://maven.apache.org/POM/4.0.0";
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > http://maven.apache.org/maven-v4_0_0.xsd";>
> >
> > abc
> > de.customer
> > 1.0.0-SNAPSHOT
> >
> > 4.0.0
> > de.customer.abc
> > product-config
> > jar
> > ${parent.version}
> > product-config
> >
> >
> > de.customer.abc.common
> > abc-basis-config
> > ${abc.common.version}
> > compile
> >
> >
> >
> >
> > local
> >
> >
> > local
> >
> >
> >
> >
> > true
> >
> >
> > ${basedir}/src/main/filters/local.properties
> >
> >
> >
> >
> >
> >
> >
> > ${mvn.filter.file}
> >
> >
> >
> > src/main/resources
> > true
[jira] Commented: (MNG-3419) Build continues despite OutOfMemoryError
[ http://jira.codehaus.org/browse/MNG-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125921 ] Brian Fox commented on MNG-3419: Kohsuke, are you saying this is a jdk compiler issue or somewhere else? We need a sample project (preferrably in the IT format) to check this out. We're planning 2.0.9 for this week so we would need it soon if we are to try and figure it out. > Build continues despite OutOfMemoryError > > > Key: MNG-3419 > URL: http://jira.codehaus.org/browse/MNG-3419 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.7 >Reporter: Sanjeeb Sahoo > Fix For: 2.0.9 > > > [I have already sent this question to users forum twice, but no response, so > I am filing this issue] > I am seeing something very strange. We have our own plugin(it's basically an > annotation processor) that gets invoked as part of compile phase. It appears > that the JVM gets OutOfMemoryError when this plugin is executed, yet the > build continues to the next phase instead of aborting. I ran with -X option > and it shows that the plugin is invoked in process. I have looked at our > plugin code and we do not catch Throwable or Error in our code. So, it > appears to be a bug in Maven. Given below is some selected output that I > think should give an idea of what's going on... > [INFO] > > [INFO] Building Web Container for GlassFish > [INFO]task-segment: [install] > [INFO] > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > ... > [DEBUG] Configuring mojo > 'com.sun.enterprise:hk2-maven-plugin:0.2-SNAPSHOT:hk2-compile' --> > ... > [DEBUG] (f) fork = false > ... > [INFO] [hk2:hk2-compile] > [DEBUG] Using compiler 'hk2-apt'. > [DEBUG] Source directories: > [/space/ss141213/WS/gf/v3/web/webtier/src/main/java] > [DEBUG] Classpath: [/space/ss141213/WS/gf/v3/web/webtier/target/classes... > [INFO] Compiling 660 source files to > /space/ss141213/WS/gf/v3/web/webtier/target/classes > The system is out of resources. > Consult the following stack trace for details. > java.lang.OutOfMemoryError: Java heap space >at > java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:99) >at > java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:393) >at java.lang.StringBuilder.append(StringBuilder.java:120) >at com.sun.tools.javac.jvm.ClassReader.list(ClassReader.java:1756) >at com.sun.tools.javac.jvm.ClassReader.listAll(ClassReader.java:1882) >at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:1901) >at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1538) >at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355) >at > com.sun.tools.javac.jvm.ClassReader.completeOwners(ClassReader.java:1547) >at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:1534) >at com.sun.tools.javac.code.Symbol.complete(Symbol.java:355) >at > com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:612) >at com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:550) >at > com.sun.tools.javac.code.Types$AsSuperFcn.visitClassType(Types.java:1440) >at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:482) >at com.sun.tools.javac.code.Types$AsSuperFcn.asSuper(Types.java:1417) >at > com.sun.tools.javac.code.Types$AsSuperFcn.visitClassType(Types.java:1434) >at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:482) >at com.sun.tools.javac.code.Types$AsSuperFcn.asSuper(Types.java:1417) >at com.sun.tools.javac.code.Types.asSuper(Types.java:1407) >at > com.sun.tools.javac.code.Types$IsSubTypeFcn.visitClassType(Types.java:429) >at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:482) >at > com.sun.tools.javac.code.Types$IsSubTypeFcn.isSubType(Types.java:353) >at com.sun.tools.javac.code.Types.isSubType(Types.java:331) >at com.sun.tools.javac.code.Types.isSubTypeUnchecked(Types.java:311) >at com.sun.tools.javac.code.Types.isConvertible(Types.java:278) >at com.sun.tools.javac.code.Types.isAssignable(Types.java:1630) >at com.sun.tools.javac.comp.Check.checkType(Check.java:325) >at com.sun.tools.javac.comp.Annotate.enterAnnotation(Annotate.java:122) >at > com.sun.tools.javac.comp.MemberEnter.enterAnnotations(MemberEnter.java:705) > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked
[jira] Commented: (MECLIPSE-165) Ability to exclude filtered resources from eclipse's source directories
[ http://jira.codehaus.org/browse/MECLIPSE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125914 ] Brian Fox commented on MECLIPSE-165: See my comment from July, the current patch is no longer valid and the tests fail. > Ability to exclude filtered resources from eclipse's source directories > --- > > Key: MECLIPSE-165 > URL: http://jira.codehaus.org/browse/MECLIPSE-165 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: PDE support >Affects Versions: 2.3 >Reporter: Cédric Vidal >Assignee: Brian Fox > Attachments: MECLIPSE-165.patch > > > Resources should be in the classpath from Eclipse's point of view because > they end up being in the classpath from Maven 2's point of view, but whenever > resources are marked as being filtered by M2, Eclipse puts them unfiltered in > the classpath thus introducing an inconsistency between Maven 2 and Eclipse. > Whether or not to include filtered resource directories in eclipse's sources > directories is therefore a real dilemna. While I'm sure a consistent solution > to this dilemna will eventually be found, it would be great to let the user > choose what to do in the meantime. > The attached patch adresses this issue by adding a parameter, > 'excludeFilteredResourcesFromSourceDirs', which when set to true prevents > filtered resource directories from being added to eclipse's source > directories. The parameter defaults to false to avoid changing current > projects' behavior. > Regards, > Cédric Vidal > http://www.B-Process.com > PS: This parameter could be overriden on a per resource directory basis as > mentionned in MECLIPSE-162. This is not adressed by the attached patch though -- 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: (MANTTASKS-106) Maven ant tasks artifact has maven inside the jar and so can't be used from inside the maven (maven-antrun-plugin) - classes do conflict
Maven ant tasks artifact has maven inside the jar and so can't be used from inside the maven (maven-antrun-plugin) - classes do conflict Key: MANTTASKS-106 URL: http://jira.codehaus.org/browse/MANTTASKS-106 Project: Maven 2.x Ant Tasks Issue Type: Bug Affects Versions: 2.0.7 Environment: Linux Reporter: Vitaliy Tymchyshyn I've previously used maven-artifact-ant that is not updated since 2.0.4. Now I need a new (2.0.6) feature - to attach additional source and javadoc jar's from install task. I've tried to use maven-ant-tasks 2.0.7 but failed. It gives me java.lang.ClassCastException: org.codehaus.plexus.component.configurator.BasicComponentConfigurator cannot be cast to org.codehaus.plexus.component.configurator.ComponentConfigurator at org.codehaus.plexus.personality.plexus.lifecycle.phase.AutoConfigurePhase.execute(AutoConfigurePhase.java:34) at org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:101) at org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:105) at org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:95) at org.codehaus.plexus.component.manager.PerLookupComponentManager.getComponent(PerLookupComponentManager.java:48) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:562) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:421) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) 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:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Looking at the jar, I can see that it contains (unlike to maven-artifact-ant) a lot of code not related to ant tasks itself inside it. I suppose this classes clashes with the "parent" maven classes. I suppose this to be a bug, because even if you wish to depend on maven code, you must provide it with dependency mechanism in maven artifact (so that it could be disabled) and not with including additional classes into the 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: (MECLIPSE-165) Ability to exclude filtered resources from eclipse's source directories
[ http://jira.codehaus.org/browse/MECLIPSE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125907 ] Jan Rudert commented on MECLIPSE-165: - Hello ? Any ETA for the release of the fix? I need it as well pretty urgently... > Ability to exclude filtered resources from eclipse's source directories > --- > > Key: MECLIPSE-165 > URL: http://jira.codehaus.org/browse/MECLIPSE-165 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: PDE support >Affects Versions: 2.3 >Reporter: Cédric Vidal >Assignee: Brian Fox > Attachments: MECLIPSE-165.patch > > > Resources should be in the classpath from Eclipse's point of view because > they end up being in the classpath from Maven 2's point of view, but whenever > resources are marked as being filtered by M2, Eclipse puts them unfiltered in > the classpath thus introducing an inconsistency between Maven 2 and Eclipse. > Whether or not to include filtered resource directories in eclipse's sources > directories is therefore a real dilemna. While I'm sure a consistent solution > to this dilemna will eventually be found, it would be great to let the user > choose what to do in the meantime. > The attached patch adresses this issue by adding a parameter, > 'excludeFilteredResourcesFromSourceDirs', which when set to true prevents > filtered resource directories from being added to eclipse's source > directories. The parameter defaults to false to avoid changing current > projects' behavior. > Regards, > Cédric Vidal > http://www.B-Process.com > PS: This parameter could be overriden on a per resource directory basis as > mentionned in MECLIPSE-162. This is not adressed by the attached patch though -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MINSTALL-50) provide property filtering on .pom files placed in local repo
provide property filtering on .pom files placed in local repo
-
Key: MINSTALL-50
URL: http://jira.codehaus.org/browse/MINSTALL-50
Project: Maven 2.x Install Plugin
Issue Type: New Feature
Affects Versions: 2.3
Environment: independent
Reporter: Stefan Armbruster
Attachments: MNG-maven-install.patch
When maven installs an artifact, it's pom is also copied into the artifact's
directory. Unfortunately, if the pom contains a property reference (e.g.
${myprop}), this will not be replaced upon copying the pom file.
I've created a patch for the install plugin that switches on property filtering
by setting a mojo parameter "filteringEnabled". Since this defaults to "false",
backward compatibility is kept 100%.
Some implementation notes:
* the dirty work is done in FilteredProjectArtifactMetadata.java, the property
resolution code has been inspired by ResourcesMojo.
* I've added a unit test, that replaces ${basedir} with the value of a system
property.
* since "svn diff" does not handle binary files,
src/test/resources/unit/basic-install-test-with-filtering/target/maven-install-test-1.0-SNAPSHOT.jar
is not included in the patch. This file is the same as
src/test/resources/unit/basic-install-test/target/maven-install-test-1.0-SNAPSHOT.jar
Since my knowledge of Maven API is more than limited, there might be a more
elegant way to provide this feature ... but it works! I'd be happy to see this
in a future release of 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] Created: (DOXIA-228) Create a new tool to handle module conversion
Create a new tool to handle module conversion - Key: DOXIA-228 URL: http://jira.codehaus.org/browse/DOXIA-228 Project: Maven Doxia Issue Type: New Feature Reporter: Vincent Siveton See the following thread http://www.nabble.com/Migrating-documentation-from-HTML-files-td15780490.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-145) Allow archetype:crawl to crawl only a specific part of the local repository
Allow archetype:crawl to crawl only a specific part of the local repository --- Key: ARCHETYPE-145 URL: http://jira.codehaus.org/browse/ARCHETYPE-145 Project: Maven Archetype Issue Type: Improvement Components: Plugin Affects Versions: 2.0-alpha-2 Reporter: Gert Vanthienen Priority: Minor The use case for this feature request would be to create a project-specific archetype catalog. Cfr. http://www.nabble.com/Tool-for-generating-an-archetype-catalog-to15799921s177.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-144) Fails "archetype:create" when specify archetypeVersion
Fails "archetype:create" when specify archetypeVersion
--
Key: ARCHETYPE-144
URL: http://jira.codehaus.org/browse/ARCHETYPE-144
Project: Maven Archetype
Issue Type: Bug
Affects Versions: 2.0-alpha-2
Reporter: BABA,Yasuyuki
We uses custom archetype and remote repository.
http://maven.seasar.org/maven2/org/seasar/cubby/cubby-archetype/1.0.0/cubby-archetype-1.0.0.jar
no specify "archetypeVersion" -> build successful
{code}
mvn archetype:create -DremoteRepositories=http://maven.seasar.org/maven2/ \
-DgroupId=com.example.foo -DartifactId=barapp
-DarchetypeGroupId=org.seasar.cubby \
-DarchetypeArtifactId=cubby-archetype
{code}
specify "archetypeVersion" -> build error
{code}
mvn archetype:create -DremoteRepositories=http://maven.seasar.org/maven2/ \
-DgroupId=com.example.foo -DartifactId=barapp
-DarchetypeGroupId=org.seasar.cubby \
-DarchetypeArtifactId=cubby-archetype -DarchetypeVersion=1.0.0
{code}
and part of log
{code}
[INFO] [archetype:create]
[INFO] Defaulting package to group ID: com.example.foo
[INFO] We are using command line specified remote repositories:
http://maven.seasar.org/maven2/
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error creating from archetype
Embedded error: OldArchetype does not exist.
http://repo1.maven.org/maven2/org/seasar/cubby/cubby-archetype/1.0.0/cubby-archetype-1.0.0.jar
~~ expects "http://maven.seasar.org/maven2/"; !
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Mon Mar 03 21:16:46 JST 2008
[INFO] Final Memory: 8M/79M
[INFO]
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHADE-20) Take care of Manifest attributes defined in maven-jar-plugin
Take care of Manifest attributes defined in maven-jar-plugin
Key: MSHADE-20
URL: http://jira.codehaus.org/browse/MSHADE-20
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 1.1
Reporter: Vincent Siveton
Using the following in the POM
{code:xml}
org.apache.maven.plugins
maven-jar-plugin
MyMainClass
...
{code}
The manifest in the generated artifact has a Main-Class attribute but it is not
present in the *uber.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: (SUREFIRE-446) Surefire fails to capture TestNG results when forkMode=always
[
http://jira.codehaus.org/browse/SUREFIRE-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125872
]
Andreas Andreou commented on SUREFIRE-446:
--
The 2.4-collab-SNAPSHOT version does not suffer from this.
> Surefire fails to capture TestNG results when forkMode=always
> -
>
> Key: SUREFIRE-446
> URL: http://jira.codehaus.org/browse/SUREFIRE-446
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 2.4
> Environment: Maven 2.0.8, JDK 1.5.0_12, WinXP
>Reporter: Benjamin Bentmann
> Fix For: 2.x
>
> Attachments: testng-fork-mode-it.patch
>
>
> The interplay between {{surefire.Surefire}} and
> {{testng.TestNGDirectoryTestSuite}} does not properly notify the
> ReportManager such that it reports 0 executed tests after the end of the day.
> IT to reproduce attached.
> Also confirmed against 2.5-SNAPSHOT.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3426) regression : in plugin configuration doesn't override plugin classpath
[ http://jira.codehaus.org/browse/MNG-3426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nicolas de loof closed MNG-3426. Assignee: nicolas de loof Resolution: Fixed Fix Version/s: 2.0.9 Use a LinkedHashSet to make plugin dependencies ordering predictable (same as maven 2.1) and place project.build.plugin.dependencies prior to plugin POM dependencies > regression : in plugin configuration doesn't override plugin > classpath > --- > > Key: MNG-3426 > URL: http://jira.codehaus.org/browse/MNG-3426 > Project: Maven 2 > Issue Type: Bug > Components: Plugin API >Affects Versions: 2.0.8 >Reporter: nicolas de loof >Assignee: nicolas de loof >Priority: Critical > Fix For: 2.0.9 > > > Many maven plugins are wrapper around other tools. The plugin is designed for > a version of the tool, and in many case user will want to use a specific > version without having to patch the plugin. The element on > plugin configuration is a common way to do this, by overriding the plugin POM > dependency with another version. > >castor-maven-plugin > > > org.codehaus.castor > castor > VERSION OF CASTOR I WANT TO USE FOR CODE > GENERATION > > > > This used to work with maven < 2.0.8 > In maven 2.0.8, this doesn't work anymore as the set in plugin > configuration is added to plugin classpath, as a duplicate for the one > declared by the plugin but LATER in the classpath (but I may be wrong on this > analysis). -- 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-3426) regression : in plugin configuration doesn't override plugin classpath
[ http://jira.codehaus.org/browse/MNG-3426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125869 ] nicolas de loof commented on MNG-3426: -- testcase committed in maven\core-integration-testing\core-integration-tests testcase uses castor-maven-plugin as castor codegen includes castor version in generated files header on maven 2.0.8, generated code is always for 1.1.2.1, as specified by plugin dependencies, even when is set on plugin configuration. > regression : in plugin configuration doesn't override plugin > classpath > --- > > Key: MNG-3426 > URL: http://jira.codehaus.org/browse/MNG-3426 > Project: Maven 2 > Issue Type: Bug > Components: Plugin API >Affects Versions: 2.0.8 >Reporter: nicolas de loof >Priority: Critical > > Many maven plugins are wrapper around other tools. The plugin is designed for > a version of the tool, and in many case user will want to use a specific > version without having to patch the plugin. The element on > plugin configuration is a common way to do this, by overriding the plugin POM > dependency with another version. > >castor-maven-plugin > > > org.codehaus.castor > castor > VERSION OF CASTOR I WANT TO USE FOR CODE > GENERATION > > > > This used to work with maven < 2.0.8 > In maven 2.0.8, this doesn't work anymore as the set in plugin > configuration is added to plugin classpath, as a duplicate for the one > declared by the plugin but LATER in the classpath (but I may be wrong on this > analysis). -- 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: (MINSTALL-40) install with classifier with no target/classes fails
[ http://jira.codehaus.org/browse/MINSTALL-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michele Lorenzini updated MINSTALL-40: -- Attachment: clean-install.log Hi, I've unzipped the sample project, tried a clean install using maven 2.0.7 and version 2.2 of maven-install plugin, and it does NOT install. Attached in clean-install.log the complete log (-X) showing what goes wrong for me. Maybe can be related to some other plugin for which I have some different version? > install with classifier with no target/classes fails > > > Key: MINSTALL-40 > URL: http://jira.codehaus.org/browse/MINSTALL-40 > Project: Maven 2.x Install Plugin > Issue Type: Bug >Affects Versions: 2.1, 2.2 > Environment: Maven version: 2.0.5, Winx XP pro >Reporter: Michele Lorenzini >Priority: Minor > Attachments: clean-install.log, sample-war.zip > > > The install plugin fails with the following error: > Error installing artifact: File C:\TEMP\sample-war\target\classes does not > exist > in a project where there is no class or classpath resource generation (so the > target/classes folder is not generated in the compile phase). > Suppose for example a war application with no java source code (maybe only > jar dependencies) and no classpath resource. > Installing the project as a primary artifact works fine. > Installing the project as a secondary artifact (so with "classifier" option) > with classes or resources works fine. > Installing the project as a secondary artifact without classes or resources > gives the error below. > Attached is a simple project with packaging WAR composed only by a web.xml > file. > Running "mvn install" on this project should give the error above. Commenting > the classifier tag will result in a successful install. > Also if I put a simple java file (or a resource) the compile goal will create > target/classes folder and the install works fine. > In fact I am using this kind of workaround for the moment (include a dummy > resource in the war build). > The same is with a similar jar project (although it may be less useful to > have an "empty" jar artifact). > Verified with both maven-install-plugin 2.1 and 2.2 -- 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
