I can see your issue :-) and this is where you'll run into the opinionated nature of maven. :-)
I work to the adage of work with the tools, not against them. In this case, I would change your distribution and update mechanism. Simply put, add another module that contains a manifest of the _actual_ changes (this process will need to stringently controlled). Then have your app pull down the manifest (I'd do it in XML) and then download the actual changes. Ultimately, I think you'll that less work for you in reworking the release plugin (it keeps the well known and well understood processes in tact) and provides a better solution for your customers. Just a thought. -Chris Sent from my iPhone On 15/02/2013, at 7:24 PM, "[email protected]" <[email protected]> wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
