Hi Chris, Well the project consists of about 80 modules. The main reason for this is that the application is a big Swing application distributed via some web-start similar technology. The reason for releasing only parts is that the application is used all over the world and some locations have a really limited internet connection. So being able to release only changed modules reduces the time needed of the update from several hours to minutes. Hours during which people can't work. So I do agree ... releasing fragments is generally a bad idea and it does come with quite a price to pay. But my customer is willing to pay that "price" in order to be able to not pay the price of stalling business all over the world every one or two weeks.
The way the release plugin currently works, indeed this would create inconsistent tags. That's why I would like to provide dev and release versions for all modules of the project and then limit the release plugin to process only selected modules (Of course ... if you have a dependency management section in your root and you release that with the others, things will break, but if you reference each internal module with it's version directly). The tag would contain poms with released versions for each module that was part of the sub-release and would contain SNAPSHOT versions for all others. So if you did a full build of the tag, the exact same output should be produced. Hopefully this explains the reasons a little more. Chris ________________________________________ Von: Chris Graham [[email protected]] Gesendet: Donnerstag, 14. Februar 2013 22:45 An: Maven Developers List Betreff: Re: Update release plugin to allow more fine-grained releases If I understand what you've written correctly, you wish to build/release only parts of your project. If that is the case, then I a'd advise you to split the projects to in two separate ones, each with their own trunk etc. That way when you check out from a tag, you'll be building everything correctly, the maven way. -Chris On Thu, Feb 14, 2013 at 10:12 PM, [email protected] < [email protected]> wrote: > But thanks for that hint to check 2.3.2 ... I'll have a look at that this > weekend :-) > > ________________________________________ > Von: Robert Scholte [[email protected]] > Gesendet: Donnerstag, 14. Februar 2013 11:59 > An: Maven Developers List > Betreff: Re: Update release plugin to allow more fine-grained releases > > Be aware that you can't determine with which arguments the deploy was done. > So if you check out the sources from tag, how should you re-install these > projects? > It should be as simple as 'mvn install'. > This means that the projects you don't want to release should keep their > -SNAPSHOT version. > There's a good chance that this has changed with m-release-p 2.4, since > it checks the value of the release and development versions. Until now > nobody had problems with it and that's a good thing. > So maybe 2.3.2 is a better version for you, so you can keep the > unreleasable projects on their old SNAPSHOT version. > > Robert > > Op Wed, 13 Feb 2013 20:30:39 +0100 schreef [email protected] > <[email protected]>: > > > Hi, > > > > I was experimenting a little with the release plugin. > > > > In one of my experiments I gave it a really long list of dev- and > > release-versions for a lot of artifacts using the "-Dproject.rel." and > > "-Dproject.dev." properties. Then I limited my maven build to only > > process a hand full of modules. > > > > What I was expecting, was that in the modules in the reactor the > > versions I provided would have been used to update the versions of all > > the artifacts I provided the plugin with. But I had to realize that the > > artifact versions of only the artifacts in the reactor were updated, but > > also for the modules that were not included. > > > > I find this way of processing quite problematic. > > > > I would volunteer to have a look at the plugin and whip up a patch. But > > I guess this only makes sense, if there is a chance of my work actually > > being accepted. > > > > What do you think about this? > > > > Chris > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
