Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project

On Friday, 2 August 2013, Stephen Colebourne wrote: > On 2 August 2013 01:10, Stephen Connolly > > wrote: > > The use of wildcard-like behaviour is not a good plan, so being slightly > > more cumbersome on the CLI is a bonus from my PoV. > > > > I prefer to encourage best practice by making non-be

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

On 02/08/2013 12:56 AM, Baptiste MATHUS wrote: 2013/8/2 Ron Wheeler > On 01/08/2013 5:55 PM, Jonathan Sharp wrote: I think John C raises an interesting case here, where the voting process can fall down. A large code d

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

2013/8/2 Ron Wheeler > On 01/08/2013 5:55 PM, Jonathan Sharp wrote: > >> I think John C raises an interesting case here, where the voting process >> can fall down. >> >> A large code dump like that can hurt the quality of documentation and >> support (in addition to team morale). >> > It depends

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

On 01/08/2013 5:55 PM, Jonathan Sharp wrote: I think John C raises an interesting case here, where the voting process can fall down. A large code dump like that can hurt the quality of documentation and support (in addition to team morale). It depends on how good the code and documentation is!

Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project

On 2 August 2013 01:10, Stephen Connolly wrote: > The use of wildcard-like behaviour is not a good plan, so being slightly > more cumbersome on the CLI is a bonus from my PoV. > > I prefer to encourage best practice by making non-best practice harder... > Making it impossible is not a good idea IM

Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project

On Friday, 2 August 2013, Stephen Colebourne wrote: > I'll try and test it tomorrow. > > However, I'd encourage you to take a step back and think if the use of > three extra arguments to the plugin, which is primarily intended for > command line use, is a pleasant UI. I'd also encourage you to con

Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project

I'll try and test it tomorrow. However, I'd encourage you to take a step back and think if the use of three extra arguments to the plugin, which is primarily intended for command line use, is a pleasant UI. I'd also encourage you to consider whether updating a single GAV wherever it is found is re

Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project

Fixed in r18607 and I've redeployed a 2.2-SNAPSHOT I now have test cases and I have verified that there are no regressions. Just have to decide if there is anything else I will add before cutting a release On 1 August 2013 18:54, Stephen Connolly wrote: > > > On Thursday, 1 August 2013, Stephe

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

I think John C raises an interesting case here, where the voting process can fall down. A large code dump like that can hurt the quality of documentation and support (in addition to team morale). My $.02 Jon On Thu, Jul 25, 2013 at 2:36 PM, John Casey wrote: > > It's about whether you expect

Re: Maven war has META-INF folder in two places

Am 2013-08-01 18:19, schrieb Gabriel Miró: Hello, I'm working on a project which uses JAAS and unfortunately for me Tomcat requires a file to be put in a META-INF folder in the root of the war app.war |__META-INF ||___context.xml ... I think that it's already weird since the defaul

Maven war has META-INF folder in two places

Hello, I'm working on a project which uses JAAS and unfortunately for me Tomcat requires a file to be put in a META-INF folder in the root of the war app.war |__META-INF ||___context.xml ... I think that it's already weird since the default META-INF location for WAR's is in the clas

Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project

On Thursday, 1 August 2013, wrote: > This is exactly what I needed a couple of weeks ago. I came up with the > same procedure but discovered that the versions plugin doesn't support > unresolving ranges. Is this something that's in the works or it's just > something you wish were there? > > It is

Re: version range: fix version prefix + RELEASE

> example. In theory this should be accomplished by [1.8.0,1.9.0). But due to > http://jira.codehaus.org/browse/MNG-3092 > this also includes snapshots I > do not want. > > Is there some possibility to override the default maven dependecy resolver > some

Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project

This is exactly what I needed a couple of weeks ago. I came up with the same procedure but discovered that the versions plugin doesn't support unresolving ranges. Is this something that's in the works or it's just something you wish were there? Alejandro Endo | Software Designer/Concepteur de l

Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project

On Thursday, 1 August 2013, Stephen Colebourne wrote: > No, I didn't use the wildcards (they are very unatural UI for solving > what seems like a normal case) > With wildcards I got NPE: I'll have a look > > [ERROR] Failed to execute goal > org.codehaus.mojo:versions-maven-plugin:2.2-SNAPS >

Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project

No, I didn't use the wildcards (they are very unatural UI for solving what seems like a normal case) With wildcards I got NPE: [ERROR] Failed to execute goal org.codehaus.mojo:versions-maven-plugin:2.2-SNAPS HOT:set (default-cli) on project london-dev: Execution default-cli of goal org.c odehaus.

Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project

Yeah I need to write some tests... You did use wildcards by the way? ie $ mvn versions:set -DgroupId=\* -DartifactId=\* -DoldVersion=\* -Dversion=... Keep in mind you need to escape the wildcard appropriate for your shell or it will replace with a glob that can never match On Thursday, 1 Augus

Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project

I pulled svn and tried it, and it didn't work in my case. It didn't even set the root aggregator pom. My set-aggregated goal is here and does work: https://gist.github.com/jodastephen/6133391 Unfortunately, half my test project is private so its hard to describe/publish logs. Stephen On 1 Aug

Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project

Please try 2.2-SNAPSHOT It may or may have wildcard support that works and doesn't cause any regressions... I need to write some tests for the wildcard stuff. On 1 August 2013 15:39, Stephen Colebourne wrote: > Thanks for the detailed description, which I hope your making a web page > out of.

Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project

Thanks for the detailed description, which I hope your making a web page out of. Here is the current description "Sets the current projects version, updating the details of any child modules as necessary." From that I conclude it will set the current project version and any child modules necessary

Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project

If I understand this correctly, goal is to release 2 wars, which have some jars and some wars in common. And, everything is part of the same multi-module-maven-project. That would be sth like: -pom (all versions are defined only here) |- jar1 |- jar2 (depends on jar1) |- war-inc |- war A (dep

Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project

first off versions:set is a @aggregator mojo. That means it only operates on the -f specified pom file or the pom file in the working directory. The goal is to update *that one project's version* it is not trying to update other project versions. So if you have A +B |+C |+D +E |+F \G where C an

Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project

The problem is that as it currently stands, the plugin gives the appearance of randomly choosing when to change versions. If you consider the second example, the set goal changes R, A, B, D and E, but not C, despite C being a child of A and in A's aggregator. Its hard to not describe that as a bug.

Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project

On 01/08/13 01:19 AM, Nestor Urquiza wrote: Hi, Let me give more information, I use an aggregator project for war1 project: ../jar1 ../jar2 ../war-inc ../war1 Another aggregator project for war2 project: ../jar1 ../war-inc

Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project

the correct way I see to handle this is to support wildcards in versions:set, e.g. mvn versions:set -DgroupId=* -DartifactId=* -DoldVersion=* -DnewVersion=1.2-SNAPSHOT which would therefore match not just the invoked project but all projects in the reactor. The changes in MVERSIONS-131 go agains

Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project

I think this is perhaps related to problems I am seeing right now as well. Basically, the versions:set goal is buggy except in the classic case where the hierarchy of aggregation matches the hierarchy of inheritance. See http://jira.codehaus.org/browse/MVERSIONS-131 and http://jira.codehaus.org/b

Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project

How I want this to work is to have versions-maven-plugin have a way to undo versions:resolve-ranges ( http://mojo.codehaus.org/versions-maven-plugin/resolve-ranges-mojo.html) - it would need to ensure that the lower bound of any unresolved range is the resolved version... [see below] We'd need to