I really appreciate all the feedback so far. I see the problem as one of build promotion, where you have a multi-module application with a non-flat physical structure in Subversion; i.e.; the modules are nested two or three deep, with a hierarchy of parent POM files. The actual assembly module is, itself, a non-flat structure, with a hierarchy of sub-assemblies. As I mentioned initially, I use POM inheritance, not aggregation.
What I would like to do is control build-promotion from a single top-level POM file, if that is possible. -----Original Message----- From: Ron Wheeler [mailto:[email protected]] Sent: Tuesday, January 10, 2012 9:39 AM To: [email protected] Subject: Re: How can Maven be used to prepare a complex, multi-module JavaEE app for release 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: [email protected] skype: ronaldmwheeler phone: 866-970-2435, ext 102 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
