Process Question

[Kevan Dunsmore <Ke...@sabrix.com>]

I'm trying to determine the "right" way to use Maven in our continuous
integration environment. Here's our basic process:

 

1.	Code changes are made and checked in to SVN.
2.	Cruise Control detects the change and kicks off a build,
executing all the tests. This is a local build (maven clean install).
3.	Once a day, or on demand, CC kicks off a numbered build (maven
clean deploy). This numbered build is tested by QA.

 

So much for the good; now for the bad: We have opposing camps. One camp
uses the deploy plugin as illustrated above. The other camp, on a
separate project, is executing the above process except that instead of
using the deploy plugin, they are using the release plugin. As far as I
can see, the use of the release plugin in step 3 goes against its
intent. The release plugin is meant for a release to a customer, not for
something that happens frequently like a nightly build. Further, the use
of the release plugin in this manner restricts the use of cross-project
libraries to released versions, since the release plugin enforces that
the pom does not depend on any snapshots. 

 

I'd like to get the thoughts of the group on this. I may be missing
something but I'd far rather use the deploy plugin for nightly builds
and the release plugin for packaging the application for release to our
customers. Am I wrong?

 

Thanks,
Kevan.

 

 

 

Kevan Dunsmore

Senior Software Engineer

SABRIX Inc

t: 503.924.4908

f: 503.620.5756

 


This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information that is protected from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and any attachments.

RE: Process Question

[Kevan Dunsmore <Ke...@sabrix.com>]

Patrick,

The other project executes the release plugin in batch mode so it just
uses default values (it increments the last number in the build and
chooses fairly sensible defaults for the other values). 

I also thought about the nice tagging feature of the release plugin and
realized that, since we're using SVN, the repository revision number is
good enough for nightly builds. I plan to look for something (or write
it if I can't find it) that gets a hold of the revision number after
Cruise Control synchs the source. Shoving that in an artifact would be
enough, I think. It would let me pull back everything in the relevant
project for that revision and build it. It's not as thorough as the
tagging / no snapshot policy of the release plugin but I think it is
good enough for such common builds. Other SCM systems work differently
(Perforce, I believe, keeps a unique number for each file and not a
global revision number) so to get the same effect a tagging plugin would
be required, either executed by Maven or by the CI tool you use.

Incidentally, on my project, we need the build number from the output of
the deploy plugin. As far as I could see, there was no way to get a hold
of that so I wrote my own plugin that will read the remote repository
metadata and extract the number from it, making it available as a
project property to the rest of the build.

Thanks for the info, Patrick. Anybody else out there care to share their
thoughts?

Kevan.


-----Original Message-----
From: Patrick Schneider [mailto:pschneider@gmail.com] 
Sent: Wednesday, January 24, 2007 10:59 AM
To: Maven Users List
Subject: Re: Process Question

Interestingly, my organization is trying to figure out the same issue at
the
moment.

The big problem that I see with the 'mvn clean deploy' is that, while
the
build is numbered, you don't really have any way of reproducing that
specific build.  That is, the deploy plugin doesn't tag anything in your
SCM
system.  So, even though your SNAPSHOT is unique by virtue of the fact
you
have a timestamped/numbered artifact, you really don't have a good way
to
"see" the differences between two uniquely numbered SNAPSHOT builds...
maybe this isn't really important, I'm not sure.

The nicest thing about a 'clean deploy' is what you brought up -- you
can
have SNAPSHOT dependencies, whereas in order to do a release, you must
remove any such dependencies.  This can be a huge undertaking if your
project is sufficiently large.

I think you are on the right track re: your assessment of the "right"
way to
use these two plugins.  The release plugin is a weightier process --
doing
it nightly seems overkill, IMO.  Out of curiosity, are they doing the
release manually?  As far as I know, releasing is generally a somewhat
manual process.  There is interaction that has to occur with the user,
such
as determining the next version number, whereas a 'clean deploy' could
be
automated...


Patrick

On 1/24/07, Kevan Dunsmore < Kevan.Dunsmore@sabrix.com> wrote:
>
> I'm trying to determine the "right" way to use Maven in our continuous
> integration environment. Here's our basic process:
>
>
>
> 1.      Code changes are made and checked in to SVN.
> 2.      Cruise Control detects the change and kicks off a build,
> executing all the tests. This is a local build (maven clean install).
> 3.      Once a day, or on demand, CC kicks off a numbered build (maven
> clean deploy). This numbered build is tested by QA.
>
>
>
> So much for the good; now for the bad: We have opposing camps. One
camp
> uses the deploy plugin as illustrated above. The other camp, on a
> separate project, is executing the above process except that instead
of
> using the deploy plugin, they are using the release plugin. As far as
I
> can see, the use of the release plugin in step 3 goes against its
> intent. The release plugin is meant for a release to a customer, not
for
> something that happens frequently like a nightly build. Further, the
use
> of the release plugin in this manner restricts the use of
cross-project
> libraries to released versions, since the release plugin enforces that
> the pom does not depend on any snapshots.
>
>
>
> I'd like to get the thoughts of the group on this. I may be missing
> something but I'd far rather use the deploy plugin for nightly builds
> and the release plugin for packaging the application for release to
our
> customers. Am I wrong?
>
>
>
> Thanks,
> Kevan.
>
>
>
>
>
>
>
> Kevan Dunsmore
>
> Senior Software Engineer
>
> SABRIX Inc
>
> t: 503.924.4908
>
> f: 503.620.5756
>
>
>
>
> This e-mail message, including any attachments, is for the sole use of
the
> intended recipient(s) and may contain confidential and privileged
> information that is protected from disclosure. Any unauthorized
review, use,
> disclosure or distribution is prohibited. If you are not the intended
> recipient, please contact the sender by reply e-mail and destroy all
copies
> of the original message and any attachments.
>
>
>

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

Re: Process Question

[Patrick Schneider <ps...@gmail.com>]

Interestingly, my organization is trying to figure out the same issue at the
moment.

The big problem that I see with the 'mvn clean deploy' is that, while the
build is numbered, you don't really have any way of reproducing that
specific build.  That is, the deploy plugin doesn't tag anything in your SCM
system.  So, even though your SNAPSHOT is unique by virtue of the fact you
have a timestamped/numbered artifact, you really don't have a good way to
"see" the differences between two uniquely numbered SNAPSHOT builds...
maybe this isn't really important, I'm not sure.

The nicest thing about a 'clean deploy' is what you brought up -- you can
have SNAPSHOT dependencies, whereas in order to do a release, you must
remove any such dependencies.  This can be a huge undertaking if your
project is sufficiently large.

I think you are on the right track re: your assessment of the "right" way to
use these two plugins.  The release plugin is a weightier process -- doing
it nightly seems overkill, IMO.  Out of curiosity, are they doing the
release manually?  As far as I know, releasing is generally a somewhat
manual process.  There is interaction that has to occur with the user, such
as determining the next version number, whereas a 'clean deploy' could be
automated...


Patrick

On 1/24/07, Kevan Dunsmore < Kevan.Dunsmore@sabrix.com> wrote:
>
> I'm trying to determine the "right" way to use Maven in our continuous
> integration environment. Here's our basic process:
>
>
>
> 1.      Code changes are made and checked in to SVN.
> 2.      Cruise Control detects the change and kicks off a build,
> executing all the tests. This is a local build (maven clean install).
> 3.      Once a day, or on demand, CC kicks off a numbered build (maven
> clean deploy). This numbered build is tested by QA.
>
>
>
> So much for the good; now for the bad: We have opposing camps. One camp
> uses the deploy plugin as illustrated above. The other camp, on a
> separate project, is executing the above process except that instead of
> using the deploy plugin, they are using the release plugin. As far as I
> can see, the use of the release plugin in step 3 goes against its
> intent. The release plugin is meant for a release to a customer, not for
> something that happens frequently like a nightly build. Further, the use
> of the release plugin in this manner restricts the use of cross-project
> libraries to released versions, since the release plugin enforces that
> the pom does not depend on any snapshots.
>
>
>
> I'd like to get the thoughts of the group on this. I may be missing
> something but I'd far rather use the deploy plugin for nightly builds
> and the release plugin for packaging the application for release to our
> customers. Am I wrong?
>
>
>
> Thanks,
> Kevan.
>
>
>
>
>
>
>
> Kevan Dunsmore
>
> Senior Software Engineer
>
> SABRIX Inc
>
> t: 503.924.4908
>
> f: 503.620.5756
>
>
>
>
> This e-mail message, including any attachments, is for the sole use of the
> intended recipient(s) and may contain confidential and privileged
> information that is protected from disclosure. Any unauthorized review, use,
> disclosure or distribution is prohibited. If you are not the intended
> recipient, please contact the sender by reply e-mail and destroy all copies
> of the original message and any attachments.
>
>
>