You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Zac Thompson <za...@gmail.com> on 2009/04/03 22:16:08 UTC
Maven 2.0 project versions, dependency versions, and perpetual
releasing
I also posted this question on stackoverflow, but I wanted to go "to
the source", as it were.
How should we manage the project and dependency versions in our POM
hierarchy? I apologize for the length of the message. The first
paragraph is probably all that's needed, but I'm not good at
self-editing and I wanted to give as much context as possible.
Scenario: The system has number of components, each with its own POM.
There are some long dependency chains (A depends on B depends on C,
etc.). I want each "non-developer-desktop" build to be a potential
release candidate -- if it passes QA, we will deploy it without
rebuilding. In other words, I never want to build SNAPSHOT versions as
part of my regularly scheduled builds, only versions like 1.3.0.5,
1.3.0.6, etc. I also want to enable the developers to work on multiple
components at once.
To forestall some expected suggestions: the Maven Release Plugin
doesn't help me ... unless there's some magic way I can have my
dependency versions not be SNAPSHOTs in the POMs but still let the
developers work on more than one component at once?
How should we manage the project and dependency versions in all of our
POMs? Right now it's just SNAPSHOTs everywhere, which makes things
simple for the developers (they started with SNAPSHOTs and never
concerned themselves with anything else). But it's worrying at
deployment time (builds with SNAPSHOT dependencies are not
well-defined, and not reproducible).
I'd like to avoid excessive version juggling at build time, but right
now I don't see any way around it.
Let's say I have components util, libj, libk, APP, and UI, with
dependencies as follows:
libj -> util (libj depends on util)
libk -> util
APP -> libj
UI -> libj, libk
I have development teams working on APP and UI, and they will
sometimes need to make changes/additions to some of the dependencies
(even util) in order to enable their current work. How should the
checked-in POM and dependency versions for each component look?
I'm prepared to hear that I may be taking the wrong approach to this
problem. All suggestions welcome.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Maven 2.0 project versions, dependency versions, and perpetual releasing
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>Also have a look at versions-maven-plugin
That's what I meant earlier, not dependency-maven-plugin. I haven't
personally used it yet, but I've shown it to several clients / trainees
and it's worked well for them in this case.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven 2.0 project versions, dependency versions, and perpetual
releasing
Posted by Stephen Connolly <st...@gmail.com>.
Also have a look at versions-maven-plugin
I use properties to define outside of reactor version... then if I build a
different project I do a local install of that project and then
mvn versions:update-properties -DallowSnapshots=true
which updates my properties to the latest version visble to me
at release time I release each project and do
mvn versions:update-properties
which will pick up the latest release versions
-Stephen
2009/4/4 Brian E. Fox <br...@reply.infinity.nu>
> Forget about LATEST and RELEASE, these are not reproducible down the road.
>
> The way I like to manage my dependencies is that they stay using the
> release version until a change to it that I need occurs. Then that
> dependency is changed to use the new snapshot. Hopefully you are using
> properties or dependencyManagement to reduce the number of places this needs
> to be changed to 1 per product group of modules. Then when it's time to
> release you know all the other things you must release because they are set
> as snapshots.
>
> -----Original Message-----
> From: Zac Thompson [mailto:zac.thompson@gmail.com]
> Sent: Friday, April 03, 2009 8:43 PM
> To: Maven Users List
> Subject: Re: Maven 2.0 project versions, dependency versions, and perpetual
> releasing
>
> I am willing to continue using snapshots during the dev cycle. I
> don't seek to eliminate them completely, but they are getting in my
> way. It's not SNAPSHOT versions of the projects themselves that is
> the obstacle, but SNAPSHOT dependencies.
>
> My challenge is that the dev cycle for a slice of the system could be
> extremely short (say, two hours), at which time I might need to update
> the versions and the dependencies for a few poms as I build them in
> sequence, and then update the dependency versions in many other POMs
> (perhaps 20, even though they may not be modified yet) in order to
> facilitate future development.
>
> As an example, let's say a developer changes a component, but also
> updates a shared utility library as part of the work. There's no
> problem with the checked-in component and library poms being
> SNAPSHOTs, but I have only four options for the dependency version:
>
> 1) component depends on SNAPSHOT dependency. Easy for the developer
> to work with and test, impossible for me to manage. This is where we
> are now.
>
> 2) component depends on specific release version of library: Feels the
> most authentic and "proper", but then Dev has to wait for a release
> build of the library and an update to the component POM for the new
> dependency version in order to use it for the component work. Also, I
> have to update all the other POMs that depend on the library.
>
> 3) component depends on virtual "RELEASE" version of library (or
> version range if supported and more appropriate). This is a lot like
> #1, but I won't have to update the component POMs when I build a new
> library. But it worsens build reproducibility, and the Dev still has
> to wait for an "official" library build in order to try out their
> changes to the component. This is a troublesome bottleneck for both
> #2 and #3 -- our split is just not that perfect that we can modify
> each piece in isolation. They need a way to use the new library they
> just built on their desktop while developing the component. They
> could update the component pom to depend on the snapshot of the
> library (temporarily back to #1), but then we risk them checking in
> that snapshot dependency, which will mess up any other devs on the
> same component. I'd like them to be able to avoid updating POMs
> unless there's a meaningful change to our dependency tree.
>
> 4) component depends on "LATEST" library. This allows the developer
> to work with the latest release until they start development, and then
> they'll find their self-built SNAPSHOTs. I also don't have to update
> lots of poms with every library build. This is close to #1, but at
> least I can be fairly sure that there will be no SNAPSHOT versions
> found by my scheduled builds. I can dimly see risks surrounding
> timing issues if they build a SNAPSHOT from an old checkout after my
> release build, but I can't fix everything.
>
> Any thoughts? #4 looks the best to me at the moment, but I haven't
> tried it yet. Still trying to wrap my head around it.
>
> Zac
>
> On Fri, Apr 3, 2009 at 3:49 PM, Brian E. Fox <br...@reply.infinity.nu>
> wrote:
> > Use snapshots during your dev cycle and publish your
> > non-developer-desktop builds as official releases. There is the
> > dependency-maven-plugin that can ease the updates of cross dependencies,
> > but if you structure your build tree effectively, this will be minimal.
> > You're on the right track, but don't throw out the notion of snapshots
> > just to avoid ever changing the poms.
> >
> > -----Original Message-----
> > From: Zac Thompson [mailto:zac.thompson@gmail.com]
> > Sent: Friday, April 03, 2009 4:16 PM
> > To: users@maven.apache.org
> > Subject: Maven 2.0 project versions, dependency versions, and perpetual
> > releasing
> >
> > I also posted this question on stackoverflow, but I wanted to go "to
> > the source", as it were.
> >
> > How should we manage the project and dependency versions in our POM
> > hierarchy? I apologize for the length of the message. The first
> > paragraph is probably all that's needed, but I'm not good at
> > self-editing and I wanted to give as much context as possible.
> >
> > Scenario: The system has number of components, each with its own POM.
> > There are some long dependency chains (A depends on B depends on C,
> > etc.). I want each "non-developer-desktop" build to be a potential
> > release candidate -- if it passes QA, we will deploy it without
> > rebuilding. In other words, I never want to build SNAPSHOT versions as
> > part of my regularly scheduled builds, only versions like 1.3.0.5,
> > 1.3.0.6, etc. I also want to enable the developers to work on multiple
> > components at once.
> >
> > To forestall some expected suggestions: the Maven Release Plugin
> > doesn't help me ... unless there's some magic way I can have my
> > dependency versions not be SNAPSHOTs in the POMs but still let the
> > developers work on more than one component at once?
> >
> > How should we manage the project and dependency versions in all of our
> > POMs? Right now it's just SNAPSHOTs everywhere, which makes things
> > simple for the developers (they started with SNAPSHOTs and never
> > concerned themselves with anything else). But it's worrying at
> > deployment time (builds with SNAPSHOT dependencies are not
> > well-defined, and not reproducible).
> >
> > I'd like to avoid excessive version juggling at build time, but right
> > now I don't see any way around it.
> >
> > Let's say I have components util, libj, libk, APP, and UI, with
> > dependencies as follows:
> > libj -> util (libj depends on util)
> > libk -> util
> > APP -> libj
> > UI -> libj, libk
> >
> > I have development teams working on APP and UI, and they will
> > sometimes need to make changes/additions to some of the dependencies
> > (even util) in order to enable their current work. How should the
> > checked-in POM and dependency versions for each component look?
> >
> > I'm prepared to hear that I may be taking the wrong approach to this
> > problem. All suggestions welcome.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: Maven 2.0 project versions, dependency versions, and perpetual releasing
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Forget about LATEST and RELEASE, these are not reproducible down the road.
The way I like to manage my dependencies is that they stay using the release version until a change to it that I need occurs. Then that dependency is changed to use the new snapshot. Hopefully you are using properties or dependencyManagement to reduce the number of places this needs to be changed to 1 per product group of modules. Then when it's time to release you know all the other things you must release because they are set as snapshots.
-----Original Message-----
From: Zac Thompson [mailto:zac.thompson@gmail.com]
Sent: Friday, April 03, 2009 8:43 PM
To: Maven Users List
Subject: Re: Maven 2.0 project versions, dependency versions, and perpetual releasing
I am willing to continue using snapshots during the dev cycle. I
don't seek to eliminate them completely, but they are getting in my
way. It's not SNAPSHOT versions of the projects themselves that is
the obstacle, but SNAPSHOT dependencies.
My challenge is that the dev cycle for a slice of the system could be
extremely short (say, two hours), at which time I might need to update
the versions and the dependencies for a few poms as I build them in
sequence, and then update the dependency versions in many other POMs
(perhaps 20, even though they may not be modified yet) in order to
facilitate future development.
As an example, let's say a developer changes a component, but also
updates a shared utility library as part of the work. There's no
problem with the checked-in component and library poms being
SNAPSHOTs, but I have only four options for the dependency version:
1) component depends on SNAPSHOT dependency. Easy for the developer
to work with and test, impossible for me to manage. This is where we
are now.
2) component depends on specific release version of library: Feels the
most authentic and "proper", but then Dev has to wait for a release
build of the library and an update to the component POM for the new
dependency version in order to use it for the component work. Also, I
have to update all the other POMs that depend on the library.
3) component depends on virtual "RELEASE" version of library (or
version range if supported and more appropriate). This is a lot like
#1, but I won't have to update the component POMs when I build a new
library. But it worsens build reproducibility, and the Dev still has
to wait for an "official" library build in order to try out their
changes to the component. This is a troublesome bottleneck for both
#2 and #3 -- our split is just not that perfect that we can modify
each piece in isolation. They need a way to use the new library they
just built on their desktop while developing the component. They
could update the component pom to depend on the snapshot of the
library (temporarily back to #1), but then we risk them checking in
that snapshot dependency, which will mess up any other devs on the
same component. I'd like them to be able to avoid updating POMs
unless there's a meaningful change to our dependency tree.
4) component depends on "LATEST" library. This allows the developer
to work with the latest release until they start development, and then
they'll find their self-built SNAPSHOTs. I also don't have to update
lots of poms with every library build. This is close to #1, but at
least I can be fairly sure that there will be no SNAPSHOT versions
found by my scheduled builds. I can dimly see risks surrounding
timing issues if they build a SNAPSHOT from an old checkout after my
release build, but I can't fix everything.
Any thoughts? #4 looks the best to me at the moment, but I haven't
tried it yet. Still trying to wrap my head around it.
Zac
On Fri, Apr 3, 2009 at 3:49 PM, Brian E. Fox <br...@reply.infinity.nu> wrote:
> Use snapshots during your dev cycle and publish your
> non-developer-desktop builds as official releases. There is the
> dependency-maven-plugin that can ease the updates of cross dependencies,
> but if you structure your build tree effectively, this will be minimal.
> You're on the right track, but don't throw out the notion of snapshots
> just to avoid ever changing the poms.
>
> -----Original Message-----
> From: Zac Thompson [mailto:zac.thompson@gmail.com]
> Sent: Friday, April 03, 2009 4:16 PM
> To: users@maven.apache.org
> Subject: Maven 2.0 project versions, dependency versions, and perpetual
> releasing
>
> I also posted this question on stackoverflow, but I wanted to go "to
> the source", as it were.
>
> How should we manage the project and dependency versions in our POM
> hierarchy? I apologize for the length of the message. The first
> paragraph is probably all that's needed, but I'm not good at
> self-editing and I wanted to give as much context as possible.
>
> Scenario: The system has number of components, each with its own POM.
> There are some long dependency chains (A depends on B depends on C,
> etc.). I want each "non-developer-desktop" build to be a potential
> release candidate -- if it passes QA, we will deploy it without
> rebuilding. In other words, I never want to build SNAPSHOT versions as
> part of my regularly scheduled builds, only versions like 1.3.0.5,
> 1.3.0.6, etc. I also want to enable the developers to work on multiple
> components at once.
>
> To forestall some expected suggestions: the Maven Release Plugin
> doesn't help me ... unless there's some magic way I can have my
> dependency versions not be SNAPSHOTs in the POMs but still let the
> developers work on more than one component at once?
>
> How should we manage the project and dependency versions in all of our
> POMs? Right now it's just SNAPSHOTs everywhere, which makes things
> simple for the developers (they started with SNAPSHOTs and never
> concerned themselves with anything else). But it's worrying at
> deployment time (builds with SNAPSHOT dependencies are not
> well-defined, and not reproducible).
>
> I'd like to avoid excessive version juggling at build time, but right
> now I don't see any way around it.
>
> Let's say I have components util, libj, libk, APP, and UI, with
> dependencies as follows:
> libj -> util (libj depends on util)
> libk -> util
> APP -> libj
> UI -> libj, libk
>
> I have development teams working on APP and UI, and they will
> sometimes need to make changes/additions to some of the dependencies
> (even util) in order to enable their current work. How should the
> checked-in POM and dependency versions for each component look?
>
> I'm prepared to hear that I may be taking the wrong approach to this
> problem. All suggestions welcome.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven 2.0 project versions, dependency versions, and perpetual
releasing
Posted by Zac Thompson <za...@gmail.com>.
I am willing to continue using snapshots during the dev cycle. I
don't seek to eliminate them completely, but they are getting in my
way. It's not SNAPSHOT versions of the projects themselves that is
the obstacle, but SNAPSHOT dependencies.
My challenge is that the dev cycle for a slice of the system could be
extremely short (say, two hours), at which time I might need to update
the versions and the dependencies for a few poms as I build them in
sequence, and then update the dependency versions in many other POMs
(perhaps 20, even though they may not be modified yet) in order to
facilitate future development.
As an example, let's say a developer changes a component, but also
updates a shared utility library as part of the work. There's no
problem with the checked-in component and library poms being
SNAPSHOTs, but I have only four options for the dependency version:
1) component depends on SNAPSHOT dependency. Easy for the developer
to work with and test, impossible for me to manage. This is where we
are now.
2) component depends on specific release version of library: Feels the
most authentic and "proper", but then Dev has to wait for a release
build of the library and an update to the component POM for the new
dependency version in order to use it for the component work. Also, I
have to update all the other POMs that depend on the library.
3) component depends on virtual "RELEASE" version of library (or
version range if supported and more appropriate). This is a lot like
#1, but I won't have to update the component POMs when I build a new
library. But it worsens build reproducibility, and the Dev still has
to wait for an "official" library build in order to try out their
changes to the component. This is a troublesome bottleneck for both
#2 and #3 -- our split is just not that perfect that we can modify
each piece in isolation. They need a way to use the new library they
just built on their desktop while developing the component. They
could update the component pom to depend on the snapshot of the
library (temporarily back to #1), but then we risk them checking in
that snapshot dependency, which will mess up any other devs on the
same component. I'd like them to be able to avoid updating POMs
unless there's a meaningful change to our dependency tree.
4) component depends on "LATEST" library. This allows the developer
to work with the latest release until they start development, and then
they'll find their self-built SNAPSHOTs. I also don't have to update
lots of poms with every library build. This is close to #1, but at
least I can be fairly sure that there will be no SNAPSHOT versions
found by my scheduled builds. I can dimly see risks surrounding
timing issues if they build a SNAPSHOT from an old checkout after my
release build, but I can't fix everything.
Any thoughts? #4 looks the best to me at the moment, but I haven't
tried it yet. Still trying to wrap my head around it.
Zac
On Fri, Apr 3, 2009 at 3:49 PM, Brian E. Fox <br...@reply.infinity.nu> wrote:
> Use snapshots during your dev cycle and publish your
> non-developer-desktop builds as official releases. There is the
> dependency-maven-plugin that can ease the updates of cross dependencies,
> but if you structure your build tree effectively, this will be minimal.
> You're on the right track, but don't throw out the notion of snapshots
> just to avoid ever changing the poms.
>
> -----Original Message-----
> From: Zac Thompson [mailto:zac.thompson@gmail.com]
> Sent: Friday, April 03, 2009 4:16 PM
> To: users@maven.apache.org
> Subject: Maven 2.0 project versions, dependency versions, and perpetual
> releasing
>
> I also posted this question on stackoverflow, but I wanted to go "to
> the source", as it were.
>
> How should we manage the project and dependency versions in our POM
> hierarchy? I apologize for the length of the message. The first
> paragraph is probably all that's needed, but I'm not good at
> self-editing and I wanted to give as much context as possible.
>
> Scenario: The system has number of components, each with its own POM.
> There are some long dependency chains (A depends on B depends on C,
> etc.). I want each "non-developer-desktop" build to be a potential
> release candidate -- if it passes QA, we will deploy it without
> rebuilding. In other words, I never want to build SNAPSHOT versions as
> part of my regularly scheduled builds, only versions like 1.3.0.5,
> 1.3.0.6, etc. I also want to enable the developers to work on multiple
> components at once.
>
> To forestall some expected suggestions: the Maven Release Plugin
> doesn't help me ... unless there's some magic way I can have my
> dependency versions not be SNAPSHOTs in the POMs but still let the
> developers work on more than one component at once?
>
> How should we manage the project and dependency versions in all of our
> POMs? Right now it's just SNAPSHOTs everywhere, which makes things
> simple for the developers (they started with SNAPSHOTs and never
> concerned themselves with anything else). But it's worrying at
> deployment time (builds with SNAPSHOT dependencies are not
> well-defined, and not reproducible).
>
> I'd like to avoid excessive version juggling at build time, but right
> now I don't see any way around it.
>
> Let's say I have components util, libj, libk, APP, and UI, with
> dependencies as follows:
> libj -> util (libj depends on util)
> libk -> util
> APP -> libj
> UI -> libj, libk
>
> I have development teams working on APP and UI, and they will
> sometimes need to make changes/additions to some of the dependencies
> (even util) in order to enable their current work. How should the
> checked-in POM and dependency versions for each component look?
>
> I'm prepared to hear that I may be taking the wrong approach to this
> problem. All suggestions welcome.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Maven 2.0 project versions, dependency versions, and perpetual releasing
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Use snapshots during your dev cycle and publish your
non-developer-desktop builds as official releases. There is the
dependency-maven-plugin that can ease the updates of cross dependencies,
but if you structure your build tree effectively, this will be minimal.
You're on the right track, but don't throw out the notion of snapshots
just to avoid ever changing the poms.
-----Original Message-----
From: Zac Thompson [mailto:zac.thompson@gmail.com]
Sent: Friday, April 03, 2009 4:16 PM
To: users@maven.apache.org
Subject: Maven 2.0 project versions, dependency versions, and perpetual
releasing
I also posted this question on stackoverflow, but I wanted to go "to
the source", as it were.
How should we manage the project and dependency versions in our POM
hierarchy? I apologize for the length of the message. The first
paragraph is probably all that's needed, but I'm not good at
self-editing and I wanted to give as much context as possible.
Scenario: The system has number of components, each with its own POM.
There are some long dependency chains (A depends on B depends on C,
etc.). I want each "non-developer-desktop" build to be a potential
release candidate -- if it passes QA, we will deploy it without
rebuilding. In other words, I never want to build SNAPSHOT versions as
part of my regularly scheduled builds, only versions like 1.3.0.5,
1.3.0.6, etc. I also want to enable the developers to work on multiple
components at once.
To forestall some expected suggestions: the Maven Release Plugin
doesn't help me ... unless there's some magic way I can have my
dependency versions not be SNAPSHOTs in the POMs but still let the
developers work on more than one component at once?
How should we manage the project and dependency versions in all of our
POMs? Right now it's just SNAPSHOTs everywhere, which makes things
simple for the developers (they started with SNAPSHOTs and never
concerned themselves with anything else). But it's worrying at
deployment time (builds with SNAPSHOT dependencies are not
well-defined, and not reproducible).
I'd like to avoid excessive version juggling at build time, but right
now I don't see any way around it.
Let's say I have components util, libj, libk, APP, and UI, with
dependencies as follows:
libj -> util (libj depends on util)
libk -> util
APP -> libj
UI -> libj, libk
I have development teams working on APP and UI, and they will
sometimes need to make changes/additions to some of the dependencies
(even util) in order to enable their current work. How should the
checked-in POM and dependency versions for each component look?
I'm prepared to hear that I may be taking the wrong approach to this
problem. All suggestions welcome.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org