You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by amit kumar <am...@gmail.com> on 2008/02/06 15:25:59 UTC
Conceptual Confusion about build and release process using maven.
Hi,
Please pardon me for such a long mail but couldn't cut it any shorter.
After 2 months of being assigned the task of mavenizing the whole
product at my workplace and build and release automation process with
Continuous Integration, I have been able to mavenize the product and
put continuum and mavenized CVS structure in sync.
But while pondering over how to go about with the build an release
strategy I got myself in deep confusion.
The product (as usual) has several submodules with separate developers
and with many intermodule dependencies. My understanding of the whole
process till now has been like below
Development environment, after intranet maven repository in place
would be something like this: owner of module A would deploy the A.jar
on maven repository from where the other module owners which depend on
a.jar would fetch it from. And as the development goes on for module
A, the owner of module will keep on changing the versions (with in an
iteration as well) and deploying it on to the maven repository and
dependent modules will keep on changing the version in their pom.xml
for "a.jar".(unsure about whether this is how it happens)
All these developments in various modules keep on getting committed
into the CVS from where the Continuum keeps on checking out and
building ( Continuous Integration).
Now my confusion over my own understanding and assumption is:
1) During the development process within an iteration, how to make
sure that all the module owners dependent on "a.jar" keeps up to date
with the changing versions of a.jar as the development goes on until
Integration Testing.
2) If a module owner dependent on a.jar fails to update the version of
the a.jar in the pom.xml and/or miss to commit the updated pom.xml
with a contemporary version of a.jar. Continuous Integration at
Continuum would suffer( assuming that even with not up to date version
of a.jar the module still gets through build),
Pardon me for any wrong assumptions, I do not have much exposure to the process.
Regards,
Amit
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Conceptual Confusion about build and release process using maven.
Posted by Nicole Lacoste <ni...@gmail.com>.
Hi,
I recommend reading chapter 7, Team Collaboration with Maven, from Better
Builds with Maven.
Nicole
On 07/02/2008, simon <si...@chello.at> wrote:
>
>
> On Wed, 2008-02-06 at 09:47 -0500, Edelson, Justin wrote:
> > > 1) During the development process within an iteration, how to make
> > > sure that all the module owners dependent on "a.jar" keeps up to date
> > > with the changing versions of a.jar as the development goes on until
> > > Integration Testing.
> > It sounds to me like you want to use a SNAPSHOT version within each
> iteration. That way dependent module owners don't need to constantly update
> their poms. Once you hit your testing phase, do an "alpha" or "beta"
> release of all the modules and test against that.
>
> Yes, this is probably what you are looking for.
>
> (1) deploying
>
> When a module with a version of form 1.2.3-SNAPSHOT is deployed, then
> there are two choices: with or without datestamp.
>
> Without datestamp, the 1.2.3-SNAPSHOT file will just overwrite the
> previous one in the repository.
>
> With datestamp, a new 1.2.3-SNAPSHOT-yyyymmddn file file be created.
>
> Whether deploy applies datestamps or not is configured in the repository
> block. Using datestamps clutters the repository, but does mean that
> other projects can decide to depend on the snapshot for a particular
> date if they want.
>
> (2)
> When a project has a dependency on a 1.2.3-SNAPSHOT module, then it
> checks the repository for a 1.2.3-SNAPSHOT-yyyymmddn or 1.2.3-SNAPSHOT
> file, and downloads it if it is newer.
>
> Exactly when the check is done is configurable: every time maven is run,
> once per day, once per week (I think those are the options). I cannot
> remember offhand where that is configured.
>
> Regards,
> Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: Conceptual Confusion about build and release process using
maven.
Posted by simon <si...@chello.at>.
On Wed, 2008-02-06 at 09:47 -0500, Edelson, Justin wrote:
> > 1) During the development process within an iteration, how to make
> > sure that all the module owners dependent on "a.jar" keeps up to date
> > with the changing versions of a.jar as the development goes on until
> > Integration Testing.
> It sounds to me like you want to use a SNAPSHOT version within each iteration. That way dependent module owners don't need to constantly update their poms. Once you hit your testing phase, do an "alpha" or "beta" release of all the modules and test against that.
Yes, this is probably what you are looking for.
(1) deploying
When a module with a version of form 1.2.3-SNAPSHOT is deployed, then
there are two choices: with or without datestamp.
Without datestamp, the 1.2.3-SNAPSHOT file will just overwrite the
previous one in the repository.
With datestamp, a new 1.2.3-SNAPSHOT-yyyymmddn file file be created.
Whether deploy applies datestamps or not is configured in the repository
block. Using datestamps clutters the repository, but does mean that
other projects can decide to depend on the snapshot for a particular
date if they want.
(2)
When a project has a dependency on a 1.2.3-SNAPSHOT module, then it
checks the repository for a 1.2.3-SNAPSHOT-yyyymmddn or 1.2.3-SNAPSHOT
file, and downloads it if it is newer.
Exactly when the check is done is configurable: every time maven is run,
once per day, once per week (I think those are the options). I cannot
remember offhand where that is configured.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Conceptual Confusion about build and release process using maven.
Posted by "Edelson, Justin" <Ju...@mtvstaff.com>.
> 1) During the development process within an iteration, how to make
> sure that all the module owners dependent on "a.jar" keeps up to date
> with the changing versions of a.jar as the development goes on until
> Integration Testing.
It sounds to me like you want to use a SNAPSHOT version within each iteration. That way dependent module owners don't need to constantly update their poms. Once you hit your testing phase, do an "alpha" or "beta" release of all the modules and test against that.
Just my 2 cents.
Justin
________________________________
From: amit kumar [mailto:amit.kumar97400@gmail.com]
Sent: Wed 2/6/2008 9:25 AM
To: users@maven.apache.org
Subject: Conceptual Confusion about build and release process using maven.
Hi,
Please pardon me for such a long mail but couldn't cut it any shorter.
After 2 months of being assigned the task of mavenizing the whole
product at my workplace and build and release automation process with
Continuous Integration, I have been able to mavenize the product and
put continuum and mavenized CVS structure in sync.
But while pondering over how to go about with the build an release
strategy I got myself in deep confusion.
The product (as usual) has several submodules with separate developers
and with many intermodule dependencies. My understanding of the whole
process till now has been like below
Development environment, after intranet maven repository in place
would be something like this: owner of module A would deploy the A.jar
on maven repository from where the other module owners which depend on
a.jar would fetch it from. And as the development goes on for module
A, the owner of module will keep on changing the versions (with in an
iteration as well) and deploying it on to the maven repository and
dependent modules will keep on changing the version in their pom.xml
for "a.jar".(unsure about whether this is how it happens)
All these developments in various modules keep on getting committed
into the CVS from where the Continuum keeps on checking out and
building ( Continuous Integration).
Now my confusion over my own understanding and assumption is:
1) During the development process within an iteration, how to make
sure that all the module owners dependent on "a.jar" keeps up to date
with the changing versions of a.jar as the development goes on until
Integration Testing.
2) If a module owner dependent on a.jar fails to update the version of
the a.jar in the pom.xml and/or miss to commit the updated pom.xml
with a contemporary version of a.jar. Continuous Integration at
Continuum would suffer( assuming that even with not up to date version
of a.jar the module still gets through build),
Pardon me for any wrong assumptions, I do not have much exposure to the process.
Regards,
Amit
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Conceptual Confusion about build and release process using maven.
Posted by VUB Stefan Seidel <ss...@vub.de>.
amit kumar wrote:
> Hi,
>
> 1) During the development process within an iteration, how to make
> sure that all the module owners dependent on "a.jar" keeps up to date
> with the changing versions of a.jar as the development goes on until
> Integration Testing.
>
Use version ranges. Developers can update versions in their modules and
other developers can pick up the latest version automatically by
declaring <version>[1,)</version>. As others have recommended, "Better
builds with Maven" is an excellent book about this and other topics.
> 2) If a module owner dependent on a.jar fails to update the version of
> the a.jar in the pom.xml and/or miss to commit the updated pom.xml
> with a contemporary version of a.jar. Continuous Integration at
> Continuum would suffer( assuming that even with not up to date version
> of a.jar the module still gets through build),
Again, version ranges help. You developers may update the lower boundary
for the version range from time to time just to make sure that the
features they need in their modules are present in the modules they
depend on.
You should also use the release feature of continuum or the maven
release plugin to make sure that the module versions are updated and the
jars are being properly deployed to the repository.
--
best regards,
Stefan Seidel
software developer
________________________
VUB Printmedia GmbH
Chopinstraße 4
D-04103 Leipzig
Germany
tel. +49 (341) 9 60 50 07
fax. +49 (341) 9 60 50 92
mail. sseidel@vub.de
web. www.vub.de
HRB Köln 24015
UStID DE 122 649 251
GF Dr. Achim Preuss Neudorf,
Dr. Christian Preuss Neudorf
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Conceptual Confusion about build and release process using maven.
Posted by Rahul Thakur <ra...@gmail.com>.
Now my confusion over my own understanding and assumption is:
> 1) During the development process within an iteration, how to make
> sure that all the module owners dependent on "a.jar" keeps up to date
> with the changing versions of a.jar as the development goes on until
> Integration Testing.
>
In my opinion there is also some bit of discipline involved here. Your
CI server does scheduled builds for all project modules. Developers
should ensure they update their projects regularly. For me the first
thing in the morning when I get to work are:
> svn up
> mvn clean eclipse:clean eclipse:eclipse -DdownloadSources=true
(assuming there were not build failure notifications from CI server ;-)
). Also keep in the mind to use SNAPSHOTS (as suggested in the other
email).
> 2) If a module owner dependent on a.jar fails to update the version of
> the a.jar in the pom.xml and/or miss to commit the updated pom.xml
> with a contemporary version of a.jar. Continuous Integration at
> Continuum would suffer( assuming that even with not up to date version
> of a.jar the module still gets through build),
>
Continuous integration would show red flags if there were incompatible
changes checked in. To a good extent this also depends on the tests that
the developers have in place for each module.
> Pardon me for any wrong assumptions, I do not have much exposure to the process.
>
> Regards,
> Amit
>
>
HTH,
Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org