We had the same situation.
One of the things that we did as the application got more mature was to
decide that not all modules need to be at the same version number.
This was just an abstraction of the idea that we had already accepted
that third party libraries had different version number and worked just
fine.
We did have an architecture that was functionally organized so we did
get to a state where minor releases (1.x to 1.y) did not actually
require code changes in the majority of modules.
We used Hibernate for the ORM and had an API for database access and a
lot of web services which helped insulate the view from the model.
In the planning phase, we identified the modules that would be changed
and created a simple spreadsheet that we used to control the versions in
each release.
This reduced the overhead and removed the frustration of having to
rebuild modules just to change a version number.
In reality, changing all the modules' versions was not a major consumer
of time but more of an annoyance at doing something for no useful purpose.
Ron
On 09/01/2012 8:07 PM, Glenn Silverman wrote:
We have a complex JavaEE app with multiple wars, jars, ds.xml and config
files, etc. In fact, there are over 80 different artifacts that make up
our application. We use the maven-assembly-plugin to create a gzip file
and untar it into a JBOSS instance to deploy and run. It's not pretty
and it's a nightmare to actually do a release. We use Subversion, Maven
3, Nexus for repository management and Jenkins for build management. The
following are the manual steps required for us to do a release:
1. Create a SNAPSHOT version of the changed modules and deploy to
a test environment
a. Create a SNAPSHOT branch in SVN
b. Copy changed modules to the new branch from trunk
c. Manually change the dependency versions from SNAPSHOT as
needed in each individual POM
d. Manually change the dependency versions in the assembly POM
files (there are 5 sub assemblies and one main assembly to put them all
together)
e. Run mvn deploy on each new module to install SNAPSHOT versions
to Nexus
f. Run mvn install on each sub-assembly (I don't want to deploy
the assemblies to Nexus)
g. Run mvn package on the main assembly
h. Copy and untar the main assembly on our QA JBOSS
server/instance
2. Create a RELEASE version and deploy to production
a. Merge the SNAPSHOT branch modules in SVN to trunk
b. Repeat steps a-h, above, manually removing "-SNAPSHOT" from all
the POM files
I've tried to simplify a little by consolidating dependency management
in the parent assembly, but it still requires that I modify each
affected sub-assembly to use the correct parent version. Why not use the
maven-release-plugin to eliminate the manual process, you might wonder?
Great, then I have to modify each POMs scm element whenever I do a
SNAPSHOT-to-RELEASE, and, unless I use module inheritance in my POMs at
some point, the release plugin isn't going to recurse through all of the
changed modules for me.
I thought maven was supposed to relieve me of this manual configuration
nightmare, but it seems to only have increased it. All of the
documentation and Web-help I have seen discusses only simple
multi-module systems, with maybe a war, an ejb and a domain jar, for
example. That's child's play compared to what we have to deal with, and
I'm just out of ideas. Maybe someone out there has faced a similar
daunting task and can help. Thanks in advance.
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
