You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Glenn Silverman <gs...@dispensingsolutionsinc.com> on 2012/01/10 02:07:18 UTC
How can Maven be used to prepare a complex, multi-module JavaEE app for release
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.
RE: How can Maven be used to prepare a complex, multi-module JavaEE app for release
Posted by Glenn Silverman <gs...@dispensingsolutionsinc.com>.
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:rwheeler@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: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How can Maven be used to prepare a complex, multi-module JavaEE
app for release
Posted by Ron Wheeler <rw...@artifact-software.com>.
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: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: How can Maven be used to prepare a complex, multi-module JavaEE
app for release
Posted by Jasper de Vries <li...@gmail.com>.
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
<an...@gmail.com> wrote:
> 2012/1/10 Glenn Silverman <gs...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How can Maven be used to prepare a complex, multi-module JavaEE
app for release
Posted by Antonio Petrelli <an...@gmail.com>.
2012/1/10 Glenn Silverman <gs...@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