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, christofer.d...@c-ware.de 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: christofer.d...@c-ware.de <mailto:christofer.d...@c-ware.de>
http://www.c-ware.de <http://www.c-ware.de/>
UStId-Nr. DE195700962
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
