[jira] Updated: (MENFORCER-51) build failure in case of available updates
[ http://jira.codehaus.org/browse/MENFORCER-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MENFORCER-51: -- Component/s: Standard Rules > build failure in case of available updates > -- > > Key: MENFORCER-51 > URL: http://jira.codehaus.org/browse/MENFORCER-51 > Project: Maven 2.x Enforcer Plugin > Issue Type: Wish > Components: Standard Rules >Reporter: Tomasz Pik > > It would be useful to have a possibility to fail build if there's an update > of given dependency. > In some way it would 'solve' problem of 'how to depend of latest stable > version of my company parent pom' problem - build would just not pass > if there's an update. -- 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: (MENFORCER-56) NPE if contains an unset variable
[
http://jira.codehaus.org/browse/MENFORCER-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MENFORCER-56:
--
Component/s: Standard Rules
> NPE if contains an unset variable
> -
>
> Key: MENFORCER-56
> URL: http://jira.codehaus.org/browse/MENFORCER-56
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Reporter: Craig Russell
>Assignee: Brian Fox
> Attachments: menforcer-56.patch
>
>
> With this snippet of metadata:
>
> ndbj.jnilib2
> "You must have a ndbj.jnilib2!"
>
>
>
>${ndbj.jnilib2}
>
>
> the variable ndbj.jnilib2 doesn't exist and results in:
> java.lang.NullPointerException
> at
> org.apache.maven.plugins.enforcer.RequireFilesExist.checkFile(RequireFilesExist.java:38)
> at
> org.apache.maven.plugins.enforcer.AbstractRequireFiles.execute(AbstractRequireFiles.java:71)
> at
> org.apache.maven.plugins.enforcer.EnforceMojo.execute(EnforceMojo.java:185)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> 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:272)
> 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)
--
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: (MENFORCER-52) multi module build fails
[ http://jira.codehaus.org/browse/MENFORCER-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MENFORCER-52: -- Component/s: Plugin > multi module build fails > > > Key: MENFORCER-52 > URL: http://jira.codehaus.org/browse/MENFORCER-52 > Project: Maven 2.x Enforcer Plugin > Issue Type: Bug > Components: Plugin >Affects Versions: 1.0-alpha-3, 1.0-alpha-4 > Environment: maven 2.0.9 >Reporter: Michael Brackx >Assignee: Brian Fox > Attachments: enforcer-bug.zip > > > alpha-4 is not fixing my multi module projects build problems > attached is a simple project that fails when building with "mvn verify" -- 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: (MENFORCER-46) include feature of sizewatch-plugin into enforcer plugin
[ http://jira.codehaus.org/browse/MENFORCER-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MENFORCER-46: -- Component/s: Standard Rules > include feature of sizewatch-plugin into enforcer plugin > > > Key: MENFORCER-46 > URL: http://jira.codehaus.org/browse/MENFORCER-46 > Project: Maven 2.x Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Reporter: Roman Stumm >Assignee: Brian Fox > Fix For: 1.0 > > Attachments: verifysize.zip > > > As discussed in the last days, here is the project and source of the > verifysize plugin that allows to check an artifact for max./min. size. > Use it / include it into the enforcer plugin. > For more information, refer to : > http://code.google.com/p/agimatec-maven-plugins/ > Roman -- 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: (MENFORCER-24) create a rule to check that certain profiles are activated.
[ http://jira.codehaus.org/browse/MENFORCER-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MENFORCER-24. - Resolution: Fixed Fix Version/s: (was: 1.0) 1.0-alpha-4 this was already present > create a rule to check that certain profiles are activated. > --- > > Key: MENFORCER-24 > URL: http://jira.codehaus.org/browse/MENFORCER-24 > Project: Maven 2.x Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Affects Versions: 1.0-alpha-3 >Reporter: Brian Fox >Assignee: Brian Fox > Fix For: 1.0-alpha-4 > > -- 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: (MENFORCER-60) throw an error instead of failing the rule if the beanshell is invalid
[ http://jira.codehaus.org/browse/MENFORCER-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MENFORCER-60. - Assignee: Brett Porter (was: Brian Fox) Resolution: Fixed Fix Version/s: 1.0 > throw an error instead of failing the rule if the beanshell is invalid > -- > > Key: MENFORCER-60 > URL: http://jira.codehaus.org/browse/MENFORCER-60 > Project: Maven 2.x Enforcer Plugin > Issue Type: Bug > Components: Standard Rules >Affects Versions: 1.0-alpha-4 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 1.0 > > > it can be confusing if the rule just fails because the script is misconfigured -- 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: (MENFORCER-60) throw an error instead of failing the rule if the beanshell is invalid
throw an error instead of failing the rule if the beanshell is invalid -- Key: MENFORCER-60 URL: http://jira.codehaus.org/browse/MENFORCER-60 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Components: Standard Rules Affects Versions: 1.0-alpha-4 Reporter: Brett Porter Assignee: Brian Fox it can be confusing if the rule just fails because the script is misconfigured -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MERCURY-65) Implement "old" maven-ant syntax
[
http://jira.codehaus.org/browse/MERCURY-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159016#action_159016
]
Oleg Gusakov edited comment on MERCURY-65 at 12/22/08 7:36 PM:
---
Proposal #2 seem to be the most convenient. On one hand it naturally blends
with Ant path, on the other hand - it provides a container for either nested
elements or can have an attribute pom="/path/to/pom"
As has a different sematics in maven-ant, will have to use for now
All 4 syntax samples will works:
{code:xml|title=dependencies from the pom}
{code}
and
{code:xml|title=embedded into embedded classpath}
{code}
and
{code:xml|title=creates a new classpath}
{code}
and
{code:xml|title=embedded into named classpath}
{code}
was (Author: olle):
Proposal #2 seem to be the most convenient. On one hand it naturally blends
with Ant path, on the other hand - it provides a container for either nested
elements or can have an attribute pom="/path/to/pom"
As has a different sematics in maven-ant, will have to use for now
All 4 syntax samples will works:
{code:xml|title=dependencie in the pom}
{code}
and
{code:xml|title=embedded into embedded classpath}
{code}
and
{code:xml|title=creates a new classpath}
{code}
and
{code:xml|title=embedded into named classpath}
{code}
> Implement "old" maven-ant syntax
> -
>
> Key: MERCURY-65
> URL: http://jira.codehaus.org/browse/MERCURY-65
> Project: Mercury
> Issue Type: Improvement
> Components: Ant tasks
>Reporter: Oleg Gusakov
>Assignee: Oleg Gusakov
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> * As there are a lot of users that expect some kind of "investment protection"
> * simplify to allow "3 line" solutions for common tasks
> * introduce defaults - default repository, default dependency set
> * merge mercury: deps and mercury:resolve into one dependencies task
> * show how to inline mercury classpath in the build.xml instead of ~/.ant/lib
> * expose "transitive" option from "resolve" task - for non-transitive reading
> from repos
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159020#action_159020 ] Moritz Rebbert edited comment on MRELEASE-261 at 12/22/08 7:35 PM: --- We also using a "flat" hierarchy for some of our projects. Based on the assumption of a common ancestor directory that has to be tagged, we started to make a patch. It workes for us in a simple setup with a parent project in the same folder with some direct modules. Also it should not destroy the behavior in hierarchical layouts. We do not set or change the workingDirectory variable but compute the common ancestor of all projects where we need it. So we technically devided the location where the pom of the root project resides from the directory which will be tagged(or my be branched). All projects are tagged under a common directory and "release:perform" also do the job for us. I've you are brave, you could give "flatProject.main.patch" a try. We also tried to fix the tests in a reasonable way(flatProject.test.patch). (We also assume that the layout of the working copy matches the layout in a single repository.) Edit: its based on 2.0-beta-9-SNAPSHOT (Last Changed Rev: 726974) was (Author: ztiromoritz): We also using a "flat" hierarchy for some of our projects. Based on the assumption of a common ancestor directory that has to be tagged, we started to make a patch. It workes for us in a simple setup with a parent project in the same folder with some direct modules. Also it should not destroy the behavior in hierarchical layouts. We do not set or change the workingDirectory variable but compute the common ancestor of all projects where we need it. So we technically devided the location where the pom of the root project resides from the directory which will be tagged(or my be branched). All projects are tagged under a common directory and "release:perform" also do the job for us. I've you are brave, you could give "flatProject.main.patch" a try. We also tried to fix the tests in a reasonable way(flatProject.test.patch). (We also assume that the layout of the working copy matches the layout in a single repository.) > release:prepare shouls support flat directory multimodule projects > -- > > Key: MRELEASE-261 > URL: http://jira.codehaus.org/browse/MRELEASE-261 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare > Environment: linux / maven2 / svn >Reporter: paul.whe...@gmail.com > Attachments: flatProject.main.patch, flatProject.test.patch, > PrepareReleaseMojo.patch > > > What I mean by flat file structure firstly. > parent/pom.xml > module1/pom.xml > module2/pom.xml > . > . > . > module15/pom.xml > the parent references the modules like so > > ../module1 > ../module2 > . > . > . > ../module15 > > When i release:prepare only the parent project is tagged the modules > projects versions are incremented etc but the modules are not tagged in svn. > I use this structure as i use eclipse as my IDE. > I would love to see a fix for the issue marked as closed here > http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand > each submodule of the projects but it would be so nice to have the release > plugin do this for me. > forgive my english. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MERCURY-65) Implement "old" maven-ant syntax
[
http://jira.codehaus.org/browse/MERCURY-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159016#action_159016
]
Oleg Gusakov edited comment on MERCURY-65 at 12/22/08 7:35 PM:
---
Proposal #2 seem to be the most convenient. On one hand it naturally blends
with Ant path, on the other hand - it provides a container for either nested
elements or can have an attribute pom="/path/to/pom"
As has a different sematics in maven-ant, will have to use for now
All 4 syntax samples will works:
{code:xml|title=dependencie in the pom}
{code}
and
{code:xml|title=embedded into embedded classpath}
{code}
and
{code:xml|title=creates a new classpath}
{code}
and
{code:xml|title=embedded into named classpath}
{code}
was (Author: olle):
Proposal #2 seem to be the most convenient. On one hand it naturally blends
with Ant path, on the other hand - it provides a container for either nested
elements or can have an attribute pom="/path/to/pom"
As has a different sematics in maven-ant, will have to use for now
All 4 syntax samples will works:
{code:xml}
{code}
and
{code:xml}
{code}
and
{code:xml}
{code}
and
{code:xml}
{code}
> Implement "old" maven-ant syntax
> -
>
> Key: MERCURY-65
> URL: http://jira.codehaus.org/browse/MERCURY-65
> Project: Mercury
> Issue Type: Improvement
> Components: Ant tasks
>Reporter: Oleg Gusakov
>Assignee: Oleg Gusakov
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> * As there are a lot of users that expect some kind of "investment protection"
> * simplify to allow "3 line" solutions for common tasks
> * introduce defaults - default repository, default dependency set
> * merge mercury: deps and mercury:resolve into one dependencies task
> * show how to inline mercury classpath in the build.xml instead of ~/.ant/lib
> * expose "transitive" option from "resolve" task - for non-transitive reading
> from repos
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MERCURY-65) Implement "old" maven-ant syntax
[
http://jira.codehaus.org/browse/MERCURY-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159016#action_159016
]
Oleg Gusakov edited comment on MERCURY-65 at 12/22/08 7:32 PM:
---
Proposal #2 seem to be the most convenient. On one hand it naturally blends
with Ant path, on the other hand - it provides a container for either nested
elements or can have an attribute pom="/path/to/pom"
As has a different sematics in maven-ant, will have to use for now
All 4 syntax samples will works:
{code:xml}
{code}
and
{code:xml}
{code}
and
{code:xml}
{code}
and
{code:xml}
{code}
was (Author: olle):
Proposal #2 seem to be the most convenient. On one hand it naturally blends
with Ant path, on the other hand - it provides a container for either nested
elements or can have an attribute pom="/path/to/pom"
As has a different sematics in maven-ant, will have to use for now
All 3 syntax samples will works:
{code:xml}
{code}
and
{code:xml}
{code}
and
{code:xml}
{code}
> Implement "old" maven-ant syntax
> -
>
> Key: MERCURY-65
> URL: http://jira.codehaus.org/browse/MERCURY-65
> Project: Mercury
> Issue Type: Improvement
> Components: Ant tasks
>Reporter: Oleg Gusakov
>Assignee: Oleg Gusakov
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> * As there are a lot of users that expect some kind of "investment protection"
> * simplify to allow "3 line" solutions for common tasks
> * introduce defaults - default repository, default dependency set
> * merge mercury: deps and mercury:resolve into one dependencies task
> * show how to inline mercury classpath in the build.xml instead of ~/.ant/lib
> * expose "transitive" option from "resolve" task - for non-transitive reading
> from repos
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MERCURY-65) Implement "old" maven-ant syntax
[
http://jira.codehaus.org/browse/MERCURY-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159016#action_159016
]
Oleg Gusakov edited comment on MERCURY-65 at 12/22/08 7:27 PM:
---
Proposal #2 seem to be the most convenient. On one hand it naturally blends
with Ant path, on the other hand - it provides a container for either nested
elements or can have an attribute pom="/path/to/pom"
As has a different sematics in maven-ant, will have to use for now
All 3 syntax samples will works:
{code:xml}
{code}
and
{code:xml}
{code}
and
{code:xml}
{code}
was (Author: olle):
Proposal #2 seem to be the most convenient. On one hand it naturally blends
with Ant path, on the other hand - it provides a container for either nested
elements or can have an attribute pom="/path/to/pom"
As has a different sematics in maven-ant, will have to use for now
All 3 syntax samples will works:
{code}
{code}
and
{code}
{code}
and
{code}
{code}
> Implement "old" maven-ant syntax
> -
>
> Key: MERCURY-65
> URL: http://jira.codehaus.org/browse/MERCURY-65
> Project: Mercury
> Issue Type: Improvement
> Components: Ant tasks
>Reporter: Oleg Gusakov
>Assignee: Oleg Gusakov
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> * As there are a lot of users that expect some kind of "investment protection"
> * simplify to allow "3 line" solutions for common tasks
> * introduce defaults - default repository, default dependency set
> * merge mercury: deps and mercury:resolve into one dependencies task
> * show how to inline mercury classpath in the build.xml instead of ~/.ant/lib
> * expose "transitive" option from "resolve" task - for non-transitive reading
> from repos
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Moritz Rebbert updated MRELEASE-261: Attachment: flatProject.test.patch flatProject.main.patch We also using a "flat" hierarchy for some of our projects. Based on the assumption of a common ancestor directory that has to be tagged, we started to make a patch. It workes for us in a simple setup with a parent project in the same folder with some direct modules. Also it should not destroy the behavior in hierarchical layouts. We do not set or change the workingDirectory variable but compute the common ancestor of all projects where we need it. So we technically devided the location where the pom of the root project resides from the directory which will be tagged(or my be branched). All projects are tagged under a common directory and "release:perform" also do the job for us. I've you are brave, you could give "flatProject.main.patch" a try. We also tried to fix the tests in a reasonable way(flatProject.test.patch). (We also assume that the layout of the working copy matches the layout in a single repository.) > release:prepare shouls support flat directory multimodule projects > -- > > Key: MRELEASE-261 > URL: http://jira.codehaus.org/browse/MRELEASE-261 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare > Environment: linux / maven2 / svn >Reporter: paul.whe...@gmail.com > Attachments: flatProject.main.patch, flatProject.test.patch, > PrepareReleaseMojo.patch > > > What I mean by flat file structure firstly. > parent/pom.xml > module1/pom.xml > module2/pom.xml > . > . > . > module15/pom.xml > the parent references the modules like so > > ../module1 > ../module2 > . > . > . > ../module15 > > When i release:prepare only the parent project is tagged the modules > projects versions are incremented etc but the modules are not tagged in svn. > I use this structure as i use eclipse as my IDE. > I would love to see a fix for the issue marked as closed here > http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand > each submodule of the projects but it would be so nice to have the release > plugin do this for me. > forgive my english. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MERCURY-65) Implement "old" maven-ant syntax
[
http://jira.codehaus.org/browse/MERCURY-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159016#action_159016
]
Oleg Gusakov edited comment on MERCURY-65 at 12/22/08 7:25 PM:
---
Proposal #2 seem to be the most convenient. On one hand it naturally blends
with Ant path, on the other hand - it provides a container for either nested
elements or can have an attribute pom="/path/to/pom"
As has a different sematics in maven-ant, will have to use for now
All 3 syntax samples will works:
{code}
{code}
and
{code}
{code}
and
{code}
{code}
was (Author: olle):
Proposal #2 seem to be the most convenient. On one hand it naturally blends
with Ant path, on the other hand - it provides a container for either nested
elements or can have an attribute pom="/path/to/pom"
As has a different sematics in maven-ant, will have to use
something else for the container name: something like
So it should works like:
{code}
{code}
and
{code}
{code}
> Implement "old" maven-ant syntax
> -
>
> Key: MERCURY-65
> URL: http://jira.codehaus.org/browse/MERCURY-65
> Project: Mercury
> Issue Type: Improvement
> Components: Ant tasks
>Reporter: Oleg Gusakov
>Assignee: Oleg Gusakov
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> * As there are a lot of users that expect some kind of "investment protection"
> * simplify to allow "3 line" solutions for common tasks
> * introduce defaults - default repository, default dependency set
> * merge mercury: deps and mercury:resolve into one dependencies task
> * show how to inline mercury classpath in the build.xml instead of ~/.ant/lib
> * expose "transitive" option from "resolve" task - for non-transitive reading
> from repos
--
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: (MENFORCER-59) add the ability to be more selective with banned repositories
[ http://jira.codehaus.org/browse/MENFORCER-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MENFORCER-59. - Resolution: Fixed > add the ability to be more selective with banned repositories > - > > Key: MENFORCER-59 > URL: http://jira.codehaus.org/browse/MENFORCER-59 > Project: Maven 2.x Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 1.0-alpha-4 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 1.0 > > > for consistency with requirePluginVersion, add the following: > banRepositories (for non-plugin repos) - boolean > banPluginRepositories - boolean > allowedRepositories - list of ids > allowedPluginRepositories - list of ides -- 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: (MERCURY-66) add Mercury structure documentation
[ http://jira.codehaus.org/browse/MERCURY-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov updated MERCURY-66: Attachment: mercury-ant-deps.png Herve - you can open pom in the pom editor - see attached > add Mercury structure documentation > --- > > Key: MERCURY-66 > URL: http://jira.codehaus.org/browse/MERCURY-66 > Project: Mercury > Issue Type: Task > Components: Misc/All >Reporter: Herve Boutemy >Assignee: Oleg Gusakov > Attachments: mercury-ant-deps.png, mercury-deps-2.odg, > mercury-deps-2.png, mercury-deps.odg, mercury-deps.png > > > Mercury is composed of a lot of components. Having a map of the components > and their dependencies would help a lot to jump into the 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] Updated: (MERCURY-65) Implement "old" maven-ant syntax
[
http://jira.codehaus.org/browse/MERCURY-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Gusakov updated MERCURY-65:
Component/s: (was: Ant tasks)
Remaining Estimate: 0 minutes
Original Estimate: 0 minutes
Proposal #2 seem to be the most convenient. On one hand it naturally blends
with Ant path, on the other hand - it provides a container for either nested
elements or can have an attribute pom="/path/to/pom"
As has a different sematics in maven-ant, will have to use
something else for the container name: something like
So it should works like:
{code}
{code}
and
{code}
{code}
> Implement "old" maven-ant syntax
> -
>
> Key: MERCURY-65
> URL: http://jira.codehaus.org/browse/MERCURY-65
> Project: Mercury
> Issue Type: Improvement
> Components: Ant tasks
>Reporter: Oleg Gusakov
>Assignee: Oleg Gusakov
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
>
> * As there are a lot of users that expect some kind of "investment protection"
> * simplify to allow "3 line" solutions for common tasks
> * introduce defaults - default repository, default dependency set
> * merge mercury: deps and mercury:resolve into one dependencies task
> * show how to inline mercury classpath in the build.xml instead of ~/.ant/lib
> * expose "transitive" option from "resolve" task - for non-transitive reading
> from repos
--
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: (MERCURY-65) Implement "old" maven-ant syntax
[ http://jira.codehaus.org/browse/MERCURY-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov updated MERCURY-65: Component/s: Ant tasks > Implement "old" maven-ant syntax > - > > Key: MERCURY-65 > URL: http://jira.codehaus.org/browse/MERCURY-65 > Project: Mercury > Issue Type: Improvement > Components: Ant tasks >Reporter: Oleg Gusakov >Assignee: Oleg Gusakov > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > * As there are a lot of users that expect some kind of "investment protection" > * simplify to allow "3 line" solutions for common tasks > * introduce defaults - default repository, default dependency set > * merge mercury: deps and mercury:resolve into one dependencies task > * show how to inline mercury classpath in the build.xml instead of ~/.ant/lib > * expose "transitive" option from "resolve" task - for non-transitive reading > from repos -- 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: (MENFORCER-59) add the ability to be more selective with banned repositories
add the ability to be more selective with banned repositories - Key: MENFORCER-59 URL: http://jira.codehaus.org/browse/MENFORCER-59 Project: Maven 2.x Enforcer Plugin Issue Type: Improvement Components: Standard Rules Affects Versions: 1.0-alpha-4 Reporter: Brett Porter Assignee: Brian Fox Fix For: 1.0 for consistency with requirePluginVersion, add the following: banRepositories (for non-plugin repos) - boolean banPluginRepositories - boolean allowedRepositories - list of ids allowedPluginRepositories - list of ides -- 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: (MENFORCER-59) add the ability to be more selective with banned repositories
[ http://jira.codehaus.org/browse/MENFORCER-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MENFORCER-59: -- Assignee: Brett Porter (was: Brian Fox) Fix Version/s: 1.0 > add the ability to be more selective with banned repositories > - > > Key: MENFORCER-59 > URL: http://jira.codehaus.org/browse/MENFORCER-59 > Project: Maven 2.x Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 1.0-alpha-4 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 1.0 > > > for consistency with requirePluginVersion, add the following: > banRepositories (for non-plugin repos) - boolean > banPluginRepositories - boolean > allowedRepositories - list of ids > allowedPluginRepositories - list of ides -- 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: (MENFORCER-17) add a new rule to enforce that no repositories are defined in the poms.
[ http://jira.codehaus.org/browse/MENFORCER-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MENFORCER-17. - Resolution: Fixed Fix Version/s: (was: 1.0) 1.0-alpha-4 was included in the last version. > add a new rule to enforce that no repositories are defined in the poms. > --- > > Key: MENFORCER-17 > URL: http://jira.codehaus.org/browse/MENFORCER-17 > Project: Maven 2.x Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Affects Versions: 1.0-alpha-3 >Reporter: Brian Fox >Assignee: Brian Fox > Fix For: 1.0-alpha-4 > > > repositories in the poms are against best practices -- 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-3224) Maven XML schemes are not usable in XML catalogs
[ http://jira.codehaus.org/browse/MNG-3224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MNG-3224. -- Assignee: Herve Boutemy Resolution: Fixed Fix Version/s: (was: 3.x) 2.0.10 toolchain fixed in r728800, 728801, 728802, 728803 for Maven 3.0.x, 2.0.10-RC, 2.0.x and 2.1.x plugin-metadata fixed in r728813 and redeployed to http://maven.apache.org/xsd/ > Maven XML schemes are not usable in XML catalogs > > > Key: MNG-3224 > URL: http://jira.codehaus.org/browse/MNG-3224 > Project: Maven 2 > Issue Type: Improvement >Reporter: Vojtech Habarta >Assignee: Herve Boutemy > Fix For: 2.0.10 > > Attachments: schemes.zip > > > XML catalogs are usable especially for XML validation and in XML editors. > They eliminate the need for schemaLocation attribute and online access to > schema. They provide convenience and performance for XML processing. XML > catalogs should map namespace to single schema file. This schema file can > include other files but each namespace should be defined by single "primary" > schema file. > Unfortunately different maven schemes (maven-4.0.0.xsd, settings-1.0.0.xsd, > etc.) define complex types with same name in the same namespace with > different content. > For Maven 2 I am suggesting quick solution which is to rename all repeating > complex types to unique names and then either merge all schemes to one file > or create simple "primary" schema file which would include all schema files. > For Maven 3 I am suggesting to introduce different namespaces for different > formats to allow separate versioning. -- 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-3939) dependencyManagement does not inherit imported dependencies
[ http://jira.codehaus.org/browse/MNG-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Dean updated MNG-3939: -- Attachment: console_output.txt I've attached the console output from doing a mvn clean install on the non-working version of the project. Also, the working and non-working versions of the example project are committed as separate zip files. > dependencyManagement does not inherit imported dependencies > --- > > Key: MNG-3939 > URL: http://jira.codehaus.org/browse/MNG-3939 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.9 >Reporter: Ben Dean > Attachments: console_output.txt, > maven-dependency-inherited-import.not-working.zip, > maven-dependency-inherited-import.working.zip > > > I've attached a zip that has two versions of the same multi-module project. > In the first version there is a parent-pom which defines a > dependencyManagement section with one dependency (junit 4.4). I child project > then inherits from the parent-pom and inherits the dependency management > section including the version number for junit. Then then child project can > have a dependency for junit and not care about the version number which is > managed by the dependencyManagement inherited from the parent. > In the second version, the dependencyManagement of the parent has been moved > to a dependency-pom. This makes sense because the dependencyManagement > section for a multi-module project could get huge and it would be nice to > keep the parent-pom small and clean and just import dependencyManagement as > needed. The problem is that the child project does not inherit these imported > dependencies. It seems to me that imported dependencyManagement sections > should be inherited too. This is the error given when the child doesn't what > version of junit to use: > Project ID: maven.dependency.example:child > POM Location: C:\sandbox\eclipse\default\maven example\child\pom.xml > Validation Messages: > [0] 'dependencies.dependency.version' is missing for junit:junit > This is somewhat related (maybe only tangentially) to the following issues: > http://jira.codehaus.org/browse/MNG-3553 > http://jira.codehaus.org/browse/MNG-2314 > http://jira.codehaus.org/browse/MNG-3537 > maybe more ... > However, all those other issues seem to involve a more complex example than > this issue. This issue is just dependencyManagement, import and inheritance. -- 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-3806) NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range
[ http://jira.codehaus.org/browse/MNG-3806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3806: -- Fix Version/s: 2.0.x ok, yes, I see it now. This is not a regression (it occurs in several versions of Maven), but probably a related bug. > NullPointerException when a dependency uses version range and another uses an > actual version incompatible with that range > - > > Key: MNG-3806 > URL: http://jira.codehaus.org/browse/MNG-3806 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.9, 2.1.0-M1 > Environment: Windows XP SP2, Maven see above, JDK 6 >Reporter: Michael Osipov >Priority: Critical > Fix For: 2.0.x > > Attachments: debug-2.0.9.log, debug-2.1.0-M1.log > > > This is simply a regression/reoccurence of MNG-2123, test dependency makes > the whole system fail. > Debug logs are attached. > If I test with slf4j-nop with soft version 1.5.5 it works flawlessly. > Here is the source: http://svn.fckeditor.net/FCKeditor.Java/trunk/ r2607 > run with "mvn site package assembly:assembly" -- 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-3939) dependencyManagement does not inherit imported dependencies
dependencyManagement does not inherit imported dependencies --- Key: MNG-3939 URL: http://jira.codehaus.org/browse/MNG-3939 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.9 Reporter: Ben Dean Attachments: maven-dependency-inherited-import.not-working.zip, maven-dependency-inherited-import.working.zip I've attached a zip that has two versions of the same multi-module project. In the first version there is a parent-pom which defines a dependencyManagement section with one dependency (junit 4.4). I child project then inherits from the parent-pom and inherits the dependency management section including the version number for junit. Then then child project can have a dependency for junit and not care about the version number which is managed by the dependencyManagement inherited from the parent. In the second version, the dependencyManagement of the parent has been moved to a dependency-pom. This makes sense because the dependencyManagement section for a multi-module project could get huge and it would be nice to keep the parent-pom small and clean and just import dependencyManagement as needed. The problem is that the child project does not inherit these imported dependencies. It seems to me that imported dependencyManagement sections should be inherited too. This is the error given when the child doesn't what version of junit to use: Project ID: maven.dependency.example:child POM Location: C:\sandbox\eclipse\default\maven example\child\pom.xml Validation Messages: [0] 'dependencies.dependency.version' is missing for junit:junit This is somewhat related (maybe only tangentially) to the following issues: http://jira.codehaus.org/browse/MNG-3553 http://jira.codehaus.org/browse/MNG-2314 http://jira.codehaus.org/browse/MNG-3537 maybe more ... However, all those other issues seem to involve a more complex example than this issue. This issue is just dependencyManagement, import and inheritance. -- 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-3938) [regression] Plugin executions with default id are not always merged
[
http://jira.codehaus.org/browse/MNG-3938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3938:
--
Fix Version/s: 3.0-alpha-3
> [regression] Plugin executions with default id are not always merged
>
>
> Key: MNG-3938
> URL: http://jira.codehaus.org/browse/MNG-3938
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
>Priority: Minor
> Fix For: 3.0-alpha-3
>
>
> Plugin executions using the default id are not merged during inheritance if
> a) the parent POM defines the plugin via plugin management
> b) the parent POM omits the {{}} for the plugin execution
> c) the child POM uses {{default}} for the plugin execution
> This causes Maven 3.x to fail with a validation error (duplicate execution
> ids)
--
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-3937) [regression] Goals inherited from parent are lost when merging with child execution
[
http://jira.codehaus.org/browse/MNG-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3937:
--
Fix Version/s: 3.0-alpha-3
> [regression] Goals inherited from parent are lost when merging with child
> execution
> ---
>
> Key: MNG-3937
> URL: http://jira.codehaus.org/browse/MNG-3937
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
>Priority: Minor
> Fix For: 3.0-alpha-3
>
>
> Parent POM snippet:
> {code:xml}
>
> org.apache.maven.its.plugins
> maven-it-plugin-a
>
>
>
> parent
>
>
>
>
> {code}
> Child POM snippet:
> {code:xml}
>
> org.apache.maven.its.plugins
> maven-it-plugin-a
>
>
>
> child
>
>
>
>
> {code}
> Effective child POM in Maven 2.x:
> {code:xml}
>
> org.apache.maven.its.plugins
> maven-it-plugin-a
>
>
>
> child
> parent
>
>
>
>
> {code}
> i.e. both the goal from the child and the goal from the parent (in that
> order) will be executed. In Maven 3.x however, only the child's goal is
> present.
--
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-144) Cannot generate Javadoc on Mac OS X if path contains space characters
[ http://jira.codehaus.org/browse/MJAVADOC-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158986#action_158986 ] Trevor Harmon commented on MJAVADOC-144: I was having the bug in Maven 2.0.9 in this configuration: org.apache.maven.plugins maven-javadoc-plugin Simply forcing the 2.5 version fixed the problem for me: org.apache.maven.plugins maven-javadoc-plugin 2.5 > Cannot generate Javadoc on Mac OS X if path contains space characters > - > > Key: MJAVADOC-144 > URL: http://jira.codehaus.org/browse/MJAVADOC-144 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Maven version: 2.0.7 > Java version: 1.5.0_07 > OS name: "mac os x" version: "10.4.10" arch: "i386" >Reporter: Claes Buckwalter >Assignee: Vincent Siveton > Fix For: 2.5 > > > Running 'mvn javadoc:javadoc' fails if the path to the current directory > contains a space character. It works with the 2.0 version of the plugin. It > also works if I rename the directory so that it does not contain a space > character. > presley:~/Documents/workarea/Elk API clabu$ mvn -e javadoc:javadoc > + Error stacktraces are turned on. > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'javadoc'. > [INFO] > > [INFO] Building The Elk Framework > [INFO]task-segment: [javadoc:javadoc] (aggregator-style) > [INFO] > > [INFO] Preparing javadoc:javadoc > [INFO] > > [INFO] Building The Elk Framework > [INFO] > > [INFO] No goals needed for project - skipping > [INFO] Setting property: classpath.resource.loader.class => > 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. > [INFO] Setting property: velocimacro.messages.on => 'false'. > [INFO] Setting property: resource.loader => 'classpath'. > [INFO] Setting property: resource.manager.logwhenfound => 'false'. > [INFO] ** > [INFO] Starting Jakarta Velocity v1.4 > [INFO] RuntimeInstance initializing. > [INFO] Default Properties File: > org/apache/velocity/runtime/defaults/velocity.properties > [INFO] Default ResourceManager initializing. (class > org.apache.velocity.runtime.resource.ResourceManagerImpl) > [INFO] Resource Loader Instantiated: > org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader > [INFO] ClasspathResourceLoader : initialization starting. > [INFO] ClasspathResourceLoader : initialization complete. > [INFO] ResourceCache : initialized. (class > org.apache.velocity.runtime.resource.ResourceCacheImpl) > [INFO] Default ResourceManager initialization complete. > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach > [INFO] Created: 20 parsers. > [INFO] Velocimacro : initialization starting. > [INFO] Velocimacro : adding VMs from VM library template : > VM_global_library.vm > [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in > any resource loader. > [INFO] Velocimacro : error using VM library template VM_global_library.vm : > org.apache.velocity.exception.ResourceNotFoundException: Unable to find > resource 'VM_global_library.vm' > [INFO] Velocimacro : VM library template macro registration complete. > [INFO] Velocimacro : allowInline = true : VMs can be defined inline in > templates > [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may > NOT replace previous VM definitions > [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be > global in scope if allowed. > [INFO] Velocimacro : initialization complete. > [INFO] Velocity successfully started. > [INFO] [javadoc:javadoc] > 1 error > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] An error has occurred in JavaDocs report generation:Exit code: 1 -
[jira] Commented: (MNG-3806) NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range
[ http://jira.codehaus.org/browse/MNG-3806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158985#action_158985 ] Michael Osipov commented on MNG-3806: - Hi Brett, did you change the sfl4j version to the commented range? [1.5.5,1.6) > NullPointerException when a dependency uses version range and another uses an > actual version incompatible with that range > - > > Key: MNG-3806 > URL: http://jira.codehaus.org/browse/MNG-3806 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.9, 2.1.0-M1 > Environment: Windows XP SP2, Maven see above, JDK 6 >Reporter: Michael Osipov >Priority: Critical > Attachments: debug-2.0.9.log, debug-2.1.0-M1.log > > > This is simply a regression/reoccurence of MNG-2123, test dependency makes > the whole system fail. > Debug logs are attached. > If I test with slf4j-nop with soft version 1.5.5 it works flawlessly. > Here is the source: http://svn.fckeditor.net/FCKeditor.Java/trunk/ r2607 > run with "mvn site package assembly:assembly" -- 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-3938) [regression] Plugin executions with default id are not always merged
[regression] Plugin executions with default id are not always merged
Key: MNG-3938
URL: http://jira.codehaus.org/browse/MNG-3938
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 3.0-alpha-1
Reporter: Benjamin Bentmann
Priority: Minor
Plugin executions using the default id are not merged during inheritance if
a) the parent POM defines the plugin via plugin management
b) the parent POM omits the {{}} for the plugin execution
c) the child POM uses {{default}} for the plugin execution
This causes Maven 3.x to fail with a validation error (duplicate execution ids)
--
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-3821) [regression] Project builder blows up when POM declares two plugins which use the same id for their executions/reportsets
[
http://jira.codehaus.org/browse/MNG-3821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shane Isbell closed MNG-3821.
-
Resolution: Fixed
Fix Version/s: (was: 3.0-alpha-3)
3.0-alpha-1
We can't feed containers of containers into the ModelTransformerContext.
Merging of subcontainers needs to be handled in the ModelTransformer
implementation.
> [regression] Project builder blows up when POM declares two plugins which use
> the same id for their executions/reportsets
> -
>
> Key: MNG-3821
> URL: http://jira.codehaus.org/browse/MNG-3821
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle, POM
>Affects Versions: 3.0-alpha-1
>Reporter: Benjamin Bentmann
>Assignee: Shane Isbell
> Fix For: 3.0-alpha-1
>
>
> Running the core IT 2695 with trunk delivered:
> {noformat}
> java.io.IOException:
> org.codehaus.plexus.util.xml.pull.XmlPullParserException: end tag name
> must match start t
> ag name from line 43 (position: START_TAG seen
> .. @43:22) :
> [...]
> at
> org.apache.maven.project.builder.PomClassicTransformer.transformToDomainModel(PomClassicTransformer.java:237)
> at
> org.apache.maven.shared.model.ModelTransformerContext.transform(ModelTransformerContext.java:286)
> at
> org.apache.maven.project.builder.impl.DefaultProjectBuilder.buildFromLocalPath(DefaultProjectBuilder.java:176)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.readModelFromLocalPath(DefaultMavenProjectBuilder.java:544)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:132)
> at
> org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:286)
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:256)
> at
> org.apache.maven.DefaultMaven.createReactorManager(DefaultMaven.java:93)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:147)
> at
> org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:854)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:63)
> 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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:31)
> [ERROR]
> Failed to build MavenProject instance for:
> M:\maven\core-it\core-it-suite\src\test\resources\mng-2695\pom.xml
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRELEASE-297) release doesn't bump versions in properties to the next dev iteration
[
http://jira.codehaus.org/browse/MRELEASE-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158964#action_158964
]
Jan Arend Jansen edited comment on MRELEASE-297 at 12/22/08 9:17 AM:
-
Before
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
nl.test
release-test
pom
Test Releases
0.0.2-SNAPSHOT
release-module1
0.0.2-SNAPSHOT
org.apache.maven.plugins
maven-release-plugin
2.0-beta-8
nl.test
release-module1
${module1.version}
scm:svn:https:///svn/repos/tests/trunk/
{code}
After:
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
nl.test
release-test
pom
Test Releases
0.0.3-SNAPSHOT
release-module1
0.0.2
org.apache.maven.plugins
maven-release-plugin
2.0-beta-8
nl.test
release-module1
${module1.version}
scm:svn:https:///svn/repos/tests/trunk/
{code}
was (Author: jajansen):
Before
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
nl.test
release-test
pom
Test Releases
0.0.2-SNAPSHOT
release-module1
0.0.2-SNAPSHOT
org.apache.maven.plugins
maven-release-plugin
2.0-beta-8
nl.test
release-module1
${module1.version}
scm:svn:https:///svn/repos/tests/trunk/
{code:xml}
After:
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
nl.test
release-test
pom
Test Releases
0.0.3-SNAPSHOT
release-module1
0.0.2
org.apache.maven.plugins
maven-release-plugin
2.0-beta-8
nl.test
release-module1
${module1.version}
scm:svn:https:///svn/repos/tests/trunk/
{code:xml}
> release doesn't bump versions in properties to the next dev iteration
> -
>
> Key: MRELEASE-297
> URL: http://jira.codehaus.org/browse/MRELEASE-297
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-6, 2.0-beta-7
>Reporter: Brian Fox
>Assignee: Maria Odea Ching
>
> Properties used as versions are correctly updated to the release version and
> committed, but they are not bumped to the next snapshot after.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRELEASE-297) release doesn't bump versions in properties to the next dev iteration
[
http://jira.codehaus.org/browse/MRELEASE-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158964#action_158964
]
Jan Arend Jansen edited comment on MRELEASE-297 at 12/22/08 9:17 AM:
-
Before
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
nl.test
release-test
pom
Test Releases
0.0.2-SNAPSHOT
release-module1
0.0.2-SNAPSHOT
org.apache.maven.plugins
maven-release-plugin
2.0-beta-8
nl.test
release-module1
${module1.version}
scm:svn:https:///svn/repos/tests/trunk/
{code}
After:
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
nl.test
release-test
pom
Test Releases
0.0.3-SNAPSHOT
release-module1
0.0.2
org.apache.maven.plugins
maven-release-plugin
2.0-beta-8
nl.test
release-module1
${module1.version}
scm:svn:https:///svn/repos/tests/trunk/
{code}
was (Author: jajansen):
Before
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
nl.test
release-test
pom
Test Releases
0.0.2-SNAPSHOT
release-module1
0.0.2-SNAPSHOT
org.apache.maven.plugins
maven-release-plugin
2.0-beta-8
nl.test
release-module1
${module1.version}
scm:svn:https:///svn/repos/tests/trunk/
{code}
After:
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
nl.test
release-test
pom
Test Releases
0.0.3-SNAPSHOT
release-module1
0.0.2
org.apache.maven.plugins
maven-release-plugin
2.0-beta-8
nl.test
release-module1
${module1.version}
scm:svn:https:///svn/repos/tests/trunk/
{code}
> release doesn't bump versions in properties to the next dev iteration
> -
>
> Key: MRELEASE-297
> URL: http://jira.codehaus.org/browse/MRELEASE-297
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-6, 2.0-beta-7
>Reporter: Brian Fox
>Assignee: Maria Odea Ching
>
> Properties used as versions are correctly updated to the release version and
> committed, but they are not bumped to the next snapshot after.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-297) release doesn't bump versions in properties to the next dev iteration
[
http://jira.codehaus.org/browse/MRELEASE-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158964#action_158964
]
Jan Arend Jansen commented on MRELEASE-297:
---
Before
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
nl.test
release-test
pom
Test Releases
0.0.2-SNAPSHOT
release-module1
0.0.2-SNAPSHOT
org.apache.maven.plugins
maven-release-plugin
2.0-beta-8
nl.test
release-module1
${module1.version}
scm:svn:https:///svn/repos/tests/trunk/
{code:xml}
After:
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
nl.test
release-test
pom
Test Releases
0.0.3-SNAPSHOT
release-module1
0.0.2
org.apache.maven.plugins
maven-release-plugin
2.0-beta-8
nl.test
release-module1
${module1.version}
scm:svn:https:///svn/repos/tests/trunk/
{code:xml}
> release doesn't bump versions in properties to the next dev iteration
> -
>
> Key: MRELEASE-297
> URL: http://jira.codehaus.org/browse/MRELEASE-297
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-6, 2.0-beta-7
>Reporter: Brian Fox
>Assignee: Maria Odea Ching
>
> Properties used as versions are correctly updated to the release version and
> committed, but they are not bumped to the next snapshot after.
--
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-3937) [regression] Goals inherited from parent are lost when merging with child execution
[regression] Goals inherited from parent are lost when merging with child
execution
---
Key: MNG-3937
URL: http://jira.codehaus.org/browse/MNG-3937
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 3.0-alpha-1
Reporter: Benjamin Bentmann
Priority: Minor
Parent POM snippet:
{code:xml}
org.apache.maven.its.plugins
maven-it-plugin-a
parent
{code}
Child POM snippet:
{code:xml}
org.apache.maven.its.plugins
maven-it-plugin-a
child
{code}
Effective child POM in Maven 2.x:
{code:xml}
org.apache.maven.its.plugins
maven-it-plugin-a
child
parent
{code}
i.e. both the goal from the child and the goal from the parent (in that order)
will be executed. In Maven 3.x however, only the child's goal is present.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-297) release doesn't bump versions in properties to the next dev iteration
[ http://jira.codehaus.org/browse/MRELEASE-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158963#action_158963 ] Jan Arend Jansen commented on MRELEASE-297: --- Also affects 2.0-beta8 > release doesn't bump versions in properties to the next dev iteration > - > > Key: MRELEASE-297 > URL: http://jira.codehaus.org/browse/MRELEASE-297 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-6, 2.0-beta-7 >Reporter: Brian Fox >Assignee: Maria Odea Ching > > Properties used as versions are correctly updated to the release version and > committed, but they are not bumped to the next snapshot after. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2310) New version of XINS for Maven2 repository
New version of XINS for Maven2 repository - Key: MAVENUPLOAD-2310 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2310 Project: Maven Upload Requests Issue Type: Task Reporter: Anthony Goubard Hi, Here are new JAR file that I'd like to have uploaded in Maven: http://xins.sourceforge.net/maven/xins-server-2.2.jar http://xins.sourceforge.net/maven/xins-common-2.2.jar http://xins.sourceforge.net/maven/xins-client-2.2.jar http://xins.sourceforge.net/maven/logdoc-2.2.jar Kind regards, Anthony -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2309) Uploading XmlTask jar
Uploading XmlTask jar - Key: MAVENUPLOAD-2309 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2309 Project: Maven Upload Requests Issue Type: Wish Reporter: Sathish Kumar Hi, I want to use XmlTask in my project. But this jar is not available in the repo1.maven.org (or) mavenrepository.com. Pls, upload the XmlTask 1.14 version of jar to these repositories. Thanks, P.Sathish Kumar. -- 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-3769) [regression] Excluding relocated transitive dependencies does not work
[
http://jira.codehaus.org/browse/MNG-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158959#action_158959
]
Brett Porter commented on MNG-3769:
---
confirmed that reverting MNG-3380 fixes this (r675087, r675353). Will continue
investigation later.
> [regression] Excluding relocated transitive dependencies does not work
> --
>
> Key: MNG-3769
> URL: http://jira.codehaus.org/browse/MNG-3769
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.1.0-M1
>Reporter: Dirk Olmes
>Priority: Blocker
> Fix For: 2.0.10, 2.1.0-M2
>
> Attachments: MNG-3769-debugging-info-2.zip,
> MNG-3769-debugging-info.zip, pom.xml
>
>
> I'm trying to exclude transitive dependencies of a dependency. This works
> fine with 2.0.9, however it does not work with 2.1.0-M1.
> Run {{mvn dependency:tree}} on the attached pom.xml with 2.0.9 and note how
> there is no javax.activation in the tree. Re-run with 2.1.0-M1 and note how
> javax.activation shows up in the dependencies tree.
--
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-3936) Remove m2.bat from distribution
[ http://jira.codehaus.org/browse/MNG-3936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3936. - Assignee: Brett Porter Resolution: Fixed removed > Remove m2.bat from distribution > --- > > Key: MNG-3936 > URL: http://jira.codehaus.org/browse/MNG-3936 > Project: Maven 2 > Issue Type: Task > Components: General >Affects Versions: 2.1.0-M1 >Reporter: Paul Benedict >Assignee: Brett Porter >Priority: Minor > Fix For: 2.1.0-M2 > > > As a natural followup to MNG-1395, it is time for m2.bat to finally leave us. -- 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-3769) [regression] Excluding relocated transitive dependencies does not work
[
http://jira.codehaus.org/browse/MNG-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158955#action_158955
]
Brett Porter commented on MNG-3769:
---
added integration test to the suite for verification
> [regression] Excluding relocated transitive dependencies does not work
> --
>
> Key: MNG-3769
> URL: http://jira.codehaus.org/browse/MNG-3769
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.1.0-M1
>Reporter: Dirk Olmes
>Priority: Blocker
> Fix For: 2.0.10, 2.1.0-M2
>
> Attachments: MNG-3769-debugging-info-2.zip,
> MNG-3769-debugging-info.zip, pom.xml
>
>
> I'm trying to exclude transitive dependencies of a dependency. This works
> fine with 2.0.9, however it does not work with 2.1.0-M1.
> Run {{mvn dependency:tree}} on the attached pom.xml with 2.0.9 and note how
> there is no javax.activation in the tree. Re-run with 2.1.0-M1 and note how
> javax.activation shows up in the dependencies tree.
--
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-3838) [regression] Some POMs fail to parse if the are subject to ModelContainer joining
[
http://jira.codehaus.org/browse/MNG-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-3838.
--
Assignee: Shane Isbell
Resolution: Fixed
Fix Version/s: (was: 3.0-alpha-3)
3.0-alpha-1
Fixed in [r727855|http://svn.eu.apache.org/viewvc?view=rev&revision=727855].
> [regression] Some POMs fail to parse if the are subject to ModelContainer
> joining
> -
>
> Key: MNG-3838
> URL: http://jira.codehaus.org/browse/MNG-3838
> Project: Maven 2
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.0-alpha-1
>Reporter: Espen Wiborg
>Assignee: Shane Isbell
>Priority: Blocker
> Fix For: 3.0-alpha-1
>
> Attachments: example.zip
>
>
> With Maven 3.0-SNAPSHOT built from svn r713815, the POM in the attachment
> fails to parse with the output in fail.log. The interesting bit is
> reproduced here:
> {noformat}
> java.io.IOException:
> org.codehaus.plexus.util.xml.pull.XmlPullParserException: end tag name
> must match start tag name from line 12 (position:
> START_TAG seen .. @12:24) :
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns="http://maven.apache.org/POM/4.0.0"; >
> 4.0.0
> testing
> testing
> 1
>
>
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
>
>
> [...lots more...]
> {noformat}
> As far as I can make out, the problem is that the ModelContainer joining
> carried out in ModelTransformerContext.transform (on line 269) fails to take
> into account that it may leave the wrapper collection empty. Such an empty
> collection then leads ModelMarshaller astray later.
> The example POM is a stripped-down version of the
> org.apache.cxf:cfx-parent:2.1 POM, which is how I discovered the issue.
> This broke sometime after 2008-10-13.
--
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-3769) [regression] Excluding relocated transitive dependencies does not work
[
http://jira.codehaus.org/browse/MNG-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3769:
--
Summary: [regression] Excluding relocated transitive dependencies does not
work (was: [regression] Excluding transitive dependencies does not work)
> [regression] Excluding relocated transitive dependencies does not work
> --
>
> Key: MNG-3769
> URL: http://jira.codehaus.org/browse/MNG-3769
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.1.0-M1
>Reporter: Dirk Olmes
>Priority: Blocker
> Fix For: 2.0.10, 2.1.0-M2
>
> Attachments: MNG-3769-debugging-info-2.zip,
> MNG-3769-debugging-info.zip, pom.xml
>
>
> I'm trying to exclude transitive dependencies of a dependency. This works
> fine with 2.0.9, however it does not work with 2.1.0-M1.
> Run {{mvn dependency:tree}} on the attached pom.xml with 2.0.9 and note how
> there is no javax.activation in the tree. Re-run with 2.1.0-M1 and note how
> javax.activation shows up in the dependencies tree.
--
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-3769) [regression] Excluding transitive dependencies does not work
[
http://jira.codehaus.org/browse/MNG-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3769:
--
Fix Version/s: 2.0.10
> [regression] Excluding transitive dependencies does not work
>
>
> Key: MNG-3769
> URL: http://jira.codehaus.org/browse/MNG-3769
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.1.0-M1
>Reporter: Dirk Olmes
>Priority: Blocker
> Fix For: 2.0.10, 2.1.0-M2
>
> Attachments: MNG-3769-debugging-info-2.zip,
> MNG-3769-debugging-info.zip, pom.xml
>
>
> I'm trying to exclude transitive dependencies of a dependency. This works
> fine with 2.0.9, however it does not work with 2.1.0-M1.
> Run {{mvn dependency:tree}} on the attached pom.xml with 2.0.9 and note how
> there is no javax.activation in the tree. Re-run with 2.1.0-M1 and note how
> javax.activation shows up in the dependencies tree.
--
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-3769) [regression] Excluding transitive dependencies does not work
[
http://jira.codehaus.org/browse/MNG-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158952#action_158952
]
Brett Porter commented on MNG-3769:
---
this may be due to http://jira.codehaus.org/browse/MNG-3380
It occurs because of the relocation. saaj-api actually depends on
activation:activation which will properly be excluded.
> [regression] Excluding transitive dependencies does not work
>
>
> Key: MNG-3769
> URL: http://jira.codehaus.org/browse/MNG-3769
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.1.0-M1
>Reporter: Dirk Olmes
>Priority: Blocker
> Fix For: 2.0.10, 2.1.0-M2
>
> Attachments: MNG-3769-debugging-info-2.zip,
> MNG-3769-debugging-info.zip, pom.xml
>
>
> I'm trying to exclude transitive dependencies of a dependency. This works
> fine with 2.0.9, however it does not work with 2.1.0-M1.
> Run {{mvn dependency:tree}} on the attached pom.xml with 2.0.9 and note how
> there is no javax.activation in the tree. Re-run with 2.1.0-M1 and note how
> javax.activation shows up in the dependencies tree.
--
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-3852) [regression] Collection entries of unequal types are reordered in plugin configuration
[
http://jira.codehaus.org/browse/MNG-3852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-3852.
--
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: (was: 3.0-alpha-3)
3.0-alpha-1
Fixed in [r720432|http://svn.eu.apache.org/viewvc?view=rev&revision=720432] by
updating to Plexus 1.0-beta-2.
> [regression] Collection entries of unequal types are reordered in plugin
> configuration
> --
>
> Key: MNG-3852
> URL: http://jira.codehaus.org/browse/MNG-3852
> Project: Maven 2
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.0-alpha-1
>Reporter: Espen Wiborg
>Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-1
>
>
> It seems that the modelproperty sorting is a bit overzealous. Configure e.g.
> the exec-maven-plugin thusly:
> {code:xml}
>
> org.codehaus.mojo
> exec-maven-plugin
>
> echo
>
> foo
>
> bar
>
>
>
> {code}
> With Maven 2.0.9 I get the expected output
> {noformat}
> [INFO] [exec:exec]
> [INFO] foo /home/espenhw/tmp/target/classes bar
> {noformat}
> While with 3.0-SNAPSHOT I get
> {noformat}
> [INFO] [exec:exec]
> [INFO] foo bar /home/espenhw/tmp/target/classes
> {noformat}
> This breaks the common use case of
> {code:xml}
>
> org.codehaus.mojo
> exec-maven-plugin
>
> java
>
> -cp
>
> my.app.MainClass
>
>
>
> {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] Updated: (MNG-3806) NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range
[ http://jira.codehaus.org/browse/MNG-3806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3806: -- Fix Version/s: (was: 2.1.0-M2) I built with a clean repository and can't reproduce this issue. > NullPointerException when a dependency uses version range and another uses an > actual version incompatible with that range > - > > Key: MNG-3806 > URL: http://jira.codehaus.org/browse/MNG-3806 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.9, 2.1.0-M1 > Environment: Windows XP SP2, Maven see above, JDK 6 >Reporter: Michael Osipov >Priority: Critical > Attachments: debug-2.0.9.log, debug-2.1.0-M1.log > > > This is simply a regression/reoccurence of MNG-2123, test dependency makes > the whole system fail. > Debug logs are attached. > If I test with slf4j-nop with soft version 1.5.5 it works flawlessly. > Here is the source: http://svn.fckeditor.net/FCKeditor.Java/trunk/ r2607 > run with "mvn site package assembly:assembly" -- 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-3936) Remove m2.bat from distribution
[ http://jira.codehaus.org/browse/MNG-3936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3936: -- Fix Version/s: 2.1.0-M2 > Remove m2.bat from distribution > --- > > Key: MNG-3936 > URL: http://jira.codehaus.org/browse/MNG-3936 > Project: Maven 2 > Issue Type: Task > Components: General >Affects Versions: 2.1.0-M1 >Reporter: Paul Benedict >Priority: Minor > Fix For: 2.1.0-M2 > > > As a natural followup to MNG-1395, it is time for m2.bat to finally leave us. -- 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-3803) [regression] System properties not working any more
[
http://jira.codehaus.org/browse/MNG-3803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-3803:
---
Description:
Passing system properties to surefire-plugin used to work fine with Maven 2.0.9:
{code:xml}
maven-surefire-plugin
my.property
my.value
{code}
Now I use Maven 2.1-SNAPSHOT as Embedder launched with m2eclipse.
The properties are not defined any more.
In the logs with Maven 2.0.9 in debug mode I see:
[DEBUG] Setting system property [my.property]=[my.value]
This line is not present in the logs with Maven 2.1.
This compatibility issue is quite annoying...
was:
Passing system properties to surefire-plugin used to work fine with Maven 2.0.9:
maven-surefire-plugin
my.property
my.value
Now I use Maven 2.1-SNAPSHOT as Embedder launched with m2eclipse.
The properties are not defined any more.
In the logs with Maven 2.0.9 in debug mode I see:
[DEBUG] Setting system property [my.property]=[my.value]
This line is not present in the logs with Maven 2.1.
This compatibility issue is quite annoying...
> [regression] System properties not working any more
> ---
>
> Key: MNG-3803
> URL: http://jira.codehaus.org/browse/MNG-3803
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 3.0-alpha-1
>Reporter: Amélie Deltour
>Priority: Minor
> Fix For: 3.0-alpha-3
>
>
> Passing system properties to surefire-plugin used to work fine with Maven
> 2.0.9:
> {code:xml}
>
> maven-surefire-plugin
>
>
>
> my.property
> my.value
>
>
>
>
> {code}
> Now I use Maven 2.1-SNAPSHOT as Embedder launched with m2eclipse.
> The properties are not defined any more.
> In the logs with Maven 2.0.9 in debug mode I see:
> [DEBUG] Setting system property [my.property]=[my.value]
> This line is not present in the logs with Maven 2.1.
> This compatibility issue is quite annoying...
--
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
