Re: How can Maven be used to prepare a complex, multi-module JavaEE app for release

2012-01-10 Thread Antonio Petrelli
2012/1/10 Glenn Silverman gsilver...@dispensingsolutionsinc.com

 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 think you answered yourself. Move to a multi-module POM+.
Moreover, you wrote about a complex application made up of several wars,
besides other artifacts. Do you mean that, in the end, you have a single
EAR?

Antonio


Re: How can Maven be used to prepare a complex, multi-module JavaEE app for release

2012-01-10 Thread Jasper de Vries
You might want to take a look at the versions plugin
(http://mojo.codehaus.org/versions-maven-plugin/) to change the root
POM and make the child modules fall in line (update-child-modules
goal).

Best maven practice seems to be that you don't try to release part of
a hierarchy. If there are modules that shouldn't be released, put them
elsewhere (and release them individually or as part of another
hierarchy). If there are modules that could be released but needn't be
released (because they don't contain changes), it's usually easiest to
release them anyway rather then bend yourself backwards.

On Tue, Jan 10, 2012 at 9:42 AM, Antonio Petrelli
antonio.petre...@gmail.com wrote:
 2012/1/10 Glenn Silverman gsilver...@dispensingsolutionsinc.com

 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 think you answered yourself. Move to a multi-module POM+.
 Moreover, you wrote about a complex application made up of several wars,
 besides other artifacts. Do you mean that, in the end, you have a single
 EAR?

 Antonio

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



Re: How can Maven be used to prepare a complex, multi-module JavaEE app for release

2012-01-10 Thread Ron Wheeler

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

RE: How can Maven be used to prepare a complex, multi-module JavaEE app for release

2012-01-10 Thread Glenn Silverman
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:rwhee...@artifact-software.com] 
Sent: Tuesday, January 10, 2012 9:39 AM
To: users@maven.apache.org
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: 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