[jira] Closed: (MPA-51) Create a New JIRA Project for Maven Site
[ http://jira.codehaus.org/browse/MPA-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MPA-51. --- Assignee: Jason van Zyl Resolution: Fixed Fix Version/s: 2007-q2 > Create a New JIRA Project for Maven Site > > > Key: MPA-51 > URL: http://jira.codehaus.org/browse/MPA-51 > Project: Maven Project Administration > Issue Type: Task >Reporter: Carlos Sanchez >Assignee: Jason van Zyl > Fix For: 2007-q2 > > > The Maven site itself needs a new JIRA project to capture problems, needs, > and tasks related to Maven site improvment. > Hmmm, group_id, artifact_id and version. Left 'em blank. -- 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: (NMAVEN-21) Support for Ruby .NET Compiler
[ http://jira.codehaus.org/browse/NMAVEN-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98829 ] Shane Isbell commented on NMAVEN-21: Latest version of Ruby.NET supports dependencies, so Ruby.NET is at the point where it makes sense to add support for it. They also have an integration package for VS2005, which is compatible with the NMaven addin. > Support for Ruby .NET Compiler > -- > > Key: NMAVEN-21 > URL: http://jira.codehaus.org/browse/NMAVEN-21 > Project: NMaven > Issue Type: New Feature > Environment: Windows, Linux, Mono, Microsoft >Reporter: Shane Isbell >Priority: Minor > > Add support for Ruby .NET compiler. This feature will use the Gardens Point > Ruby .NET compiler: http://plas.fit.qut.edu.au/Ruby.NET/ . -- 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: (MPA-51) Create a New JIRA Project for Maven Site
[ http://jira.codehaus.org/browse/MPA-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened MPA-51: - > Create a New JIRA Project for Maven Site > > > Key: MPA-51 > URL: http://jira.codehaus.org/browse/MPA-51 > Project: Maven Project Administration > Issue Type: Task >Reporter: Carlos Sanchez > > The Maven site itself needs a new JIRA project to capture problems, needs, > and tasks related to Maven site improvment. > Hmmm, group_id, artifact_id and version. Left 'em blank. -- 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: (NMAVEN-48) Packaging and Deploying for Sharp Develop Addins
[ http://jira.codehaus.org/browse/NMAVEN-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98828 ] Shane Isbell commented on NMAVEN-48: SharpDevelop work on hold through at least August, unless someone else wants to pick up the work. > Packaging and Deploying for Sharp Develop Addins > - > > Key: NMAVEN-48 > URL: http://jira.codehaus.org/browse/NMAVEN-48 > Project: NMaven > Issue Type: New Feature > Environment: Sharp Develop >Reporter: Shane Isbell >Priority: Minor > > The feature should include support for generation the sharp develop addin XML > file and for putting the XML addin file (and associated resources) within the > appropriate directory for the IDE to read. -- 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: (NMAVEN-72) Investigate whether MS-CL is compatible with AL 2.0
[ http://jira.codehaus.org/browse/NMAVEN-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98827 ] Shane Isbell commented on NMAVEN-72: Sent question off to legal. Waiting for response. > Investigate whether MS-CL is compatible with AL 2.0 > --- > > Key: NMAVEN-72 > URL: http://jira.codehaus.org/browse/NMAVEN-72 > Project: NMaven > Issue Type: Task >Reporter: Shane Isbell >Priority: Minor > > Investigate whether MS-CL is compatible with AL 2.0: > http://www.microsoft.com/resources/sharedsource/licensingbasics/communitylicense.mspx -- 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: (NMAVEN-71) Replace various hard-coded paths with environment-aware versions
[ http://jira.codehaus.org/browse/NMAVEN-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98826 ] Shane Isbell commented on NMAVEN-71: Campbell, it sounds as though you are working on the cutting-edge. We should look at getting some of those .NET artifacts deployed somewhere. I have made the changes you provided and they are in the trunk. The changes will be in the m2 snapshot repo by next Thursday. Thanks again for the patches. > Replace various hard-coded paths with environment-aware versions > > > Key: NMAVEN-71 > URL: http://jira.codehaus.org/browse/NMAVEN-71 > Project: NMaven > Issue Type: Improvement > Environment: Windows? >Reporter: Campbell Boucher-Burnet >Priority: Blocker > Attachments: patches.zip > > > I'm in an environment where my system drive is not "C:\" and I cannot > guarantee that all .NET related libraries/SDKs are on "C:\" in their default > locations. > As such, it was impossible to build NMavewn (and presumably, the binaries, as > built by default, would not work in my environment, regardless). > So, I am submitting minimal patches that replace hardcoded strings containing > "C:\WINDOWS" and" C:\", respectively, with the SystemRoot and SystemDrive > paths from the enviroment. -- 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: (MPA-89) Apply remaining patches in MNG JIRA
[ http://jira.codehaus.org/browse/MPA-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MPA-89. With John and Kenney I've applied what can be and assigned the rest. So we can start with a clean slate. > Apply remaining patches in MNG JIRA > --- > > Key: MPA-89 > URL: http://jira.codehaus.org/browse/MPA-89 > Project: Maven Project Administration > Issue Type: Task > Components: Issue Management >Reporter: Brett Porter >Assignee: Jason van Zyl > Fix For: Maven 2.1 Prep > > > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&customfield_10170=Yes&pid=10500&assigneeSelect=unassigned&status=1&sorter/field=priority&sorter/order=DESC -- 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-1683) type zip for packaging ?
[ http://jira.codehaus.org/browse/MNG-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1683. -- Resolution: Fixed Simple zip artifact handling dealth with. > type zip for packaging ? > > > Key: MNG-1683 > URL: http://jira.codehaus.org/browse/MNG-1683 > Project: Maven 2 > Issue Type: Improvement > Environment: not significant >Reporter: Olivier Lamy > Fix For: 2.1-alpha-1 > > Attachments: maven-war-plugin.tar.gz, maven-zip-plugin.tar.gz, > MNG-1683.tar.gz, patch1, temp-test_version.zip > > > Hi, > I don't know if the artifact type zip exists (I think not after few test). > But I want to separate the html content and the webapp content (classes, > configuration files and so on). > The use case is to separate this different works (html designer and java > developpement) and production installation (one is to an http server and the > other is on an app server) in two artifacts with separate versionning. > But the zip is not recognized. > Then I would like to use it as an artifact with maven's features (snapshot, > pom, version, goals : install, deploy release and all others). > Add it to the webapp dependencies (needed only for developpment or unit > tests). > With this type of dependency the zip content could be unpacked to a directory > in the exploded webapp. (certainly need hack on the maven-war-plugin). > I have certainly the workaround to declare this as jar and using the assembly > plugin to generate a zip. > But I can't use install release deploy or something else to manage the > generated zip which is not an artifact. > Thanks for help or workaround. > - Olivier -- 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-2025) POM is still not read using the right encoding
[ http://jira.codehaus.org/browse/MNG-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2025: --- Patch Submitted: (was: [Yes]) > POM is still not read using the right encoding > -- > > Key: MNG-2025 > URL: http://jira.codehaus.org/browse/MNG-2025 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Stefan Hübner >Assignee: Jason van Zyl >Priority: Critical > Fix For: 2.1.x > > Attachments: MNG-2025-maven-model-testcases.patch, > MNG-2025-maven-project-testcases.patch > > > IIRC XML standard says that default encoding is UTF-8 for xml files > That can be overriden with > > But files without header saved as UTF8 are not parsed in some systems (eg > windows, solaris), while files saved as other encoding (I believe it was > ansi) break under a Mac mini with yellowdog linux -- 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-2254) the encoding parameter in xml declaration of POM is ignored
[ http://jira.codehaus.org/browse/MNG-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2254: --- Patch Submitted: (was: [Yes]) > the encoding parameter in xml declaration of POM is ignored > > > Key: MNG-2254 > URL: http://jira.codehaus.org/browse/MNG-2254 > Project: Maven 2 > Issue Type: Bug >Reporter: Naoki Nose >Assignee: Jason van Zyl > Fix For: 2.1.x > > Attachments: DefaultMavenProjectBuilder.diff, modello-plugin-xpp3.diff > > > DefaultMavenProjectBuilder reads POM in system default character encoding, > and the encoding parameter in xml declartion is ignored. > to fix this problem, We should > - fix modello-plugin-xpp3 to use the xml parser which is able to handle the > encoding parameter properly > - regenerate maven-model using fixed modello-plugin-xpp3 > - fix DefaultMavenProjectBuilder to use regenerated maven-model properly. -- 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-2546) Allow plugin executions in the "super-init" phase before reactor sorting of modules build order
[ http://jira.codehaus.org/browse/MNG-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2546: --- Patch Submitted: (was: [Yes]) > Allow plugin executions in the "super-init" phase before reactor sorting of > modules build order > --- > > Key: MNG-2546 > URL: http://jira.codehaus.org/browse/MNG-2546 > Project: Maven 2 > Issue Type: Improvement > Components: Reactor and workspace >Affects Versions: 2.0.4 >Reporter: Binyan >Assignee: Jason van Zyl > Attachments: MNG-2546-maven-core.patch > > > As seen here, > http://www.nabble.com/How-to-execute-a-plugin-prior-to-the-reactor-sorting--tf2062739.html#a5682349. > I also have the need to bind my maven-pde-plugin to a phase before the > reactor sorting of project build order happens. My plugin is being developed > to build eclipse plugins, features, fragments, update sites and products. > Right now I can build plugins and features. However the order has to > constantly be managed by the user taking information from the eclipse > descriptors and adding it to the pom file. For plugin projects I can bind to > a phase before the compile phase and dynamically analyze the eclipse plugin > descriptors and add the necessary dependencies/resources to the MavenProject > instance and all is well. For feature projects, I also can dynamically > analyze the eclipse feature descriptor and add the necessary resources to the > MavenProject instance. However, features depend on other plugins, fragments > and features. While I can dynamicaly add the plugins, fragments and features > to the MavenProject as dependencies they are not taken into context as the > reactor has already computed the sorting order. > What would be perfect is if there was a "super-init" phase that plugins could > bind to and be executed in before the normal declared lifecycle happened. > Therefore no matter what the lifecycle was, the "super-init" phase would be > available. Then plugins could do things like augmenting the super-pom with > build #'s/identifiers, dependencies, dynamic projects, etc all before maven > gets going. That would solve the problem myself and others have as well as > be 100% backwards compatible. This super-init phase (please pick a better > name) would e available to reactor and non-reactor builds. A more specific > fix would be to allow plugins to ask the reactor to reevaluate the build > order. -- 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-1683) type zip for packaging ?
[ http://jira.codehaus.org/browse/MNG-1683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-1683: --- Fix Version/s: 2.1-alpha-1 Olamy can you push these other patches to the respective plugins. I will add support for the zip type. > type zip for packaging ? > > > Key: MNG-1683 > URL: http://jira.codehaus.org/browse/MNG-1683 > Project: Maven 2 > Issue Type: Improvement > Environment: not significant >Reporter: Olivier Lamy > Fix For: 2.1-alpha-1 > > Attachments: maven-war-plugin.tar.gz, maven-zip-plugin.tar.gz, > MNG-1683.tar.gz, patch1, temp-test_version.zip > > > Hi, > I don't know if the artifact type zip exists (I think not after few test). > But I want to separate the html content and the webapp content (classes, > configuration files and so on). > The use case is to separate this different works (html designer and java > developpement) and production installation (one is to an http server and the > other is on an app server) in two artifacts with separate versionning. > But the zip is not recognized. > Then I would like to use it as an artifact with maven's features (snapshot, > pom, version, goals : install, deploy release and all others). > Add it to the webapp dependencies (needed only for developpment or unit > tests). > With this type of dependency the zip content could be unpacked to a directory > in the exploded webapp. (certainly need hack on the maven-war-plugin). > I have certainly the workaround to declare this as jar and using the assembly > plugin to generate a zip. > But I can't use install release deploy or something else to manage the > generated zip which is not an artifact. > Thanks for help or workaround. > - Olivier -- 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: (MPA-51) Create a New JIRA Project for Maven Site
[ http://jira.codehaus.org/browse/MPA-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MPA-51. > Create a New JIRA Project for Maven Site > > > Key: MPA-51 > URL: http://jira.codehaus.org/browse/MPA-51 > Project: Maven Project Administration > Issue Type: Task >Reporter: Carlos Sanchez > > The Maven site itself needs a new JIRA project to capture problems, needs, > and tasks related to Maven site improvment. > Hmmm, group_id, artifact_id and version. Left 'em blank. -- 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-2591) Plugins are merged incorrectly
[ http://jira.codehaus.org/browse/MNG-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2591: -- Priority: Blocker Fix Version/s: 2.1-alpha-1 > Plugins are merged incorrectly > -- > > Key: MNG-2591 > URL: http://jira.codehaus.org/browse/MNG-2591 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.4 > Environment: Windows XP >Reporter: Allan Shoup >Assignee: John Casey >Priority: Blocker > Fix For: 2.1-alpha-1 > > Attachments: effective-child-pom.xml, test-poms.zip > > > This bug is similar to > http://jira.codehaus.org/browse/MANTRUN-57;jsessionid=awtyLFBPEQN6vVmwu4 - > the difference being the plugins are not correctly merged. > In the parent's POM, the following was defined: > > > > > org.apache.maven.plugins > maven-eclipse-plugin > > true > > > parentBuildCommand > > > > > > > > in the child's POM, the following was defined. > > > > > org.apache.maven.plugins > maven-eclipse-plugin > > > > childBuildCommand > > > > > > > > I expect the effective POM to look like this: > > > > > maven-eclipse-plugin > > > > parentBuildCommand > > > childBuildCommand > > > true > > > > > > Outside of the common problem of the element being duplicated, > here's the issue this bug is trying to address: > In the effective pom, the the element was correctly merged, > however, the element was not. It seems like the merging only > correctly happens down to a given level. > I noticed that > http://jira.codehaus.org/browse/MNG-2297;jsessionid=awtyLFBPEQN6vVmwu4 has a > patch attached, so this may be fixed in 2.0.5, I just wanted to raise the use > case in case that patch did not address this specific problem. > I'm attaching the POMs needed to reproduce the problem and the effective POM > for the child. -- 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-3041) Apply filters to files in WEB-INF/*.xml
[ http://jira.codehaus.org/browse/MNG-3041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98821 ] Wendy Smoak commented on MNG-3041: -- The user list would be a better place to discuss this one, you can find subscription info here: http://maven.apache.org/mail-lists.html The examples here should help: http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-webresources.html > Apply filters to files in WEB-INF/*.xml > --- > > Key: MNG-3041 > URL: http://jira.codehaus.org/browse/MNG-3041 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.0.6 >Reporter: Anthony Whitford > > I have a WEB-INF/components.xml file that I would like to apply filters to. > I figured I could do something like: > > > > src/main/resources > > components.xml > > > > src/main/resources > > components.xml > > true > .. > > > > And this works -- except for one silly thing: the components.xml file, now > sitting in the target directory, is not included in the war. I tried several > different targetPaths and I can't get it to work... > It might be easier to to separate filtering from just processing resources. > (It might be nice to be able to tokenize almost any file.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3041) Apply filters to files in WEB-INF/*.xml
Apply filters to files in WEB-INF/*.xml --- Key: MNG-3041 URL: http://jira.codehaus.org/browse/MNG-3041 Project: Maven 2 Issue Type: Improvement Affects Versions: 2.0.6 Reporter: Anthony Whitford I have a WEB-INF/components.xml file that I would like to apply filters to. I figured I could do something like: src/main/resources components.xml src/main/resources components.xml true .. And this works -- except for one silly thing: the components.xml file, now sitting in the target directory, is not included in the war. I tried several different targetPaths and I can't get it to work... It might be easier to to separate filtering from just processing resources. (It might be nice to be able to tokenize almost any file.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-2289) Newer SNAPSHOT parents in the remote repository are ignored
[ http://jira.codehaus.org/browse/MNG-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened MNG-2289: --- > Newer SNAPSHOT parents in the remote repository are ignored > --- > > Key: MNG-2289 > URL: http://jira.codehaus.org/browse/MNG-2289 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.5 >Reporter: Joerg Schaible >Assignee: Jason van Zyl >Priority: Critical > Fix For: 2.0.7 > > Attachments: example.zip, mng2289.zip > > > If a POM inherits from another one in the repository with a SNAPSHOT version, > it will only look into the local repository for it, but not in the remote > repositories. > E.g. if a POM has following parent:... > > pom.maven > super > SNAPSHOT > > ... > it will not find a newer version of "pom.maven:super:SNAPSHOT" in a remote > repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2289) Newer SNAPSHOT parents in the remote repository are ignored
[ http://jira.codehaus.org/browse/MNG-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2289. - Resolution: Cannot Reproduce > Newer SNAPSHOT parents in the remote repository are ignored > --- > > Key: MNG-2289 > URL: http://jira.codehaus.org/browse/MNG-2289 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.5 >Reporter: Joerg Schaible >Assignee: Jason van Zyl >Priority: Critical > Fix For: 2.0.7 > > Attachments: example.zip, mng2289.zip > > > If a POM inherits from another one in the repository with a SNAPSHOT version, > it will only look into the local repository for it, but not in the remote > repositories. > E.g. if a POM has following parent:... > > pom.maven > super > SNAPSHOT > > ... > it will not find a newer version of "pom.maven:super:SNAPSHOT" in a remote > repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3038) Transitive DepMan not working (per MNG-1577) [use case attached]
[
http://jira.codehaus.org/browse/MNG-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98817
]
Joakim Erdfelt commented on MNG-3038:
-
Another use case.
You have 4 projects. A,B,C,D
You have the following defined. (where notation is in the form [Project] ->
[Dependency])
A -> B
A -> C
B -> D
C -> D
This forms a graph shaped like a diamond.
The following dependency management sections are defined in the above graph.
B has a depMan that says D version 2.0
C has a depMan that says D version 1.0
What version of D is in use at project A ?
> Transitive DepMan not working (per MNG-1577) [use case attached]
>
>
> Key: MNG-3038
> URL: http://jira.codehaus.org/browse/MNG-3038
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.5, 2.0.6
>Reporter: Joakim Erdfelt
>Assignee: Patrick Schneider
> Attachments: carlos_transitive_version.tar.gz
>
>
> When working with the example use case described by Carlos on the MNG-1577
> thread.
> http://www.nabble.com/Re%3A--vote--MNG-1577-as-the-default-behavior-p9506667s177.html
> {noformat}
> What about this use case for transitive dependencyManagement? has been tested?
> A -> B -> C -> D
> C depends on D 1.0
> B has D 2.0 in dependencyManagement, no D in dependencies
> A should get D 2.0
> {noformat}
> It was discovered that this does not work.
> Sample Project / Use Case is attached. (655 bytes)
--
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-3038) Transitive DepMan not working (per MNG-1577) [use case attached]
[
http://jira.codehaus.org/browse/MNG-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98815
]
Joakim Erdfelt commented on MNG-3038:
-
The integration test IT0121 demonstrates this use case.
> Transitive DepMan not working (per MNG-1577) [use case attached]
>
>
> Key: MNG-3038
> URL: http://jira.codehaus.org/browse/MNG-3038
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.5, 2.0.6
>Reporter: Joakim Erdfelt
>Assignee: Patrick Schneider
> Attachments: carlos_transitive_version.tar.gz
>
>
> When working with the example use case described by Carlos on the MNG-1577
> thread.
> http://www.nabble.com/Re%3A--vote--MNG-1577-as-the-default-behavior-p9506667s177.html
> {noformat}
> What about this use case for transitive dependencyManagement? has been tested?
> A -> B -> C -> D
> C depends on D 1.0
> B has D 2.0 in dependencyManagement, no D in dependencies
> A should get D 2.0
> {noformat}
> It was discovered that this does not work.
> Sample Project / Use Case is attached. (655 bytes)
--
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-3039) mvn.bat fails
[ http://jira.codehaus.org/browse/MNG-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-3039. -- Resolution: Fixed > mvn.bat fails > - > > Key: MNG-3039 > URL: http://jira.codehaus.org/browse/MNG-3039 > Project: Maven 2 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.6 >Reporter: Mark Hobson >Assignee: Jason van Zyl >Priority: Blocker > Fix For: 2.0.7 > > Attachments: patch.txt > > > 2.0.7-SNAPSHOT fails to launch under Windows: > [EMAIL PROTECTED] My Documents]$ mvn.bat --version > Exception in thread "main" java.lang.NoClassDefFoundError: > org/codehaus/classworlds/Launcher > Caused by MNG-2503 being merged from trunk into 2.0.x. Attached patch fixes > this. -- 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-3039) mvn.bat fails
[ http://jira.codehaus.org/browse/MNG-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl reopened MNG-3039: > mvn.bat fails > - > > Key: MNG-3039 > URL: http://jira.codehaus.org/browse/MNG-3039 > Project: Maven 2 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.6 >Reporter: Mark Hobson >Assignee: Jason van Zyl >Priority: Blocker > Fix For: 2.0.7 > > Attachments: patch.txt > > > 2.0.7-SNAPSHOT fails to launch under Windows: > [EMAIL PROTECTED] My Documents]$ mvn.bat --version > Exception in thread "main" java.lang.NoClassDefFoundError: > org/codehaus/classworlds/Launcher > Caused by MNG-2503 being merged from trunk into 2.0.x. Attached patch fixes > this. -- 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-2577) Allow interpolation of Properties in settings.xml
[ http://jira.codehaus.org/browse/MNG-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98812 ] Dimitar Dimitrov commented on MNG-2577: --- Do you mean that you will not be expanding properties defined in profiles and referenced in other elements; or do you mean all properties defined in profiles and referenced anywhere in settings.xml? If the latter, I can guarantee that there a lot of users would be banging their heads and try to make it work, as many people assume that what they read in a book must be true. In this case, just to limit the damage, I would suggest that you contact Mergere so they can amend the book. > Allow interpolation of Properties in settings.xml > - > > Key: MNG-2577 > URL: http://jira.codehaus.org/browse/MNG-2577 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0.4, 2.0.5 >Reporter: Michael Locher >Assignee: John Casey >Priority: Critical > Attachments: DefaultMavenSettingsBuilder.java.diff > > > the attached patch (against 2.0.4) allows interpolation of system properties > into the .m2/settings.xml > and interpolation of system properties and the properties of profiles found > in .m2/settings.xml (if they are activeByDefault) into conf/settings.xml > these features are necessary in order to propagate user account settings > defined in user-specific .m2/settings.xml into server sections of the > institution-wide conf/settings.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DOXIA-118) Image directory list field for PDF generation
[ http://jira.codehaus.org/browse/DOXIA-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Redmond updated DOXIA-118: --- Attachment: mylar-context.zip > Image directory list field for PDF generation > - > > Key: DOXIA-118 > URL: http://jira.codehaus.org/browse/DOXIA-118 > Project: doxia > Issue Type: Bug >Reporter: Eric Redmond > Attachments: doxia-book-itextimage.diff, mylar-context.zip > > > PDFs via iText that contain local images will not generate correctly without > access to the image directory via the classloader... added a field to allow a > list of accessible image directories -- 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-118) Image directory list field for PDF generation
[ http://jira.codehaus.org/browse/DOXIA-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Redmond updated DOXIA-118: --- Attachment: doxia-book-itextimage.diff add image dir to classpath > Image directory list field for PDF generation > - > > Key: DOXIA-118 > URL: http://jira.codehaus.org/browse/DOXIA-118 > Project: doxia > Issue Type: Bug >Reporter: Eric Redmond > Attachments: doxia-book-itextimage.diff, mylar-context.zip > > > PDFs via iText that contain local images will not generate correctly without > access to the image directory via the classloader... added a field to allow a > list of accessible image directories -- 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-118) Image directory list field for PDF generation
Image directory list field for PDF generation - Key: DOXIA-118 URL: http://jira.codehaus.org/browse/DOXIA-118 Project: doxia Issue Type: Bug Reporter: Eric Redmond PDFs via iText that contain local images will not generate correctly without access to the image directory via the classloader... added a field to allow a list of accessible image directories -- 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-117) Docbook Rendered for Doxia Book
[ http://jira.codehaus.org/browse/DOXIA-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Redmond updated DOXIA-117: --- Attachment: mylar-context.zip add context > Docbook Rendered for Doxia Book > --- > > Key: DOXIA-117 > URL: http://jira.codehaus.org/browse/DOXIA-117 > Project: doxia > Issue Type: New Feature >Reporter: Eric Redmond > Attachments: doxia-book-docbook.diff, mylar-context.zip > > > Uses Docbook Sink to render a doxia book in docbook format -- 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-117) Docbook Rendered for Doxia Book
[ http://jira.codehaus.org/browse/DOXIA-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Redmond updated DOXIA-117: --- Attachment: doxia-book-docbook.diff Adds docbook render support > Docbook Rendered for Doxia Book > --- > > Key: DOXIA-117 > URL: http://jira.codehaus.org/browse/DOXIA-117 > Project: doxia > Issue Type: New Feature >Reporter: Eric Redmond > Attachments: doxia-book-docbook.diff > > > Uses Docbook Sink to render a doxia book in docbook format -- 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-117) Docbook Rendered for Doxia Book
Docbook Rendered for Doxia Book --- Key: DOXIA-117 URL: http://jira.codehaus.org/browse/DOXIA-117 Project: doxia Issue Type: New Feature Reporter: Eric Redmond Uses Docbook Sink to render a doxia book in docbook format -- 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-116) DocBook Simple module "book" type Sink
[ http://jira.codehaus.org/browse/DOXIA-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Redmond updated DOXIA-116: --- Attachment: doxia-module-docbook-simple.diff Adds "book" sink extension > DocBook Simple module "book" type Sink > -- > > Key: DOXIA-116 > URL: http://jira.codehaus.org/browse/DOXIA-116 > Project: doxia > Issue Type: New Feature >Reporter: Eric Redmond > Attachments: doxia-module-docbook-simple.diff, mylar-context.zip, > mylar-context.zip > > > Extended the "DockBookSink" class to handle "book" type, rather than just > "article". Each book "chapter" is a parsed Source. -- 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-116) DocBook Simple module "book" type Sink
[ http://jira.codehaus.org/browse/DOXIA-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Redmond updated DOXIA-116: --- Attachment: mylar-context.zip > DocBook Simple module "book" type Sink > -- > > Key: DOXIA-116 > URL: http://jira.codehaus.org/browse/DOXIA-116 > Project: doxia > Issue Type: New Feature >Reporter: Eric Redmond > Attachments: doxia-module-docbook-simple.diff, mylar-context.zip, > mylar-context.zip > > > Extended the "DockBookSink" class to handle "book" type, rather than just > "article". Each book "chapter" is a parsed Source. -- 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-116) DocBook Simple module "book" type Sink
[ http://jira.codehaus.org/browse/DOXIA-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Redmond updated DOXIA-116: --- Attachment: mylar-context.zip docbooksink book extension > DocBook Simple module "book" type Sink > -- > > Key: DOXIA-116 > URL: http://jira.codehaus.org/browse/DOXIA-116 > Project: doxia > Issue Type: New Feature >Reporter: Eric Redmond > Attachments: mylar-context.zip > > > Extended the "DockBookSink" class to handle "book" type, rather than just > "article". Each book "chapter" is a parsed Source. -- 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-116) DocBook Simple module "book" type Sink
DocBook Simple module "book" type Sink -- Key: DOXIA-116 URL: http://jira.codehaus.org/browse/DOXIA-116 Project: doxia Issue Type: New Feature Reporter: Eric Redmond Extended the "DockBookSink" class to handle "book" type, rather than just "article". Each book "chapter" is a parsed Source. -- 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: (MECLIPSE-267) Resolve version ranges in make-artifacts
[ http://jira.codehaus.org/browse/MECLIPSE-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez updated MECLIPSE-267: Summary: Resolve version ranges in make-artifacts (was: Enhance make-artifacts to not create POMs that have version ranges) > Resolve version ranges in make-artifacts > > > Key: MECLIPSE-267 > URL: http://jira.codehaus.org/browse/MECLIPSE-267 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: PDE support >Affects Versions: 2.3 >Reporter: Micah Whitacre >Assignee: Carlos Sanchez > Fix For: 2.4 > > Attachments: MECLIPSE-267-maven-eclipse-plugin.patch > > > Currently when using the make-artifacts goal to deploy Eclipse artifacts to a > remote repository the POMs are created in such a way the versions of the > dependencies have ranges similar to [3.3,4). This information is pulled from > the Manifest. I'd like a way to specify not to use those version ranges in > the POM but to instead have a soft dependency on a specific version. The > situation that is occurring is that when I have deployed both Eclipse 3.2 and > 3.3 endstates to a remote repository, the 3.2 dependencies have ranges > specified which then pull in the 3.3 endstates. This causes conflicts when I > want to only include 3.2 endstates. If there was a way to 1. not use version > ranges in the POM and 2. instead have a soft dependency on a specific > version. This would eliminate the need to specify each and every Eclipse 3.2 > artifact for fear a transitive 3.3 dependency got pulled in. > I have also seen this cause errors when a transitive dependency pulls in a > 3.3 endstate that has conflicting version ranges for an artifact I have a > dependency on. Since the 3.3 endstates will have version ranges of [3.3,4) > but I might specify 3.2 dependencies, if I have a first class dependency on > 3.2 and a transitive dependency on the same artifact but the range is > [3.3,4), I will not be able to build my project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MJAR-75) [PATCH] Wrong artifact type attached to the project by the test-jar goal
[
http://jira.codehaus.org/browse/MJAR-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piotr Tabor updated MJAR-75:
Attachment: maven-jar-plugin-MJAR-75.diff
Patch
> [PATCH] Wrong artifact type attached to the project by the test-jar goal
> -
>
> Key: MJAR-75
> URL: http://jira.codehaus.org/browse/MJAR-75
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.0, 2.1, 2.2
> Environment: All
>Reporter: Piotr Tabor
>Priority: Critical
> Attachments: maven-jar-plugin-MJAR-75.diff
>
>
> The test-jar goal attaches to the project
> "org.apache.maven.its.it0121:model:jar" such a artifact:
> - org.apache.maven.its.it0121:model:*jar*:tests
> It should attach such an artifact:
> - org.apache.maven.its.it0121:model:*test-jar*:tests
> The wrong artifacts "naming" leads to MNG-2871 problem:
> The code does not work (because the strings are different:
> --MavenProject:
> replaceWithActiveArtifact(...)-
>
> Iterator itr = ref.getAttachedArtifacts().iterator();
> while(itr.hasNext()) {
> Artifact attached = (Artifact) itr.next();
> if(
> attached.getDependencyConflictId().equals(pluginArtifact.getDependencyConflictId())
> ) {
> ... (resolve as active's project) ...
>}
> ...
> ---
> pluginArtifact.getDependencyConflictId() is :
> org.apache.maven.its.it0121:model:*test-jar*:tests
> attached.getDependencyConflictId() is :
> org.apache.maven.its.it0121:model:*jar*:tests
> For test-case: look at test (it121) attached to:
> http://jira.codehaus.org/browse/MNG-2871
--
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: (MECLIPSE-267) Enhance make-artifacts to not create POMs that have version ranges
[ http://jira.codehaus.org/browse/MECLIPSE-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MECLIPSE-267. --- Assignee: Carlos Sanchez Resolution: Fixed Fix Version/s: 2.4 Used a different solution, but fixed anyway > Enhance make-artifacts to not create POMs that have version ranges > -- > > Key: MECLIPSE-267 > URL: http://jira.codehaus.org/browse/MECLIPSE-267 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: PDE support >Affects Versions: 2.3 >Reporter: Micah Whitacre >Assignee: Carlos Sanchez > Fix For: 2.4 > > Attachments: MECLIPSE-267-maven-eclipse-plugin.patch > > > Currently when using the make-artifacts goal to deploy Eclipse artifacts to a > remote repository the POMs are created in such a way the versions of the > dependencies have ranges similar to [3.3,4). This information is pulled from > the Manifest. I'd like a way to specify not to use those version ranges in > the POM but to instead have a soft dependency on a specific version. The > situation that is occurring is that when I have deployed both Eclipse 3.2 and > 3.3 endstates to a remote repository, the 3.2 dependencies have ranges > specified which then pull in the 3.3 endstates. This causes conflicts when I > want to only include 3.2 endstates. If there was a way to 1. not use version > ranges in the POM and 2. instead have a soft dependency on a specific > version. This would eliminate the need to specify each and every Eclipse 3.2 > artifact for fear a transitive 3.3 dependency got pulled in. > I have also seen this cause errors when a transitive dependency pulls in a > 3.3 endstate that has conflicting version ranges for an artifact I have a > dependency on. Since the 3.3 endstates will have version ranges of [3.3,4) > but I might specify 3.2 dependencies, if I have a first class dependency on > 3.2 and a transitive dependency on the same artifact but the range is > [3.3,4), I will not be able to build my project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAR-75) [PATCH] Wrong artifact type attached to the project by the test-jar goal
[PATCH] Wrong artifact type attached to the project by the test-jar goal
-
Key: MJAR-75
URL: http://jira.codehaus.org/browse/MJAR-75
Project: Maven 2.x Jar Plugin
Issue Type: Bug
Affects Versions: 2.1, 2.0, 2.2
Environment: All
Reporter: Piotr Tabor
Priority: Critical
The test-jar goal attaches to the project
"org.apache.maven.its.it0121:model:jar" such a artifact:
- org.apache.maven.its.it0121:model:*jar*:tests
It should attach such an artifact:
- org.apache.maven.its.it0121:model:*test-jar*:tests
The wrong artifacts "naming" leads to MNG-2871 problem:
The code does not work (because the strings are different:
--MavenProject:
replaceWithActiveArtifact(...)-
Iterator itr = ref.getAttachedArtifacts().iterator();
while(itr.hasNext()) {
Artifact attached = (Artifact) itr.next();
if(
attached.getDependencyConflictId().equals(pluginArtifact.getDependencyConflictId())
) {
... (resolve as active's project) ...
}
...
---
pluginArtifact.getDependencyConflictId() is :
org.apache.maven.its.it0121:model:*test-jar*:tests
attached.getDependencyConflictId() is :
org.apache.maven.its.it0121:model:*jar*:tests
For test-case: look at test (it121) attached to:
http://jira.codehaus.org/browse/MNG-2871
--
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-2591) Plugins are merged incorrectly
[ http://jira.codehaus.org/browse/MNG-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98795 ] John Casey commented on MNG-2591: - sorry, that maven-project revId should be 545315. > Plugins are merged incorrectly > -- > > Key: MNG-2591 > URL: http://jira.codehaus.org/browse/MNG-2591 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.4 > Environment: Windows XP >Reporter: Allan Shoup >Assignee: John Casey > Attachments: effective-child-pom.xml, test-poms.zip > > > This bug is similar to > http://jira.codehaus.org/browse/MANTRUN-57;jsessionid=awtyLFBPEQN6vVmwu4 - > the difference being the plugins are not correctly merged. > In the parent's POM, the following was defined: > > > > > org.apache.maven.plugins > maven-eclipse-plugin > > true > > > parentBuildCommand > > > > > > > > in the child's POM, the following was defined. > > > > > org.apache.maven.plugins > maven-eclipse-plugin > > > > childBuildCommand > > > > > > > > I expect the effective POM to look like this: > > > > > maven-eclipse-plugin > > > > parentBuildCommand > > > childBuildCommand > > > true > > > > > > Outside of the common problem of the element being duplicated, > here's the issue this bug is trying to address: > In the effective pom, the the element was correctly merged, > however, the element was not. It seems like the merging only > correctly happens down to a given level. > I noticed that > http://jira.codehaus.org/browse/MNG-2297;jsessionid=awtyLFBPEQN6vVmwu4 has a > patch attached, so this may be fixed in 2.0.5, I just wanted to raise the use > case in case that patch did not address this specific problem. > I'm attaching the POMs needed to reproduce the problem and the effective POM > for the child. -- 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-2591) Plugins are merged incorrectly
[ http://jira.codehaus.org/browse/MNG-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98792 ] John Casey commented on MNG-2591: - See http://docs.codehaus.org/display/MAVENUSER/FAQs-1#FAQs-1-HowdoImergealistofconfigurationitemsinaparentPOMwiththoseinachildPOM%3F > Plugins are merged incorrectly > -- > > Key: MNG-2591 > URL: http://jira.codehaus.org/browse/MNG-2591 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.4 > Environment: Windows XP >Reporter: Allan Shoup >Assignee: John Casey > Attachments: effective-child-pom.xml, test-poms.zip > > > This bug is similar to > http://jira.codehaus.org/browse/MANTRUN-57;jsessionid=awtyLFBPEQN6vVmwu4 - > the difference being the plugins are not correctly merged. > In the parent's POM, the following was defined: > > > > > org.apache.maven.plugins > maven-eclipse-plugin > > true > > > parentBuildCommand > > > > > > > > in the child's POM, the following was defined. > > > > > org.apache.maven.plugins > maven-eclipse-plugin > > > > childBuildCommand > > > > > > > > I expect the effective POM to look like this: > > > > > maven-eclipse-plugin > > > > parentBuildCommand > > > childBuildCommand > > > true > > > > > > Outside of the common problem of the element being duplicated, > here's the issue this bug is trying to address: > In the effective pom, the the element was correctly merged, > however, the element was not. It seems like the merging only > correctly happens down to a given level. > I noticed that > http://jira.codehaus.org/browse/MNG-2297;jsessionid=awtyLFBPEQN6vVmwu4 has a > patch attached, so this may be fixed in 2.0.5, I just wanted to raise the use > case in case that patch did not address this specific problem. > I'm attaching the POMs needed to reproduce the problem and the effective POM > for the child. -- 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-2591) Plugins are merged incorrectly
[
http://jira.codehaus.org/browse/MNG-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-2591.
---
Resolution: Fixed
I'll add a new FAQ entry for this, but essentially it's doing the right thing
by default. Since plugin configurations are handled as XML DOM instances by the
core, there is an ever-present struggle between when to merge child elements'
values with one another (when the child's overrides the parent's, for
example), and when you want to append new child elements to the existing list
(as in the example above, or any time you have a list of items to aggregate
during inheritance).
We've solved this problem using an attribute, 'combine.children'. You simply
specify this attribute, with the value of "append" at the parent element where
such aggregation should occur, and Maven will switch its merge behavior for
that element's children.
NOTE: I fixed this behavior in Maven's trunk; previously, it had been putting
the parent POM's sub-elements AFTER those of the child. This is inconsistent
with other inheritance functions, so I've reversed the ordering to truly append
the child's elements.
So, to recap:
parent:
{code:xml}
one
two
{code}
child:
{code:xml}
three
{code}
result:
{code:xml}
one
two
three
{code}
(If you're using an earlier version of Maven than the present trunk, order will
be three, one, two.)
Revision IDs affecting this change are:
plexus-utils: revId 6546
maven-project: revId 513038
I also added a couple unit tests to org.apache.maven.project.ModelUtilsTest in
maven-project/src/test/java to cover these cases.
> Plugins are merged incorrectly
> --
>
> Key: MNG-2591
> URL: http://jira.codehaus.org/browse/MNG-2591
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.4
> Environment: Windows XP
>Reporter: Allan Shoup
>Assignee: John Casey
> Attachments: effective-child-pom.xml, test-poms.zip
>
>
> This bug is similar to
> http://jira.codehaus.org/browse/MANTRUN-57;jsessionid=awtyLFBPEQN6vVmwu4 -
> the difference being the plugins are not correctly merged.
> In the parent's POM, the following was defined:
>
>
>
>
> org.apache.maven.plugins
> maven-eclipse-plugin
>
> true
>
>
> parentBuildCommand
>
>
>
>
>
>
>
> in the child's POM, the following was defined.
>
>
>
>
> org.apache.maven.plugins
> maven-eclipse-plugin
>
>
>
> childBuildCommand
>
>
>
>
>
>
>
> I expect the effective POM to look like this:
>
>
>
>
> maven-eclipse-plugin
>
>
>
> parentBuildCommand
>
>
> childBuildCommand
>
>
> true
>
>
>
>
>
> Outside of the common problem of the element being duplicated,
> here's the issue this bug is trying to address:
> In the effective pom, the the element was correctly merged,
> however, the element was not. It seems like the merging only
> correctly happens down to a given level.
> I noticed that
> http://jira.codehaus.org/browse/MNG-2297;jsessionid=awtyLFBPEQN6vVmwu4 has a
> patch attached, so this may be fixed in 2.0.5, I just wanted to raise the use
> case in case that patch did not address this specific problem.
> I'm attaching the POMs needed to reproduce the problem and the effective POM
> for the child.
--
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-2591) Plugins are merged incorrectly
[ http://jira.codehaus.org/browse/MNG-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-2591: Priority: (was: Major) Assignee: John Casey Description: This bug is similar to http://jira.codehaus.org/browse/MANTRUN-57;jsessionid=awtyLFBPEQN6vVmwu4 - the difference being the plugins are not correctly merged. In the parent's POM, the following was defined: org.apache.maven.plugins maven-eclipse-plugin true parentBuildCommand in the child's POM, the following was defined. org.apache.maven.plugins maven-eclipse-plugin childBuildCommand I expect the effective POM to look like this: maven-eclipse-plugin parentBuildCommand childBuildCommand true Outside of the common problem of the element being duplicated, here's the issue this bug is trying to address: In the effective pom, the the element was correctly merged, however, the element was not. It seems like the merging only correctly happens down to a given level. I noticed that http://jira.codehaus.org/browse/MNG-2297;jsessionid=awtyLFBPEQN6vVmwu4 has a patch attached, so this may be fixed in 2.0.5, I just wanted to raise the use case in case that patch did not address this specific problem. I'm attaching the POMs needed to reproduce the problem and the effective POM for the child. was: This bug is similar to http://jira.codehaus.org/browse/MANTRUN-57;jsessionid=awtyLFBPEQN6vVmwu4 - the difference being the plugins are not correctly merged. In the parent's POM, the following was defined: org.apache.maven.plugins maven-eclipse-plugin true parentBuildCommand in the child's POM, the following was defined. org.apache.maven.plugins maven-eclipse-plugin childBuildCommand I expect the effective POM to look like this: maven-eclipse-plugin parentBuildCommand childBuildCommand true Outside of the common problem of the element being duplicated, here's the issue this bug is trying to address: In the effective pom, the the element was correctly merged, however, the element was not. It seems like the merging only correctly happens down to a given level. I noticed that http://jira.codehaus.org/browse/MNG-2297;jsessionid=awtyLFBPEQN6vVmwu4 has a patch attached, so this may be fixed in 2.0.5, I just wanted to raise the use case in case that patch did not address this specific problem. I'm attaching the POMs needed to reproduce the problem and the effective POM for the child. Patch Submitted: (was: [Yes]) > Plugins are merged incorrectly > -- > > Key: MNG-2591 > URL: http://jira.codehaus.org/browse/MNG-2591 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.4 > Environment: Windows XP >Reporter: Allan Shoup >Assignee: John Casey > Attachments: effective-child-pom.xml, test-poms.zip > > > This bug is similar to > http://jira.codehaus.org/browse/MANTRUN-57;jsessionid=awtyLFBPEQN6vVmwu4 - > the difference being the plugins are not correctly merged. > In the parent's POM, the following was defined: > > > > > org.apache.maven.plugins > maven-eclipse-plugin > > true > > > parentBuildCommand > > > > > > > > in the child's POM, the following was defined
[jira] Closed: (CONTINUUM-691) Build Numbers are obscured by the queuing/building icon
[ http://jira.codehaus.org/browse/CONTINUUM-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edwin Punzalan closed CONTINUUM-691. Resolution: Fixed Fixed in SVN > Build Numbers are obscured by the queuing/building icon > --- > > Key: CONTINUUM-691 > URL: http://jira.codehaus.org/browse/CONTINUUM-691 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.0.3 >Reporter: Christian Gruber >Assignee: Edwin Punzalan >Priority: Critical > Fix For: 1.1-alpha-3 > > > In our system, we're building every five minutes or so, and we can't see the > last good build version number when things are queued or building. It would > be very helpful if the last good build could be completely independent of the > build status. -- 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-3038) Transitive DepMan not working (per MNG-1577) [use case attached]
[
http://jira.codehaus.org/browse/MNG-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98777
]
Joakim Erdfelt commented on MNG-3038:
-
This will likely *not* be fixed for maven 2.0.x
Instead it will be taken as an example use case for the 2.1 artifact resolution
specification.
http://docs.codehaus.org/display/MAVEN/Maven+2.1+Artifact+Resolution+Specification
> Transitive DepMan not working (per MNG-1577) [use case attached]
>
>
> Key: MNG-3038
> URL: http://jira.codehaus.org/browse/MNG-3038
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.5, 2.0.6
>Reporter: Joakim Erdfelt
> Attachments: carlos_transitive_version.tar.gz
>
>
> When working with the example use case described by Carlos on the MNG-1577
> thread.
> http://www.nabble.com/Re%3A--vote--MNG-1577-as-the-default-behavior-p9506667s177.html
> {noformat}
> What about this use case for transitive dependencyManagement? has been tested?
> A -> B -> C -> D
> C depends on D 1.0
> B has D 2.0 in dependencyManagement, no D in dependencies
> A should get D 2.0
> {noformat}
> It was discovered that this does not work.
> Sample Project / Use Case is attached. (655 bytes)
--
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-2521) Using JDK 1.5+ annotations for mojos metadata
[ http://jira.codehaus.org/browse/MNG-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Redmond updated MNG-2521: -- Attachment: format-maven-plugin-tools-java5.diff format-maven-plugin-plugin.diff Same patches with correct code formatting > Using JDK 1.5+ annotations for mojos metadata > - > > Key: MNG-2521 > URL: http://jira.codehaus.org/browse/MNG-2521 > Project: Maven 2 > Issue Type: New Feature > Components: Multiple Language Support >Affects Versions: 2.0-alpha-1, 2.0.4, 2.0.5 >Reporter: Yoav Landman >Assignee: Jason van Zyl > Attachments: format-maven-plugin-plugin.diff, > format-maven-plugin-tools-java5.diff, maven-plugin-plugin-postcompile.diff, > maven-plugin-tools-anno.patch, maven-plugin-tools-java5.diff > > > The attached patch contains a plugin-tool that allows writing annotatd mojos > using JDK 1.5 annotations instead of doclet comments. > It is was created from (my) sf.net project > https://sourceforge.net/projects/mvn-anno-mojo/. -- 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-942) Ability to source system properties in settings.xml
[ http://jira.codehaus.org/browse/MNG-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-942. -- Resolution: Duplicate See MNG-2577 > Ability to source system properties in settings.xml > --- > > Key: MNG-942 > URL: http://jira.codehaus.org/browse/MNG-942 > Project: Maven 2 > Issue Type: New Feature > Components: Plugins and Lifecycle >Affects Versions: 2.0-beta-1 > Environment: Maven 2.0-beta-1 > WIN XP PRO SP2 > java version "1.5.0_04" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05) > Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode) >Reporter: John Allen >Assignee: John Casey >Priority: Trivial > Fix For: 2.1.x > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > Would be nice to be able to source Java System properties in the global and > user settings.xml file. This is intended to allow custom build systems to set > arbitrary m2 settings.xml properties programmatically by wrapping m2 > executable in their own wrapper exe and then passing these settings to M2 via > the JVM options ($MAVEN_OPTS). Currently only explicitly supported settings > can be overrided/defined by system properties (such as maven.repo.local). > An example might be the proxy being employed, depending on where the build is > being run from the proxy might be set differently. Note the same machine is > being used (a laptop in this case) but operates in multiple locations and > therefore network configurations (work/home). The M2 wrapping script can > detect this difference from network info (ipconfig or IE connection details) > and set the proxy details appropriately. I guess in this example it would be > even better if it was just able to set a System property that acted as a > switch which then activated the correct proxy configuration defined in > settings.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2577) Allow interpolation of Properties in settings.xml
[ http://jira.codehaus.org/browse/MNG-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-2577. --- Resolution: Fixed Modifying to use request properties (embeddable system properties), and organizing this with the existing use of envars. NOT allowing profile-property interpolation, as these could influence profiles in a recursive manner and make their values hard to determine...besides, model-interpolation will pickup profile properties before POMs are interpolated, so the only thing this will miss is profile/properties -> servers, etc. inside the settings itself. > Allow interpolation of Properties in settings.xml > - > > Key: MNG-2577 > URL: http://jira.codehaus.org/browse/MNG-2577 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0.4, 2.0.5 >Reporter: Michael Locher >Assignee: John Casey >Priority: Critical > Attachments: DefaultMavenSettingsBuilder.java.diff > > > the attached patch (against 2.0.4) allows interpolation of system properties > into the .m2/settings.xml > and interpolation of system properties and the properties of profiles found > in .m2/settings.xml (if they are activeByDefault) into conf/settings.xml > these features are necessary in order to propagate user account settings > defined in user-specific .m2/settings.xml into server sections of the > institution-wide conf/settings.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2289) Newer SNAPSHOT parents in the remote repository are ignored
[ http://jira.codehaus.org/browse/MNG-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2289. -- > Newer SNAPSHOT parents in the remote repository are ignored > --- > > Key: MNG-2289 > URL: http://jira.codehaus.org/browse/MNG-2289 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.5 >Reporter: Joerg Schaible >Assignee: Jason van Zyl >Priority: Critical > Fix For: 2.0.7 > > Attachments: example.zip, mng2289.zip > > > If a POM inherits from another one in the repository with a SNAPSHOT version, > it will only look into the local repository for it, but not in the remote > repositories. > E.g. if a POM has following parent:... > > pom.maven > super > SNAPSHOT > > ... > it will not find a newer version of "pom.maven:super:SNAPSHOT" in a remote > repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPA-97) Make an archetype for integration tests
[ http://jira.codehaus.org/browse/MPA-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MPA-97: -- Assignee: John Casey > Make an archetype for integration tests > --- > > Key: MPA-97 > URL: http://jira.codehaus.org/browse/MPA-97 > Project: Maven Project Administration > Issue Type: Sub-task >Reporter: Brett Porter >Assignee: John Casey > Fix For: Maven 2.1 Prep > > -- 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: (MPA-98) Document running the integration tests
[ http://jira.codehaus.org/browse/MPA-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MPA-98: -- Assignee: John Casey > Document running the integration tests > -- > > Key: MPA-98 > URL: http://jira.codehaus.org/browse/MPA-98 > Project: Maven Project Administration > Issue Type: Sub-task >Reporter: Brett Porter >Assignee: John Casey > Fix For: Maven 2.1 Prep > > -- 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: (MPA-96) Make an archetype for test cases
[ http://jira.codehaus.org/browse/MPA-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MPA-96: -- Assignee: John Casey > Make an archetype for test cases > > > Key: MPA-96 > URL: http://jira.codehaus.org/browse/MPA-96 > Project: Maven Project Administration > Issue Type: Sub-task >Reporter: Brett Porter >Assignee: John Casey > Fix For: Maven 2.1 Prep > > -- 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: (MPA-100) resolve integration test problems
[ http://jira.codehaus.org/browse/MPA-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MPA-100: --- Assignee: John Casey > resolve integration test problems > - > > Key: MPA-100 > URL: http://jira.codehaus.org/browse/MPA-100 > Project: Maven Project Administration > Issue Type: Task >Reporter: Brett Porter >Assignee: John Casey > Fix For: Maven 2.1 Prep > > > http://docs.codehaus.org/display/MAVEN/IT+Problems > Inidividual tasks for this should be created in the MNG JIRA itself. Issues > should be linked here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (NMAVEN-77) Maven Visual Studio 2005 Installer Plugin Should Generate Sample Project on Install
Maven Visual Studio 2005 Installer Plugin Should Generate Sample Project on Install --- Key: NMAVEN-77 URL: http://jira.codehaus.org/browse/NMAVEN-77 Project: NMaven Issue Type: Improvement Reporter: Shane Isbell Priority: Minor Maven Visual Studio 2005 installer plugin should generate sample project and solution on install. This will make it easier for first-time users. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1532) Upload org.hibernate:hibernate-annotations:jar:3.3.0.ga to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98754 ] Craig Condit commented on MAVENUPLOAD-1532: --- This has already been uploaded. I think that will have to wait for 3.3.1, as I believe the ibiblio policy is not to modify existing poms. > Upload org.hibernate:hibernate-annotations:jar:3.3.0.ga to ibiblio > -- > > Key: MAVENUPLOAD-1532 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1532 > Project: maven-upload-requests > Issue Type: Task >Reporter: Craig Condit >Assignee: Carlos Sanchez > > http://randomcoder.com/projects/maven-uploads/hibernate-annotations-3.3.0.ga-bundle.jar > http://www.hibernate.org/ > Relational Persistence for Java - Annotations support -- 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-195) PDE feature in Multiproject
[ http://jira.codehaus.org/browse/MECLIPSE-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98750 ] Graham Leggett commented on MECLIPSE-195: - The workaround to this issue is to explicitly set the plugin dependencies library: maven-eclipse-plugin org.eclipse.jdt.launching.JRE_CONTAINER org.eclipse.pde.core.requiredPlugins true > PDE feature in Multiproject > --- > > Key: MECLIPSE-195 > URL: http://jira.codehaus.org/browse/MECLIPSE-195 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: PDE support >Affects Versions: 2.3 > Environment: Maven 2 & Eclipse 3.2 >Reporter: Markus Wolf > > When using pde=true in multiproject setup the > org.eclipse.pde.core.requiredPlugins is not set in .classpath -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1532) Upload org.hibernate:hibernate-annotations:jar:3.3.0.ga to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98749 ] Matt Read commented on MAVENUPLOAD-1532: The hibernate-annotations pom.xml doesn't include hibernate-commons-annotations as a dependency, shouldn't that be done as part of this fix? > Upload org.hibernate:hibernate-annotations:jar:3.3.0.ga to ibiblio > -- > > Key: MAVENUPLOAD-1532 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1532 > Project: maven-upload-requests > Issue Type: Task >Reporter: Craig Condit >Assignee: Carlos Sanchez > > http://randomcoder.com/projects/maven-uploads/hibernate-annotations-3.3.0.ga-bundle.jar > http://www.hibernate.org/ > Relational Persistence for Java - Annotations support -- 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-2577) Allow interpolation of Properties in settings.xml
[ http://jira.codehaus.org/browse/MNG-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-2577: Assignee: John Casey Patch Submitted: (was: [Yes]) > Allow interpolation of Properties in settings.xml > - > > Key: MNG-2577 > URL: http://jira.codehaus.org/browse/MNG-2577 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0.4, 2.0.5 >Reporter: Michael Locher >Assignee: John Casey >Priority: Critical > Attachments: DefaultMavenSettingsBuilder.java.diff > > > the attached patch (against 2.0.4) allows interpolation of system properties > into the .m2/settings.xml > and interpolation of system properties and the properties of profiles found > in .m2/settings.xml (if they are activeByDefault) into conf/settings.xml > these features are necessary in order to propagate user account settings > defined in user-specific .m2/settings.xml into server sections of the > institution-wide conf/settings.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-279) PDE projects should be considered java projects in all cases
PDE projects should be considered java projects in all cases Key: MECLIPSE-279 URL: http://jira.codehaus.org/browse/MECLIPSE-279 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: PDE support Affects Versions: 2.4 Environment: java version "1.5.0_10" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03) Java HotSpot(TM) Client VM (build 1.5.0_10-b03, mixed mode, sharing) Reporter: Graham Leggett Fix For: 2.4 Attachments: pde-fix.diff When an attempt is made to use the pde-maven-plugin to build plugin code, this attempt fails. It turns out that when the PDE artifact is set to zip as required by the pde-maven-plugin, it in effect tells the maven-eclipse-plugin that this artifact is no longer a java artifact. The effect is that the .classpath file is not written, and this breaks the eclipse build. The fix is to modify the isJavaProject test to treat all PDE projects as java projects, regardless of the packaging type. The attached patch allows the pde-maven-plugin and maven-eclipse-plugin to work together again. -- 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-2258) Wrong execution order of plugins in same phase
[ http://jira.codehaus.org/browse/MNG-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-2258. --- Resolution: Duplicate See MNG-2784 > Wrong execution order of plugins in same phase > -- > > Key: MNG-2258 > URL: http://jira.codehaus.org/browse/MNG-2258 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.4 > Environment: N/A >Reporter: David J. M. Karlsen >Assignee: John Casey > Fix For: 2.1.x > > > AFAIK plugins should be execute in the same order as they are listed in the > POM, when bound to the same phase. This does not happen, the execution order > is arbitrary. -- 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-227) mvn eclipse:eclipse for pom should create a .project file
[ http://jira.codehaus.org/browse/MECLIPSE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98748 ] Vincent Massol commented on MECLIPSE-227: - I agree this feature is needed but the eclipse plugin should always generate Eclipse project files when the maven projects doesn't have children. This will avoid issues with Eclipse not supporting project hiearchies. > mvn eclipse:eclipse for pom should create a .project > file > > > Key: MECLIPSE-227 > URL: http://jira.codehaus.org/browse/MECLIPSE-227 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Environment: all >Reporter: THURNER rupert > > mvn eclipse:eclipse for pom should create a .project > file. > currently it does nothing. this is especially annoying if using parent poms > with other poms in subdirectories, see also description on > http://maven.apache.org/guides/mini/guide-ide-eclipse.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-2258) Wrong execution order of plugins in same phase
[ http://jira.codehaus.org/browse/MNG-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-2258: Priority: (was: Major) Assignee: John Casey Patch Submitted: (was: [Yes]) > Wrong execution order of plugins in same phase > -- > > Key: MNG-2258 > URL: http://jira.codehaus.org/browse/MNG-2258 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.4 > Environment: N/A >Reporter: David J. M. Karlsen >Assignee: John Casey > Fix For: 2.1.x > > > AFAIK plugins should be execute in the same order as they are listed in the > POM, when bound to the same phase. This does not happen, the execution order > is arbitrary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-94) Add dependency:tree goal
[ http://jira.codehaus.org/browse/MDEP-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98746 ] Brian Fox commented on MDEP-94: --- Yes, I need to update the unarchiver version, which brings in a new container that needs a new harness, so it's on my roadmap to some how deal with the unit tests in a more common way. > Add dependency:tree goal > > > Key: MDEP-94 > URL: http://jira.codehaus.org/browse/MDEP-94 > Project: Maven 2.x Dependency Plugin > Issue Type: New Feature >Affects Versions: 2.0-alpha-5 >Reporter: Mark Hobson >Assignee: Brian Fox > Attachments: MDEP-94-test.patch, patch.txt > > > The attached patch adds the help:dependencies goal from the maven-help-plugin > to the maven-dependency-plugin as dependency:tree, as discussed on the dev > mailing list. -- 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: (MDEP-94) Add dependency:tree goal
[ http://jira.codehaus.org/browse/MDEP-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hobson updated MDEP-94: Attachment: MDEP-94-test.patch Attached patch for simple test in the same vein as the others. Needed to up maven-plugin-testing-harness to 1.1-SNAPSHOT for a more complete MavenProject stub. May be worth centralising all stubs in maven-plugin-testing-harness? > Add dependency:tree goal > > > Key: MDEP-94 > URL: http://jira.codehaus.org/browse/MDEP-94 > Project: Maven 2.x Dependency Plugin > Issue Type: New Feature >Affects Versions: 2.0-alpha-5 >Reporter: Mark Hobson >Assignee: Brian Fox > Attachments: MDEP-94-test.patch, patch.txt > > > The attached patch adds the help:dependencies goal from the maven-help-plugin > to the maven-dependency-plugin as dependency:tree, as discussed on the dev > mailing list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-245) CheckDependencySnapshotsPhase ignores ranges
CheckDependencySnapshotsPhase ignores ranges Key: MRELEASE-245 URL: http://jira.codehaus.org/browse/MRELEASE-245 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-6 Reporter: Mark Hobson Attachments: MRELEASE.patch Ranges are not resolved when checking for snapshots. The attached patch checks the resolved versions and requires @rDR on release:prepare. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-244) Correct licences in mojo test cases
Correct licences in mojo test cases --- Key: MRELEASE-244 URL: http://jira.codehaus.org/browse/MRELEASE-244 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-6 Reporter: Mark Hobson Priority: Minor Attachments: MRELEASE.patch Duplicate licences in mojo test cases. -- 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-3036) NullPointerException when eclipse jars are marked as "provided"
[ http://jira.codehaus.org/browse/MNG-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98742 ] Graham Leggett commented on MNG-3036: - Sorry, I'm being a moron - the debugger was pointing at the wrong code. The line that is NPEing is this one: 164: resetArtifact.selectVersion( resetArtifact.getVersionRange().matchVersion( resetArtifact.getAvailableVersions() ).toString() ); Or, to be more specific, the following statement returns null: resetArtifact.getVersionRange().matchVersion( resetArtifact.getAvailableVersions() ) which is in turn not handled. Digging deeper, if I evaluate the expression resetArtifact.getAvailableVersions() it evaluates to the single entry [3.2.0]. If I evaluate resetArtifact.getVersionRange().toString() it evaluates to "". Based on this it seems the case of where the list of available versions is not inside the version range, this case in currently unhandled. I don't know what the correct way would be to handle this, does anyone know what this code is trying to do? > NullPointerException when eclipse jars are marked as "provided" > --- > > Key: MNG-3036 > URL: http://jira.codehaus.org/browse/MNG-3036 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 >Reporter: Graham Leggett > Attachments: pom.xml > > > When a pde artifact is built that transitively depends on some eclipse jars, > and an attempt is made to filter out those eclipse jars by marking the scope > as provided, maven NPEs during eclipse:eclipse as follows: > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:164) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:75) > at > org.apache.maven.plugin.ide.AbstractIdeSupportMojo.doDependencyResolution(AbstractIdeSupportMojo.java:447) > at > org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:398) > 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.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java: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) > [INFO] > > [INFO] Total t
[jira] Updated: (MECLIPSE-261) IdeUtils.toRelativeAndFixSeparator returns incomplete path
[ http://jira.codehaus.org/browse/MECLIPSE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Burton updated MECLIPSE-261: Attachment: EclipsePlugin-2.4.zip After the correction in the patch I submitted, I noticed the test cases ran successfully, but the results are very misleading. I haven't located why, but the test case doesn't match up to the real world execution of the plug-in. The patch I submitted was: path = M2_REPO + IdeUtils.toRelativeAndFixSeparatorVar( localRepositoryFile, new File( fullPath ), false); kind = ATTR_VAR; //$NON-NLS-1$ and this lead to a broken path that would look like M2_REPOcom/path/to/file/1.0.1/file-1.0.1.jar When using: path = M2_REPO + "/" + IdeUtils.toRelativeAndFixSeparatorVar( localRepositoryFile, new File( fullPath ), false); kind = ATTR_VAR; //$NON-NLS-1$ The path was valid, but the test cases some how have an output of: (Note: The double slash after M2_REPO) M2_REPO//com/path/to/file/1.0.1/file-1.0.1.jar I attached a zip which contains the JAR that I'm using and the code changes embedded in the zip. I'm not 100% certain that I didn't break existing code since the TestCase themselves seem broken. Best Regards, Richard L. Burton III > IdeUtils.toRelativeAndFixSeparator returns incomplete path > -- > > Key: MECLIPSE-261 > URL: http://jira.codehaus.org/browse/MECLIPSE-261 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Windows XP, jdk 1.5.0_11-b03, maven 2.0.5 >Reporter: Marcio Paulo Guedes > Attachments: .classpath, baseDirIsRoot.patch, > EclipseClasspathWriter.java, EclipsePlugin-2.4.zip, IdeUtils.java, patch.txt, > pom.xml > > > .classpath file is generated with incomplete path for classpathentry when > kind is "var". > Example: > > when path="M2_REPO/ognl/ognl/2.6.9/ognl-2.6.9.jar"/> is expected. > It's caused by IdeUtils.toRelativeAndFixSeparator when basepath is not equal > absolutepath. Code on line 99 shifts the string 1 character to the right, > corrupting the result path. -- 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-2289) Newer SNAPSHOT parents in the remote repository are ignored
[ http://jira.codehaus.org/browse/MNG-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2289: --- Patrick and I cannot not reproduce this Jorg, so we're going to mark can't reproduce. Unless you want to take a look at the IT we whipped up and see if you can. > Newer SNAPSHOT parents in the remote repository are ignored > --- > > Key: MNG-2289 > URL: http://jira.codehaus.org/browse/MNG-2289 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.5 >Reporter: Joerg Schaible >Assignee: Jason van Zyl >Priority: Critical > Fix For: 2.0.7 > > Attachments: example.zip, mng2289.zip > > > If a POM inherits from another one in the repository with a SNAPSHOT version, > it will only look into the local repository for it, but not in the remote > repositories. > E.g. if a POM has following parent:... > > pom.maven > super > SNAPSHOT > > ... > it will not find a newer version of "pom.maven:super:SNAPSHOT" in a remote > repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-243) Release pom is deployed and embedded in artifacts
Release pom is deployed and embedded in artifacts - Key: MRELEASE-243 URL: http://jira.codehaus.org/browse/MRELEASE-243 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-6 Reporter: Mark Hobson Attachments: MRELEASE.patch When generating release poms, the release pom is added to the tag and is thus used in preference to the standard pom when running release:perform goals. This means the release pom is deployed and placed in artifacts such as jars. The attached patch forces release:perform to use pom.xml over the release pom. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-240) release-pom.xml does not contain and
[ http://jira.codehaus.org/browse/MRELEASE-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hobson updated MRELEASE-240: - Attachment: MRELEASE-240.patch Attached patch adds @rDR back into release:prepare to fix the missing dependencies problem, as agreed over IRC with Brett and summarised in the above thread. The dependencyManagement block is never present in a release pom since dependencies are fully resolved. > release-pom.xml does not contain and > -- > > Key: MRELEASE-240 > URL: http://jira.codehaus.org/browse/MRELEASE-240 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Yann Le Du > Attachments: MRELEASE-240.patch > > > Since version 2.0-beta-6, mvn release:prepare -DgenerateReleasePoms=true > creates release-pom.xml, which is good. > Though, this release-pom.xml does not contain the and > sections of the original POM. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3039) mvn.bat fails
[ http://jira.codehaus.org/browse/MNG-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-3039. -- Patch applied. > mvn.bat fails > - > > Key: MNG-3039 > URL: http://jira.codehaus.org/browse/MNG-3039 > Project: Maven 2 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.6 >Reporter: Mark Hobson >Assignee: Jason van Zyl >Priority: Blocker > Fix For: 2.0.7 > > Attachments: patch.txt > > > 2.0.7-SNAPSHOT fails to launch under Windows: > [EMAIL PROTECTED] My Documents]$ mvn.bat --version > Exception in thread "main" java.lang.NoClassDefFoundError: > org/codehaus/classworlds/Launcher > Caused by MNG-2503 being merged from trunk into 2.0.x. Attached patch fixes > this. -- 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-3039) mvn.bat fails
[ http://jira.codehaus.org/browse/MNG-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-3039: --- Affects Version/s: (was: 2.0.7) 2.0.6 Fix Version/s: 2.0.7 > mvn.bat fails > - > > Key: MNG-3039 > URL: http://jira.codehaus.org/browse/MNG-3039 > Project: Maven 2 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.6 >Reporter: Mark Hobson >Assignee: Jason van Zyl >Priority: Blocker > Fix For: 2.0.7 > > Attachments: patch.txt > > > 2.0.7-SNAPSHOT fails to launch under Windows: > [EMAIL PROTECTED] My Documents]$ mvn.bat --version > Exception in thread "main" java.lang.NoClassDefFoundError: > org/codehaus/classworlds/Launcher > Caused by MNG-2503 being merged from trunk into 2.0.x. Attached patch fixes > this. -- 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-3040) Failure to construct build plan fatal error on trunk r545155
Failure to construct build plan fatal error on trunk r545155 Key: MNG-3040 URL: http://jira.codehaus.org/browse/MNG-3040 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.1-alpha-1 Reporter: Brett Porter Attachments: pom.xml see attached pom which causes this: mcbrett:~/scm/maven/sandbox/continuum/continuum-data-upgrade brett$ mvn clean install -e + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] [INFO] Building Unnamed - org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT [INFO]task-segment: [clean, install] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to construct build plan for: org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT ( task-segment: [clean, install] ). Reason: No phase specified for goal: exec in plugin: org.codehaus.mojo:exec-maven-plugin from POM: org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT [INFO] [INFO] Trace org.apache.maven.BuildFailureException: Failed to construct build plan for: org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT ( task-segment: [clean, install] ). Reason: No phase specified for goal: exec in plugin: org.codehaus.mojo:exec-maven-plugin from POM: org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:296) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:112) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:906) at org.apache.maven.cli.MavenCli.main(MavenCli.java:367) 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.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) Caused by: org.apache.maven.lifecycle.LifecycleExecutionException: Failed to construct build plan for: org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT ( task-segment: [clean, install] ). Reason: No phase specified for goal: exec in plugin: org.codehaus.mojo:exec-maven-plugin from POM: org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getLifecycleBindings(DefaultLifecycleExecutor.java:305) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:246) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:141) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292) ... 11 more Caused by: org.apache.maven.lifecycle.LifecycleSpecificationException: No phase specified for goal: exec in plugin: org.codehaus.mojo:exec-maven-plugin from POM: org.apache.maven.continuum:continuum-data-upgrade:jar:1.1-SNAPSHOT at org.apache.maven.lifecycle.binding.DefaultLifecycleBindingManager.getProjectCustomBindings(DefaultLifecycleBindingManager.java:295) at org.apache.maven.lifecycle.plan.DefaultBuildPlanner.constructBuildPlan(DefaultBuildPlanner.java:54) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getLifecycleBindings(DefaultLifecycleExecutor.java:294) ... 14 more [INFO] [INFO] Total time: < 1 second [INFO] Finished at: Thu Jun 07 22:40:57 EST 2007 [INFO] Final Memory: 2M/5M [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: < 1 second [INFO] Finished at: Thu Jun 07 22:40:57 EST 2007 [INFO] Final Memory: 2M/5M [INFO] -- This message is automatically generated by JIRA. - If you think it was sen
[jira] Closed: (MNG-2988) Ranges with inclusive upper bounds are not validated against metadata
[ http://jira.codehaus.org/browse/MNG-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2988. - Resolution: Fixed applied to trunk and branch > Ranges with inclusive upper bounds are not validated against metadata > - > > Key: MNG-2988 > URL: http://jira.codehaus.org/browse/MNG-2988 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.6 >Reporter: Mark Hobson >Assignee: Brett Porter > Fix For: 2.0.7 > > Attachments: patch.txt > > > See http://www.mail-archive.com/[EMAIL PROTECTED]/msg67131.html > Patch attached. -- 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-242) Unable to find the mojo maven-release-plugin:perform
[ http://jira.codehaus.org/browse/MRELEASE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98726 ] Stephane Nicoll commented on MRELEASE-242: -- Probably corrupted metadata. Remove ~/.m2/repository/org/apache/maven/plugins/maven-release-plugin and try again. > Unable to find the mojo maven-release-plugin:perform > > > Key: MRELEASE-242 > URL: http://jira.codehaus.org/browse/MRELEASE-242 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 > Environment: C:\java\development\mx\trunk>java -version > java version "1.5.0_10" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03) > Java HotSpot(TM) Client VM (build 1.5.0_10-b03, mixed mode, sharing) >Reporter: Graham Leggett > > When an attempt is made to run the release:perform goal on the release plugin > on Windows, the following exception is thrown: > [INFO] > - > --- > [INFO] Building Alchemy II MX > [INFO]task-segment: [release:perform] (aggregator-style) > [INFO] > - > --- > - > this realm = > app0.child-container[org.apache.maven.plugins:maven-release-plugin] > urls[0] = > file:/C:/WINNT/profiles/leggettg/.m2/repository/org/apache/maven/plugi > ns/maven-release-plugin/2.0-beta-6/maven-release-plugin-2.0-beta-6.jar > urls[1] = > file:/C:/WINNT/profiles/leggettg/.m2/repository/org/apache/maven/scm/m > aven-scm-api/1.0/maven-scm-api-1.0.jar > urls[2] = > file:/C:/WINNT/profiles/leggettg/.m2/repository/org/apache/maven/scm/m > aven-scm-provider-cvsexe/1.0/maven-scm-provider-cvsexe-1.0.jar > urls[3] = > file:/C:/WINNT/profiles/leggettg/.m2/repository/org/netbeans/lib/cvscl > ient/20060125/cvsclient-20060125.jar > urls[4] = > file:/C:/WINNT/profiles/leggettg/.m2/repository/org/codehaus/plexus/pl > exus-utils/1.1/plexus-utils-1.1.jar > urls[5] = > file:/C:/WINNT/profiles/leggettg/.m2/repository/org/apache/maven/scm/m > aven-scm-manager-plexus/1.0/maven-scm-manager-plexus-1.0.jar > urls[6] = > file:/C:/WINNT/profiles/leggettg/.m2/repository/org/apache/maven/scm/m > aven-scm-provider-hg/1.0/maven-scm-provider-hg-1.0.jar > urls[7] = > file:/C:/WINNT/profiles/leggettg/.m2/repository/org/apache/maven/scm/m > aven-scm-provider-bazaar/1.0/maven-scm-provider-bazaar-1.0.jar > urls[8] = > file:/C:/WINNT/profiles/leggettg/.m2/repository/org/apache/maven/scm/m > aven-scm-provider-starteam/1.0/maven-scm-provider-starteam-1.0.jar > urls[9] = > file:/C:/WINNT/profiles/leggettg/.m2/repository/org/apache/maven/scm/m > aven-scm-provider-cvsjava/1.0/maven-scm-provider-cvsjava-1.0.jar > urls[10] = > file:/C:/WINNT/profiles/leggettg/.m2/repository/org/apache/maven/scm/ > maven-scm-provider-svnexe/1.0/maven-scm-provider-svnexe-1.0.jar > urls[11] = > file:/C:/WINNT/profiles/leggettg/.m2/repository/org/apache/maven/scm/ > maven-scm-provider-synergy/1.0/maven-scm-provider-synergy-1.0.jar > urls[12] = > file:/C:/WINNT/profiles/leggettg/.m2/repository/jaxen/jaxen/1.1-beta- > 8/jaxen-1.1-beta-8.jar > urls[13] = > file:/C:/WINNT/profiles/leggettg/.m2/repository/org/apache/maven/scm/ > maven-scm-provider-svn-commons/1.0/maven-scm-provider-svn-commons-1.0.jar > urls[14] = > file:/C:/WINNT/profiles/leggettg/.m2/repository/org/apache/maven/scm/ > maven-scm-provider-clearcase/1.0/maven-scm-provider-clearcase-1.0.jar > urls[15] = > file:/C:/WINNT/profiles/leggettg/.m2/repository/ch/ethz/ganymed/ganym > ed-ssh2/build210/ganymed-ssh2-build210.jar > urls[16] = > file:/C:/WINNT/profiles/leggettg/.m2/repository/jdom/jdom/1.0/jdom-1. > 0.jar > urls[17] = > file:/C:/WINNT/profiles/leggettg/.m2/repository/org/apache/maven/scm/ > maven-scm-provider-perforce/1.0/maven-scm-provider-perforce-1.0.jar > urls[18] = > file:/C:/WINNT/profiles/leggettg/.m2/repository/org/apache/maven/scm/ > maven-scm-provider-cvs-commons/1.0/maven-scm-provider-cvs-commons-1.0.jar > urls[19] = > file:/C:/WINNT/profiles/leggettg/.m2/repository/regexp/regexp/1.3/reg > exp-1.3.jar > urls[20] = > file:/C:/WINNT/profiles/leggettg/.m2/repository/org/apache/maven/rele > ase/maven-release-manager/1.0-alpha-3/maven-release-manager-1.0-alpha-3.jar > Number of imports: 4 > import: [EMAIL PROTECTED] > import: [EMAIL PROTECTED] > import: [EMAIL PROTECTED] > import: [EMAIL PROTECTED] > this realm = plexus.core > urls[0] = file:/C:/java/maven-2.0.6/lib/maven-core-2.0.6-uber.jar > Number of imports: 4 > import: [EMAIL PROTECTED] > import: [EMAIL PROTECTED] > import: [EMAIL PROTECTED] > import: [EMAIL PROTECTED] > - > [INFO] > > [ERROR] BUILD E
[jira] Updated: (MNG-2994) Snapshot repositories are not checked when using ranges
[ http://jira.codehaus.org/browse/MNG-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hobson updated MNG-2994: - Attachment: MNG-2994-2.patch Updated IT patch to sync with current trunk by renaming it0121 to it0123 - please apply before someone adds another it0123! > Snapshot repositories are not checked when using ranges > --- > > Key: MNG-2994 > URL: http://jira.codehaus.org/browse/MNG-2994 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.6 > Environment: Windows XP, Cygwin >Reporter: Mark Hobson >Assignee: Jason van Zyl > Attachments: MNG-2994-2.patch, patch.txt > > > The attached patch demonstrates the problem by adding it0121. If the test > repository has releases enabled, the test passes, when they are disabled, the > test fails. This appears to be due to DefaultArtifact.isSnapshot returning > false for unresolved ranges, thus causing snapshot repositories to be > disabled when resolving artifacts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3039) mvn.bat fails
mvn.bat fails - Key: MNG-3039 URL: http://jira.codehaus.org/browse/MNG-3039 Project: Maven 2 Issue Type: Bug Components: Command Line Affects Versions: 2.0.7 Reporter: Mark Hobson Priority: Blocker Attachments: patch.txt 2.0.7-SNAPSHOT fails to launch under Windows: [EMAIL PROTECTED] My Documents]$ mvn.bat --version Exception in thread "main" java.lang.NoClassDefFoundError: org/codehaus/classworlds/Launcher Caused by MNG-2503 being merged from trunk into 2.0.x. Attached patch fixes this. -- 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: (MPA-94) Clean up patch submission
[ http://jira.codehaus.org/browse/MPA-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MPA-94: - Just a collection of criteria: - patches must be accompanies by sample/test projects that demonstrate the problem - new features that require new configurations must have sample projects with sample configurations - the complete description of the problem must be included, not references to nabble or any other external source of information. someone processing patches should be able to work offline processing patches > Clean up patch submission > - > > Key: MPA-94 > URL: http://jira.codehaus.org/browse/MPA-94 > Project: Maven Project Administration > Issue Type: Task > Components: Issue Management >Reporter: Brett Porter > Fix For: Maven 2.1 Prep > > -- 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-2988) Ranges with inclusive upper bounds are not validated against metadata
[ http://jira.codehaus.org/browse/MNG-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2988: --- >From Mark's email: I'm working on tests for MRELEASE-177 which has led me to investigate how ranges are resolved. An example problem was [1.0,2.0] resolving to 2.0 irrespective of the repository metadata. This appears to be due to VersionRange.getSelectedVersion and isSelectedVersionKnown which selects the upper bound if present and inclusive. DefaultArtifactCollector then blindly uses this without consulting the artifact metadata. Any idea why VersionRange special cases this situation? All the integration tests pass without it. > Ranges with inclusive upper bounds are not validated against metadata > - > > Key: MNG-2988 > URL: http://jira.codehaus.org/browse/MNG-2988 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.6 >Reporter: Mark Hobson >Assignee: Brett Porter > Fix For: 2.0.7 > > Attachments: patch.txt > > > See http://www.mail-archive.com/[EMAIL PROTECTED]/msg67131.html > Patch attached. -- 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-2988) Ranges with inclusive upper bounds are not validated against metadata
[ http://jira.codehaus.org/browse/MNG-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2988: --- Please put the description in the issue. One the beauties of Mylar is working completely offline which is not possible with external reference to the actual issues. It's bad practice not to have the intact set of information associated with the issue itself. > Ranges with inclusive upper bounds are not validated against metadata > - > > Key: MNG-2988 > URL: http://jira.codehaus.org/browse/MNG-2988 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.6 >Reporter: Mark Hobson >Assignee: Brett Porter > Fix For: 2.0.7 > > Attachments: patch.txt > > > See http://www.mail-archive.com/[EMAIL PROTECTED]/msg67131.html > Patch attached. -- 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: (MPA-51) Create a New JIRA Project for Maven Site
[ http://jira.codehaus.org/browse/MPA-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MPA-51: - Description: The Maven site itself needs a new JIRA project to capture problems, needs, and tasks related to Maven site improvment. Hmmm, group_id, artifact_id and version. Left 'em blank. was: The Maven site itself needs a new JIRA project to capture problems, needs, and tasks related to Maven site improvment. Hmmm, group_id, artifact_id and version. Left 'em blank. Something called Maven Project Website might be less confusing to users. I think we need a place to capture usability issues with the site. > Create a New JIRA Project for Maven Site > > > Key: MPA-51 > URL: http://jira.codehaus.org/browse/MPA-51 > Project: Maven Project Administration > Issue Type: Task >Reporter: Carlos Sanchez > > The Maven site itself needs a new JIRA project to capture problems, needs, > and tasks related to Maven site improvment. > Hmmm, group_id, artifact_id and version. Left 'em blank. -- 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: (MPA-90) Clean up JIRA
[ http://jira.codehaus.org/browse/MPA-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98717 ] Jason van Zyl commented on MPA-90: -- Of primarily importance is getting some meaning back. There are close to 800 open issues which is totally out of control. Some things that can be done are: - looking for duplicates within components (not to say there are duplicates in other components) - close as incomplete any bug report that doesn't have a sample project (we just can't reproduce the problem without it and people can reopen them) - An incoming bucket that we know has not been looked at (is there a way to do this easily? Or should we do what JetBrains does and create a separate project from which to select?) - look for issues that have been assigned to the wrong project I think we need to take a heavy hand to push the open issue count down. And provide a better means for processing them. Even if we close many and ask people to make working projects for testing. > Clean up JIRA > - > > Key: MPA-90 > URL: http://jira.codehaus.org/browse/MPA-90 > Project: Maven Project Administration > Issue Type: Task > Components: Issue Management >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: Maven 2.1 Prep > > > # Flush out the duplicates > # Close what issues have been dealt with > # Delete the issues with incomprehensible explanations > # Set appropriate components > # Set appropriate versions > Currently need a way to attack this, unless it's just one person going > through them all. -- 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-3023) Reactor projects should be included in dependency resolution
[ http://jira.codehaus.org/browse/MNG-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98707 ] Brett Porter commented on MNG-3023: --- patch applied for test > Reactor projects should be included in dependency resolution > > > Key: MNG-3023 > URL: http://jira.codehaus.org/browse/MNG-3023 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.7 >Reporter: Mark Hobson > Attachments: patch.txt > > > Dependency resolution for mojos with @requiresDependencyResolution should > include the projects within the reactor. See attached it0122 for an example > (numbered as such due to MNG-2994's it0121). -- 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-2988) Ranges with inclusive upper bounds are not validated against metadata
[ http://jira.codehaus.org/browse/MNG-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2988: -- Fix Version/s: 2.0.7 Patch Submitted: [Yes] > Ranges with inclusive upper bounds are not validated against metadata > - > > Key: MNG-2988 > URL: http://jira.codehaus.org/browse/MNG-2988 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.6 >Reporter: Mark Hobson >Assignee: Brett Porter > Fix For: 2.0.7 > > Attachments: patch.txt > > > See http://www.mail-archive.com/[EMAIL PROTECTED]/msg67131.html > Patch attached. -- 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-2994) Snapshot repositories are not checked when using ranges
[ http://jira.codehaus.org/browse/MNG-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98706 ] Brett Porter commented on MNG-2994: --- I'd suggest adding a method that is an alternate to isSnapshot that is capable of expressing the difference, and use that from the metadata manager (retains backwards compat too). > Snapshot repositories are not checked when using ranges > --- > > Key: MNG-2994 > URL: http://jira.codehaus.org/browse/MNG-2994 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.6 > Environment: Windows XP, Cygwin >Reporter: Mark Hobson >Assignee: Jason van Zyl > Attachments: patch.txt > > > The attached patch demonstrates the problem by adding it0121. If the test > repository has releases enabled, the test passes, when they are disabled, the > test fails. This appears to be due to DefaultArtifact.isSnapshot returning > false for unresolved ranges, thus causing snapshot repositories to be > disabled when resolving artifacts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3023) Reactor projects should be included in dependency resolution
[ http://jira.codehaus.org/browse/MNG-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3023: -- Fix Version/s: (was: 2.0.7) Patch Submitted: (was: [Yes]) my bad, it's just the test - no fix yet. > Reactor projects should be included in dependency resolution > > > Key: MNG-3023 > URL: http://jira.codehaus.org/browse/MNG-3023 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.7 >Reporter: Mark Hobson > Attachments: patch.txt > > > Dependency resolution for mojos with @requiresDependencyResolution should > include the projects within the reactor. See attached it0122 for an example > (numbered as such due to MNG-2994's it0121). -- 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-3018) pluginManagement configurations are not honoured when plugin is silently included
[ http://jira.codehaus.org/browse/MNG-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever reopened MNG-3018: - The above snippet is enough to put into the pom.xml, along with a ... for a child project. Given that the parent project does not have java sources, and the child project does, step into the child project and build. It should builds ok, with the settings as defined under the parent's pluginManagement for maven-compiler-plugin. This is because the maven-compiler-plugin is included by default when you compile java sources, and when it is installed by default it sucks in the settings defined within the pluginManagement. Now, instead of building, run/debug the embedder to output the child's pom (or however the embedder works to extract this information) and you'll see that the maven-compiler-plugin settings are not "sucked in". Reading the original issue, http://jira.codehaus.org/browse/MEVENIDE-532 , goes through the original issue report at a more user-level, since i originally thought the problem was in the netbeans maven-project implementation, but the author there reported that it's actually the maven embedder which is not extracting the information defined it pluginManagement. If i change pluginManagement to just plugins then it works correctly, but every plugin listed within plugins is therefore loaded into each subprojects maven build process, yuk. > pluginManagement configurations are not honoured when plugin is silently > included > - > > Key: MNG-3018 > URL: http://jira.codehaus.org/browse/MNG-3018 > Project: Maven 2 > Issue Type: Bug > Components: Embedding >Reporter: Michael Semb Wever > > Read http://jira.codehaus.org/browse/MEVENIDE-532 > In my top parent pom.xml i've define the maven-compiler-plugin configuration > like: > > > > > maven-compiler-plugin > > 1.5 > 1.5 > UTF-8 > > ... > since not all my subprojects require the plugin, and when they do they > silently include the plugin, it makes more sense to define it within the > tag. > But when i use mevenide-netbeans all my projects are marked uncompilable > since the maven embedder does not report the above defined configuration for > the maven-compiler-plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3023) Reactor projects should be included in dependency resolution
[ http://jira.codehaus.org/browse/MNG-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3023: -- Fix Version/s: 2.0.7 Patch Submitted: [Yes] will review patch for 2.0.7 since it has a test and all > Reactor projects should be included in dependency resolution > > > Key: MNG-3023 > URL: http://jira.codehaus.org/browse/MNG-3023 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.7 >Reporter: Mark Hobson > Fix For: 2.0.7 > > Attachments: patch.txt > > > Dependency resolution for mojos with @requiresDependencyResolution should > include the projects within the reactor. See attached it0122 for an example > (numbered as such due to MNG-2994's it0121). -- 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: (MRM-254) connecting proxied repositories without http-proxy fails
[ http://jira.codehaus.org/browse/MRM-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98702 ] Fabrice BELLINGARD commented on MRM-254: Stefan, do you still have the bug with the current trunk? > connecting proxied repositories without http-proxy fails > > > Key: MRM-254 > URL: http://jira.codehaus.org/browse/MRM-254 > Project: Archiva > Issue Type: Improvement > Components: remote proxy > Environment: archiva-trunk on SuSE-Linux in intranet-environment > behind a firewall and with http-proxy >Reporter: Stefan Hübner > Fix For: 1.0-alpha-2 > > > If one configures Archiva to proxy another inhouse repository, Archiva > struggles to connect to the proxied repository. The log file contains 503 > HTTP Error Codes for any attempt to connect to the second repo. This is > because Archiva tries to connect to the second server via > http-proxy-connection (even though the proxied repository is configured not > to connect through http-proxy). > First thing, the "Use HTTP Proxy" option doesn't work properly since Archiva > *does* open proxy-connections even with that option inactive. > Second: I figured out, that there's a hidden option for HTTP-Proxy, only > configurable in Archiva's archiva.xml file. If the proxy-element contains a > "nonProxyHosts"-element (same as in maven settings.xml) and that element > lists the second server, all 503 return codes vanish. > Conclusion: either the "Use HTTP proxy"-option is screwed or serves a > different purpose. If first, please fix that issue. If second, please make > "nonProxyHosts" configurable via UI. > Cheers, > Stefan -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-321) bootstrap does duplicate checkout
bootstrap does duplicate checkout - Key: SCM-321 URL: http://jira.codehaus.org/browse/SCM-321 Project: Maven SCM Issue Type: Bug Components: maven-plugin Affects Versions: 1.x Environment: All Reporter: Wouter Hermeling A duplicate checkout is performed when executing scm:bootstrap. I checked the sources of the plugin. In BoostrapMojo#execute() the following causes problem: super.execute(); CheckOutScmResult result = checkout(); The super.execute() will perform a checkout since the class inherits from CheckoutMojo. And the checkout() method will of course also perform a checkout. -- 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: (CONTINUUM-1226) Second build definitions on a project is never triggered with CVS
[
http://jira.codehaus.org/browse/CONTINUUM-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98698
]
Stephane Nicoll commented on CONTINUUM-1226:
Could you please schedule this issue for 1.1?
> Second build definitions on a project is never triggered with CVS
> -
>
> Key: CONTINUUM-1226
> URL: http://jira.codehaus.org/browse/CONTINUUM-1226
> Project: Continuum
> Issue Type: Bug
> Components: Core system, SCM
>Affects Versions: 1.1-alpha-1
>Reporter: Stephane Nicoll
>
> I have two build definitions in a group:
> # run clean install every 4 hours
> # run clean site-deploy every day at 2AM
> The second build definitions is triggered properly but it's never activated
> (they are changes in CVS since the day before at 2AM since the first build
> definition is running at least twice a day)
> {noformat}
> INFO org.apache.maven.continuum.buildcontroller.BuildController:default -
> Starting build of Catalog Service
> INFO org.apache.maven.continuum.buildcontroller.BuildController:default -
> Updating working dir
> INFO org.apache.maven.continuum.buildcontroller.BuildController:default -
> Performing action check-working-directory
> INFO org.apache.maven.continuum.buildcontroller.BuildController:default -
> Performing action update-working-directory-from-scm
> INFO org.apache.maven.continuum.scm.ContinuumScm - Updating project: id:
> '40', name 'Catalog Service'.
> DEBUG org.apache.maven.scm.manager.ScmManager - cvsRoot: :pserver:[EMAIL
> PROTECTED]:2401/data/cvsroot
> DEBUG org.apache.maven.scm.manager.ScmManager - passFile:
> /var/lib/tomcat-maven/.cvspass
> DEBUG org.apache.maven.scm.manager.ScmManager - cvsroot :pserver:[EMAIL
> PROTECTED]:2401/data/cvsroot already exist in /var/lib/tomcat-maven/.cvspass.
> SKIPPED.
> INFO org.apache.maven.scm.manager.ScmManager - Executing: cvs -z3 -f -d
> :pserver:[EMAIL PROTECTED]:/data/cvsroot -q update -d
> INFO org.apache.maven.scm.manager.ScmManager - Working directory:
> /var/ionic/ci/work/40
> INFO org.apache.maven.continuum.buildcontroller.BuildController:default -
> Merging SCM results
> INFO org.apache.maven.continuum.buildcontroller.BuildController:default -
> The project was not built because there are no changes.
> INFO org.apache.maven.continuum.buildcontroller.BuildController:default -
> No changes, not building
> {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] Reopened: (MNG-3035) Maven caches missing snapshot dependencies, so further builds fail without checking the repo until the cache expires or -U is included to flush the cache
[ http://jira.codehaus.org/browse/MNG-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Parker reopened MNG-3035: - Updated with example and further information (see previous comment) > Maven caches missing snapshot dependencies, so further builds fail without > checking the repo until the cache expires or -U is included to flush the cache > - > > Key: MNG-3035 > URL: http://jira.codehaus.org/browse/MNG-3035 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Tom Parker >Priority: Minor > Attachments: MNG-3035.zip > > > The problem is caused by a slightly obscure sequence, in this example, I use > two projects, Server & Common. Server depends on Common: > Alice updates Server to depend on Common-1.2-SNAPSHOT instead of 1.1-SNAPSHOT > and commits that change. > Bob syncs that change and attempts a build of Server, maven checks for > Common-1.2-SNAPSHOT in the local repo, finds it missing and checks the global > repo, where it is also missing. Maven records this information in a cache and > fails the build. > Alice deploys Common-1.2-SNAPSHOT to the global repo. > Bob attempts to build Server again, maven checks it's cached information and > finds that Common-1.2-SNAPSHOT wasn't in the global repo last time, so fails > the build. > Maven should not fail the build due to missing dependencies simply because > the cache says the dependency was missing last time. It should check the > configured repos before failing. -- 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-3035) Maven caches missing snapshot dependencies, so further builds fail without checking the repo until the cache expires or -U is included to flush the cache
[ http://jira.codehaus.org/browse/MNG-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Parker updated MNG-3035: Attachment: MNG-3035.zip See attached pom files and script to build them in the correct order and simulate two different users. The script has been tested on linux and probably won't work on windows. Be careful as the script will mess around with your ~/.m2/repository. You cannot reliably build anything else while the script is running. The part of the puzzle that I left out is this: When Alice deploys Common 1.2, she creates Common-1.2-20070607.071016-1.jar in the shared repo. When Bob checks a second time for a missing snapshot, he only attempts to download Common-1.2-SNAPSHOT.jar which doesn't exist. > Maven caches missing snapshot dependencies, so further builds fail without > checking the repo until the cache expires or -U is included to flush the cache > - > > Key: MNG-3035 > URL: http://jira.codehaus.org/browse/MNG-3035 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Tom Parker >Priority: Minor > Attachments: MNG-3035.zip > > > The problem is caused by a slightly obscure sequence, in this example, I use > two projects, Server & Common. Server depends on Common: > Alice updates Server to depend on Common-1.2-SNAPSHOT instead of 1.1-SNAPSHOT > and commits that change. > Bob syncs that change and attempts a build of Server, maven checks for > Common-1.2-SNAPSHOT in the local repo, finds it missing and checks the global > repo, where it is also missing. Maven records this information in a cache and > fails the build. > Alice deploys Common-1.2-SNAPSHOT to the global repo. > Bob attempts to build Server again, maven checks it's cached information and > finds that Common-1.2-SNAPSHOT wasn't in the global repo last time, so fails > the build. > Maven should not fail the build due to missing dependencies simply because > the cache says the dependency was missing last time. It should check the > configured repos before failing. -- 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
