As described in my other response. Simply keeping the versions in sync is not
an option for us due to the donwtime this would mean for our clients and the
load this would generate on the central servers.
Well currently the approach to release a new version was to have all modules
defined in the master pom modules-section as well as a
dependencyManagement-section that defines the versions of all the modules.
Now if a new build was to be made that updates only some of the modules, the
other modules (the ones that should stay the same) were commented out of the
master poms modules-section and then the releaseplugin was used to release the
desired artifacts. After the release was finished the versions hat do be
manually updated.
This process really sucked and caused a lot of problems.
Now my approach was not to use the release plugin at all and to define all of
the versions used throughout the entire project in the master pom using
properties. So all I had to do was to increase the versions in the release
profile to the versions I want and commit that. Now in jenkins I was able to
define some jobs to run "mvn deploy" for individual projects with turned on
"release" profile.
To me this seems a lot cleaner than all other approaches, but as I don't want
to kill too many kittens (As stephen on the dev-list called it). So I'm open
for other suggestions or explanationy WHY this is bad.
Stephen claimed that if I re-define my properties in child modules, I would
have really big trouble, but we are developing the entire project and this is a
thing we could fefinitely rule out because it should be really easy to enforce
such a constraint ("Versions are defines solely in the master pom"). And as I
mentioned, to me it looks more like a highly restricted feature than a bug in
maven that I was able to use a variable in the version.
Chris
________________________________________
Von: Ron Wheeler [[email protected]]
Gesendet: Dienstag, 16. Oktober 2012 00:21
An: [email protected]
Betreff: Re: Independent module release strategies
Our project was about 50% larger in terms of modules and we did what you
are suggesting and got rid of the idea of increasing versions on
artifacts that did not change.
I am not sure why this is causing you more problems rather than less.
We had a master spreadsheet listing all of our modules and their versions.
Every time we issued a new release, we went through the list at looked
at what was going to change and what was going to carry through "as is"
with the version number that it had.
We also looked at third party libraries that we wanted to upgrade at the
same time.
We fixed up each pom to update the versions of anything that was going
to change to a x.x-SNAPSHOT and moved on.
It took about an hour to do the whole job since our system was service
oriented so there were not a lot of dependencies.
Once a module was tested and released we updated the dependencies to the
released module.
We still ended up with a lot of releases at the very end of the upgrade
process but that is partly human nature since deleting a release is a
bad thing even if it is one of yours and could only be done by me so it
got a lot of visibility if someone made a mistake.
It is hard to get everyone confident that their module's specification
will not change due to someone else making a mistake in their design
which only gets detected late in the process. They solved this by
staying at the SNAPSHOT after they had it fully tested and ready for
release, if someone who depended on it was not yet done.
It was not a big problem and I never took any steps to fix it.
We aggregated a lot of library-like dependencies into larger packages
that were "provided". This gave a dependency on our "utilities" package
that actually was an aggregation of several projects so each war project
did not have dozens of dependencies on modules that were shared by most
modules.
We did this with third party software as well so a lot of really useful
Apache libraries were aggregated into 1 jar that all projects depended on.
This reduced the number of dependencies in the POM files and made them a
lot easier to maintain.
By using a lot of "Provided" jars, we really sped up the builds and
reduced the size of the war files from megabytes to kilobytes since they
only contained the code that was in the source files rather that a few
Kb of code output and megabytes of libraries.
I am not sure that this is the best way to tackle the problem but it
eliminated the work that we were doing when we changed the version on
everything that made up the application.
It also got us thinking about our own packages in the same way that we
looked at Apache libraries.
There was an incentive to think about interfaces and SOA in a more
considered way.
I hope that this helps.
You are on the right track and your project is still pretty small at 50
modules.
Ron
On 15/10/2012 5:32 PM, [email protected] wrote:
>
> Hi,
>
> I am currently working on finetuning the workflows on a large
> application that was migrated from an Ant based build to one based
> upon Maven.
>
> The build itself is running smoothly but, what I'm currently working
> on is getting the release workflow optimized.
>
> The project consists of about 50 Maven artifacts. A lot of people are
> using this project all over the world. The client is distributed by
> some web-start similar solution.
>
> The problem is whenever a bugfix-release is done, we don't want to
> release all modules in a new version because then all of these would
> have to be downloaded by the clients.
>
> So we have a project with a lot of modules and a parent pom that
> configures the plugins.
>
> Using the regular maven-release-plugin involves a lot of manual
> adjusting of version numbers and I would like to eliminate this.
>
> That's why I setup the master pom to have two profiles "develop"
> (active by default) and "release" activated during a release. In both
> profiles a lot of properties are configured to be used for setting the
> artifact versions.
>
> No comes the part where I was told on the dev-list that I was tempted
> by the dark side of the force ;-)
>
> In my master pom, I defined one major dependencyManagement section
> fixing the version of each artifact to the versions in the properties.
> Ok ... so this is normal and this is not "dark side magic". But in
> order to have the parent version automatically configured the right
> way I wanted to have the version of the parent link configured by
> these properties too. Ok so maven doesn't allow this. But it seems
> that this is not entirely true:
>
> If I configre the version of the artifact I want to use as parent with
> the same variable as I am using in the parent definition of the child
> module. Maven seems to work fine with that. The only thing that I was
> not quite satisfied with, was that the install plugin installed the
> raw poms into my local repo. The directory it was installed to
> contained the correct version so the resolution must have worked.
> That's why I thought this was a bug in the deploy plugin and that's
> why I filed an issue (which was immediately closed because I was doing
> bad magic) http://jira.codehaus.org/browse/MNG-5358
>
> I attached an example project containing an example configuration
> demonstrating what I was doing.
>
> What I find particularly strange is that Maven claims not to resolve
> properties in project.version and project.parent.version and in 90% of
> the cases this is true:
>
> Let me illustrate thsi a little. Assuming I have only two projects ...
> one master and one module.
>
> If I define two properties in my master pom: "my.cool.master.version"
> and "my.cool.alternate.master.version" and set both to the same value
> of "1.2-SNAPSHOT".
>
> In szenario 1: I hard code the version of the master to "1.2-SNAPSHOT"
> but use the property to reference the parent from the moule ... when
> running a build, maven tries to download
> "de/mycompany/test/${my.cool.master.version}/mycoolmaster-${my.cool.master.version}.pom"
> --> Failure, because the property is not resolved
>
> In szenario 2: I use the same variable for defining the masters
> version. This time the maven build runs fine and the parent version is
> correctly resolved.
>
> In szenario 3: I use the first property to define the version of the
> master and the second one for referncing the parent from the module
> ... when running a build, maven tries to download
> "de/mycompany/test/${my.cool.alternate.master.version}/mycoolmaster-${my.cool.alternate.master.version}.pom"
> --> Failure, because the property is not resolved
>
> So to me it looks as if there was some sort of intention behind
> everything and not a bug in the system as I was told on the dev-list.
> To me it looks like one teeniewienie loophole allowing properies in
> versions while closing the usage range so much that possible harm is
> reduced to it's absolute minimum. So it seems that my usecase seems to
> be the onlly one allowed. After all ... this is a problem users are
> begging for maven to provide a solution since maven 2.0 (When looking
> at the forums).
>
> Ok ... and now to finish the loop back to my topic:
>
> If I am doing bad sourcery ... how would I setup one maven build to
> allow simple releases of individual modules with individual versions?
>
> Chris
>
> [ C h r i s t o f e r D u t z ]
>
> C-Ware IT-Service
>
> Inhaber
>
> Dipl. Inf. Christofer Dutz
>
> Karlstraße. 104, 64285 Darmstadt
>
> Beschreibung: 788335
> <http://www.benchpark.com/788335/kundenzufriedenheit.htm>
>
> IT- und Systemhäuser <http://www.benchpark.com/it_und_systemhaeuser.htm>
>
> fon: 0 61 51 / 27315 - 61
>
> fax: 0 61 51 / 27315 - 64
>
> mobil: 0171 / 7 444 2 33
>
> email: [email protected] <mailto:[email protected]>
>
> http://www.c-ware.de <http://www.c-ware.de/>
>
> UStId-Nr. DE195700962
>
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
