You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Guillaume Lederrey <gu...@gmail.com> on 2008/01/07 17:34:31 UTC
Dependency versions in large multi-projects multi-modules environment
Hello !
I have to investigate the migration to Maven in our organisation. We
have a pretty large software base : about 100 projects each generating
3 to 6 artifacts. A part of these modules are a framework used by most
other projects.
For the moment, we are managing versioning with ant, and a script that
download the latest version of each library. This script is updated
every time a new version of a library is released. The script itself
is on a server and accessed by all developers / build tools.
I see to major ways to do the same with Maven :
1) replace our script by a parent pom which will contain all
dependencies and versions in its <dependencyManagement/> section. This
means that every time a new library is released, a new version of this
parent pom has to be released as well. And all other projects have to
update their reference to the latest parent pom.
2) use version ranges in the parent pom. This way, the new version of
the library is used by all projects as soon as it is available in our
central repository. Much easier to manage, but it sound a bit scary to
have it that much automated ... Other problem, we will loose build
reproducibility ...
I'll be happy to know how you manage dependency versions in large
organizations ...
Thanks a lot !
Guillaume
--
Jabber : gehel@amessage.ch
Skype : Guillaume.Lederrey
Projects :
* http://rwanda.wordpress.com/
* http://rwandatech.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependency versions in large multi-projects multi-modules environment
Posted by Guillaume Lederrey <gu...@gmail.com>.
I'm afraid that solution #1 will be hard to scale ... We have releases
almost every day. Updating every other project every day doesnt seems
to be such a good idea either ...
But thanks for your feedback !
On 07/01/2008, Barrett Nuzum <Ba...@valtech.com> wrote:
> Guillaume:
>
> At one of our clients, we had a very similar situation.
> We opted to go with option #1, below.
>
> It *is* a bit of a maintenance burden, but it's far more reliable and explicit than any alternatives.
>
> Barrett
>
> ::
> Barrett Nuzum
> Sr. Consultant
> Direct: 918.640.4414
> Fax: 972.789.1340
>
> Valtech Technologies, Inc.
> 5080 Spectrum Drive
> Suite 700 West
> Addison, Texas 75001
> www.valtech.us <http://www.valtech.us/>
> Delivering Business Agility
>
>
> ________________________________
>
> From: Guillaume Lederrey [mailto:guillaume.lederrey@gmail.com]
> Sent: Mon 1/7/2008 10:34 AM
> To: Maven Users List
> Subject: Dependency versions in large multi-projects multi-modules environment
>
>
>
> Hello !
>
> I have to investigate the migration to Maven in our organisation. We
> have a pretty large software base : about 100 projects each generating
> 3 to 6 artifacts. A part of these modules are a framework used by most
> other projects.
>
> For the moment, we are managing versioning with ant, and a script that
> download the latest version of each library. This script is updated
> every time a new version of a library is released. The script itself
> is on a server and accessed by all developers / build tools.
>
> I see to major ways to do the same with Maven :
>
> 1) replace our script by a parent pom which will contain all
> dependencies and versions in its <dependencyManagement/> section. This
> means that every time a new library is released, a new version of this
> parent pom has to be released as well. And all other projects have to
> update their reference to the latest parent pom.
>
> 2) use version ranges in the parent pom. This way, the new version of
> the library is used by all projects as soon as it is available in our
> central repository. Much easier to manage, but it sound a bit scary to
> have it that much automated ... Other problem, we will loose build
> reproducibility ...
>
> I'll be happy to know how you manage dependency versions in large
> organizations ...
>
> Thanks a lot !
>
> Guillaume
>
>
> --
> Jabber : gehel@amessage.ch
> Skype : Guillaume.Lederrey
> Projects :
> * http://rwanda.wordpress.com/
> * http://rwandatech.wordpress.com/
>
> ---------------------------------------------------------------------
> 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
>
>
--
Jabber : gehel@amessage.ch
Skype : Guillaume.Lederrey
Projects :
* http://rwanda.wordpress.com/
* http://rwandatech.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Dependency versions in large multi-projects multi-modules environment
Posted by Barrett Nuzum <Ba...@Valtech.com>.
Guillaume:
At one of our clients, we had a very similar situation.
We opted to go with option #1, below.
It *is* a bit of a maintenance burden, but it's far more reliable and explicit than any alternatives.
Barrett
::
Barrett Nuzum
Sr. Consultant
Direct: 918.640.4414
Fax: 972.789.1340
Valtech Technologies, Inc.
5080 Spectrum Drive
Suite 700 West
Addison, Texas 75001
www.valtech.us <http://www.valtech.us/>
Delivering Business Agility
________________________________
From: Guillaume Lederrey [mailto:guillaume.lederrey@gmail.com]
Sent: Mon 1/7/2008 10:34 AM
To: Maven Users List
Subject: Dependency versions in large multi-projects multi-modules environment
Hello !
I have to investigate the migration to Maven in our organisation. We
have a pretty large software base : about 100 projects each generating
3 to 6 artifacts. A part of these modules are a framework used by most
other projects.
For the moment, we are managing versioning with ant, and a script that
download the latest version of each library. This script is updated
every time a new version of a library is released. The script itself
is on a server and accessed by all developers / build tools.
I see to major ways to do the same with Maven :
1) replace our script by a parent pom which will contain all
dependencies and versions in its <dependencyManagement/> section. This
means that every time a new library is released, a new version of this
parent pom has to be released as well. And all other projects have to
update their reference to the latest parent pom.
2) use version ranges in the parent pom. This way, the new version of
the library is used by all projects as soon as it is available in our
central repository. Much easier to manage, but it sound a bit scary to
have it that much automated ... Other problem, we will loose build
reproducibility ...
I'll be happy to know how you manage dependency versions in large
organizations ...
Thanks a lot !
Guillaume
--
Jabber : gehel@amessage.ch
Skype : Guillaume.Lederrey
Projects :
* http://rwanda.wordpress.com/
* http://rwandatech.wordpress.com/
---------------------------------------------------------------------
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: Dependency versions in large multi-projects multi-modules environment
Posted by Guillaume Lederrey <gu...@gmail.com>.
Thanks for your answer !
I have read some documentation on using dependency range, but I havent
used it in any real world project yet. The documentation I have found
sometimes makes me think this is a work still in progress. As you seem
to be using it in real world projects, could you please share a bit of
your experience ? Especially the following points :
* build reproducibility : do you find it easy to work on old branches
(already released) to patch them ? how much work on the part of the
developer to work against the dependency set that was used at release
time ?
* do you have any problem with non monotonic version numbers ? For
example, we release version 1.2.3 in production. We are now working on
version 1.3.1, which might have been released in test. Bug report
comes against version 1.2.3, we now have to release version 1.2.4 in
production. Does this poses problem with version ranges ?
* Is the version syntax sufficiently robust ? For example, most of our
projects use a 3 or 4 number version (1.2.3 or 1.2.3.4). Some projects
(usually the release "super-packages" that aggregate many other
projects) have a 2 number version (like 802.1 for the first release in
february 2008).
* do you have any problem with automatically jumping to the last
release of a lib ? Isnt it not enough control, too much automation ?
On the overall, I'm quite interested in the version range feature, but
I'd like to have more feedback before recommending that kind of
approach in production ...
Thanks a lot for your help !
Guillaume
On 07/01/2008, Damien Lecan <ml...@dlecan.com> wrote:
> > 2) use version ranges in the parent pom. This way, the new version of
> > the library is used by all projects as soon as it is available in our
> > central repository. Much easier to manage, but it sound a bit scary to
> > have it that much automated ... Other problem, we will loose build
> > reproducibility ...
> >
> > I'll be happy to know how you manage dependency versions in large
> > organizations ...
>
> As you describe for my project ((900+ modules).
> Parent version is defined for each projets and parent project defines
> version range dependencies.
>
> According to this :
> http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Reproducibility
> version ranges are removed when release is done to preserve reproductibility.
>
> Damien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Jabber : gehel@amessage.ch
Skype : Guillaume.Lederrey
Projects :
* http://rwanda.wordpress.com/
* http://rwandatech.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependency versions in large multi-projects multi-modules environment
Posted by Damien Lecan <ml...@dlecan.com>.
> 2) use version ranges in the parent pom. This way, the new version of
> the library is used by all projects as soon as it is available in our
> central repository. Much easier to manage, but it sound a bit scary to
> have it that much automated ... Other problem, we will loose build
> reproducibility ...
>
> I'll be happy to know how you manage dependency versions in large
> organizations ...
As you describe for my project ((900+ modules).
Parent version is defined for each projets and parent project defines
version range dependencies.
According to this :
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Reproducibility
version ranges are removed when release is done to preserve reproductibility.
Damien
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependency versions in large multi-projects multi-modules environment
Posted by Guillaume Lederrey <gu...@gmail.com>.
On 09/01/2008, simon <si...@chello.at> wrote:
>
> On Wed, 2008-01-09 at 14:23 +0100, Guillaume Lederrey wrote:
> > Thanks a lot for all the feedback !
> >
> > I am still not completely convinced ... see below.
> >
> > On 09/01/2008, Beelen, M. - SPLXL <Ma...@klm.com> wrote:
> > > Ïn my opition the cycle you mention where the snake bites it's tail" can only be a real problem is you actually do have circular dependencies, which often isn't the case.
> > > I assume that although you have inter-dependencies in your libraries those dependencies are not circular.
> >
> > Actually, we do have quite a few circular dependencies (old project,
> > legacy code, we wont clean everything anytime soon). We have to live
> > with them ;-(
>
> If you really have odd dependency structures, then Maven might not be
> right for you. Maven has a clear idea of what "best practice" is, and is
> not infinitely configurable. The infinitely-configurable build tool is
> called Ant.
Yep, I know that ... ;-) But the decision to migrate to Maven has
been taken higher up, and now we have to move along ... It might be
painful, but we dont have that much choice on the matter ...
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Jabber : gehel@amessage.ch
Skype : Guillaume.Lederrey
Projects :
* http://rwanda.wordpress.com/
* http://rwandatech.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependency versions in large multi-projects multi-modules
environment
Posted by simon <si...@chello.at>.
On Wed, 2008-01-09 at 14:23 +0100, Guillaume Lederrey wrote:
> Thanks a lot for all the feedback !
>
> I am still not completely convinced ... see below.
>
> On 09/01/2008, Beelen, M. - SPLXL <Ma...@klm.com> wrote:
> > Ïn my opition the cycle you mention where the snake bites it's tail" can only be a real problem is you actually do have circular dependencies, which often isn't the case.
> > I assume that although you have inter-dependencies in your libraries those dependencies are not circular.
>
> Actually, we do have quite a few circular dependencies (old project,
> legacy code, we wont clean everything anytime soon). We have to live
> with them ;-(
If you really have odd dependency structures, then Maven might not be
right for you. Maven has a clear idea of what "best practice" is, and is
not infinitely configurable. The infinitely-configurable build tool is
called Ant.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependency versions in large multi-projects multi-modules environment
Posted by Guillaume Lederrey <gu...@gmail.com>.
Thanks a lot for all the feedback !
I am still not completely convinced ... see below.
On 09/01/2008, Beelen, M. - SPLXL <Ma...@klm.com> wrote:
> Ïn my opition the cycle you mention where the snake bites it's tail" can only be a real problem is you actually do have circular dependencies, which often isn't the case.
> I assume that although you have inter-dependencies in your libraries those dependencies are not circular.
Actually, we do have quite a few circular dependencies (old project,
legacy code, we wont clean everything anytime soon). We have to live
with them ;-(
> My suggestion would be to split the libraries parent pom along the hierachy of your libraries
>
> - Corporare
> -- Framework
> -- General Libraries parent
> --- Core Library A (without dependancies on your other libraries)
> ---- Module 1
> ---- Module 2
> --- Core Library B (without dependancies on your other libraries)
> ---- Module 1
> ---- Module 2
> --- Parent for 2nd level projects (includes versions of your core libraries A&B)
> ---- Library C pom
> ----- Module 1
> ----- Module 2
> ---- Library D pom
> ----- Module 1
> ----- Module 2
I think I will need to lay down a full dependency graph of my
libraries and see if there is any way to split them in subprojects.
But I somehow doubt it - we'll see.
Maybe I should go back to the big picture, what we are actually trying
to achieve ...
Splitting the version management in too many places is exactly what we
are trying to avoid. The reasons are more organizational than
technical (but important none the less). The versions of all libraries
have to be vetted by the "release manager". Once a version is released
and approved, it should be used by all projects and all libraries
depending on it. The release manager also needs to be able to go back
to an older version in case we have a regression.
So the version management has to be externalized from the projects /
libraries themselves. Every project can be responsible for its own
version number, but should not be responsible to manage the version of
its dependencies. Of course, in some special cases, a project has to
be able to override the "official" version number.
> I would not include any dependency in the dependencyManagement of a parent pom if that the depenency is itself a child module of that parent. It can be done, by aligning all your versionNumber and specify the versions of the dependencies in the dependancyManagement as ${pom.version}.
> Note: this would enforce all your libraries being on the same version all the times, which isn't very likely to be usefull.
That's exactly what I would like to do (include dependency version in
the parent dependencyManagement). But I would as well like to keep
different version numbers for the subprojects ... Lots of our
libraries are interdependent, and should be handled as a whole. At the
same time, they should be able to have different version numbers ...
Doesnt seem to be possible (and yes, I understand perfectly why).
> Bottom line is: You should not try to configure everything in one place if it isn't exactly for the same purpose.
>
> Hope this helps,
> Marco Beelen
>
>
>
>
> -----Original Message-----
> From: Guillaume Lederrey [mailto:guillaume.lederrey@gmail.com]
> Sent: Wednesday, January 09, 2008 11:57 AM
> To: Maven Users List
> Subject: Re: Dependency versions in large multi-projects multi-modules environment
>
> On 09/01/2008, nicklist@planet.nl <ni...@planet.nl> wrote:
> > > I have to investigate the migration to Maven in our organisation. We
> > > have a pretty large software base : about 100 projects each
> > > generating
> > > 3 to 6 artifacts. A part of these modules are a framework used by
> > > most other projects.
> >
> > On this basis I would start with three parent poms.
> > - On for the company, which would have normal dependencymanagement for common projects outside your company.
> > - On for the framework, which is a child of the company pom.
> > - On for the other libraries, which is also a child of the company pom and keeps references to the right framework libraries.
>
> That's more or less what I have in place for my tests. (Actually, it is a bit more complex, as we have 2 levels of framework).
>
> My problem is with our libraries.
> * We have a parent pom that references the versions of the framework (this pom is released by the team responsible for the framework).
> * We have a pom that references the versions of all libraries, its parent is the one above.
> * every library defines its own dependency, but no version. Its parent pom is the one above. So, overall I have :
>
> Company pom
> \-- Framework parent pom (defines all versions of the framework dependencies)
> \-- Libraries parent pom (defines all versions of the libraries)
> |-- Library 1 pom
> | |-- module 1
> | |-- module 2
> | \-- module 3
> |-- Library 2 pom
> | |-- module 1
> | |-- module 2
> | \-- module 3
> \-- Library 3 pom
> |-- module 1
> |-- module 2
> \-- module 3
>
> Libraries have interdependencies, so we want the libraries themselves to inherit from a parent pom that declares the versions. And that's where the snake bite its tail ...
>
> So, if I understand your solution right, it doesnt apply to our situation, because w cant just "side step" the dependency declaration .... Did I miss something again ?
>
>
>
> > Now it is a matter of releasing the framework with its superpom and after that updating the other superpom to reference the right libraries.
> >
> > Hth,
> >
> > Nick Stolwijk
> >
> > -----Original Message-----
> > From: Guillaume Lederrey [mailto:guillaume.lederrey@gmail.com]
> > Sent: Wed 1/9/2008 11:01 AM
> > To: Maven Users List
> > Subject: Re: Dependency versions in large multi-projects multi-modules
> > environment
> >
> > I'm trying to go down the path of option #1 below :
> >
> > * a super pom which define all dependencies, we can leave it in
> > SNAPSHOT state for the dev cycle
> > * all libraries reference this parent pom. The libraries can go
> > through a couple of version increments during the dev cycle.
> >
> > Now I have a problem at the time of release :
> >
> > I have to release a version of both the super pom and the libraries.
> > The parent pom has to be updated to reference the versions of the
> > libraries at release time, and the libraries have to be updated to
> > reference the super pom at release time. So I got a cycle ...
> >
> > If I release the libraries first, and then update the super pom, I
> > then have to release the super pom, and as the super pom has been
> > updated, I have to release the libraries as well and so on ...
> >
> > I think my requirements are pretty standard, so there should be an
> > obvious solution that I am missing. What didnt I understand ?
> >
> > Thanks for your help !
> >
> > MrG
> >
> > On 07/01/2008, Guillaume Lederrey <gu...@gmail.com> wrote:
> > > Hello !
> > >
> > > I have to investigate the migration to Maven in our organisation. We
> > > have a pretty large software base : about 100 projects each
> > > generating
> > > 3 to 6 artifacts. A part of these modules are a framework used by
> > > most other projects.
> > >
> > > For the moment, we are managing versioning with ant, and a script
> > > that download the latest version of each library. This script is
> > > updated every time a new version of a library is released. The
> > > script itself is on a server and accessed by all developers / build tools.
> > >
> > > I see to major ways to do the same with Maven :
> > >
> > > 1) replace our script by a parent pom which will contain all
> > > dependencies and versions in its <dependencyManagement/> section.
> > > This means that every time a new library is released, a new version
> > > of this parent pom has to be released as well. And all other
> > > projects have to update their reference to the latest parent pom.
> > >
> > > 2) use version ranges in the parent pom. This way, the new version
> > > of the library is used by all projects as soon as it is available in
> > > our central repository. Much easier to manage, but it sound a bit
> > > scary to have it that much automated ... Other problem, we will
> > > loose build reproducibility ...
> > >
> > > I'll be happy to know how you manage dependency versions in large
> > > organizations ...
> > >
> > > Thanks a lot !
> > >
> > > Guillaume
> > >
> > >
> > > --
> > > Jabber : gehel@amessage.ch
> > > Skype : Guillaume.Lederrey
> > > Projects :
> > > * http://rwanda.wordpress.com/
> > > * http://rwandatech.wordpress.com/
> > >
> >
> >
> > --
> > Jabber : gehel@amessage.ch
> > Skype : Guillaume.Lederrey
> > Projects :
> > * http://rwanda.wordpress.com/
> > * http://rwandatech.wordpress.com/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> >
>
>
> --
> Jabber : gehel@amessage.ch
> Skype : Guillaume.Lederrey
> Projects :
> * http://rwanda.wordpress.com/
> * http://rwandatech.wordpress.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
> **********************************************************************
> For information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee
> only. If you are not the addressee, you are notified that no part
> of the e-mail or any attachment may be disclosed, copied or
> distributed, and that any other action related to this e-mail or
> attachment is strictly prohibited, and may be unlawful. If you have
> received this e-mail by error, please notify the sender immediately
> by return e-mail, and delete this message.
>
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
> and/or its employees shall not be liable for the incorrect or
> incomplete transmission of this e-mail or any attachments, nor
> responsible for any delay in receipt.
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
> Dutch Airlines) is registered in Amstelveen, The Netherlands, with
> registered number 33014286
> **********************************************************************
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Jabber : gehel@amessage.ch
Skype : Guillaume.Lederrey
Projects :
* http://rwanda.wordpress.com/
* http://rwandatech.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Dependency versions in large multi-projects multi-modules environment
Posted by "Beelen, M. - SPLXL" <Ma...@klm.com>.
Hi,
First of all I agree with Nick and the path you have chosen already.
So using your framework isn't a problem anymore.
Ïn my opition the cycle you mention where the snake bites it's tail" can only be a real problem is you actually do have circular dependencies, which often isn't the case.
I assume that although you have inter-dependencies in your libraries those dependencies are not circular.
My suggestion would be to split the libraries parent pom along the hierachy of your libraries
- Corporare
-- Framework
-- General Libraries parent
--- Core Library A (without dependancies on your other libraries)
---- Module 1
---- Module 2
--- Core Library B (without dependancies on your other libraries)
---- Module 1
---- Module 2
--- Parent for 2nd level projects (includes versions of your core libraries A&B)
---- Library C pom
----- Module 1
----- Module 2
---- Library D pom
----- Module 1
----- Module 2
I would not include any dependency in the dependencyManagement of a parent pom if that the depenency is itself a child module of that parent. It can be done, by aligning all your versionNumber and specify the versions of the dependencies in the dependancyManagement as ${pom.version}.
Note: this would enforce all your libraries being on the same version all the times, which isn't very likely to be usefull.
Bottom line is: You should not try to configure everything in one place if it isn't exactly for the same purpose.
Hope this helps,
Marco Beelen
-----Original Message-----
From: Guillaume Lederrey [mailto:guillaume.lederrey@gmail.com]
Sent: Wednesday, January 09, 2008 11:57 AM
To: Maven Users List
Subject: Re: Dependency versions in large multi-projects multi-modules environment
On 09/01/2008, nicklist@planet.nl <ni...@planet.nl> wrote:
> > I have to investigate the migration to Maven in our organisation. We
> > have a pretty large software base : about 100 projects each
> > generating
> > 3 to 6 artifacts. A part of these modules are a framework used by
> > most other projects.
>
> On this basis I would start with three parent poms.
> - On for the company, which would have normal dependencymanagement for common projects outside your company.
> - On for the framework, which is a child of the company pom.
> - On for the other libraries, which is also a child of the company pom and keeps references to the right framework libraries.
That's more or less what I have in place for my tests. (Actually, it is a bit more complex, as we have 2 levels of framework).
My problem is with our libraries.
* We have a parent pom that references the versions of the framework (this pom is released by the team responsible for the framework).
* We have a pom that references the versions of all libraries, its parent is the one above.
* every library defines its own dependency, but no version. Its parent pom is the one above. So, overall I have :
Company pom
\-- Framework parent pom (defines all versions of the framework dependencies)
\-- Libraries parent pom (defines all versions of the libraries)
|-- Library 1 pom
| |-- module 1
| |-- module 2
| \-- module 3
|-- Library 2 pom
| |-- module 1
| |-- module 2
| \-- module 3
\-- Library 3 pom
|-- module 1
|-- module 2
\-- module 3
Libraries have interdependencies, so we want the libraries themselves to inherit from a parent pom that declares the versions. And that's where the snake bite its tail ...
So, if I understand your solution right, it doesnt apply to our situation, because w cant just "side step" the dependency declaration .... Did I miss something again ?
> Now it is a matter of releasing the framework with its superpom and after that updating the other superpom to reference the right libraries.
>
> Hth,
>
> Nick Stolwijk
>
> -----Original Message-----
> From: Guillaume Lederrey [mailto:guillaume.lederrey@gmail.com]
> Sent: Wed 1/9/2008 11:01 AM
> To: Maven Users List
> Subject: Re: Dependency versions in large multi-projects multi-modules
> environment
>
> I'm trying to go down the path of option #1 below :
>
> * a super pom which define all dependencies, we can leave it in
> SNAPSHOT state for the dev cycle
> * all libraries reference this parent pom. The libraries can go
> through a couple of version increments during the dev cycle.
>
> Now I have a problem at the time of release :
>
> I have to release a version of both the super pom and the libraries.
> The parent pom has to be updated to reference the versions of the
> libraries at release time, and the libraries have to be updated to
> reference the super pom at release time. So I got a cycle ...
>
> If I release the libraries first, and then update the super pom, I
> then have to release the super pom, and as the super pom has been
> updated, I have to release the libraries as well and so on ...
>
> I think my requirements are pretty standard, so there should be an
> obvious solution that I am missing. What didnt I understand ?
>
> Thanks for your help !
>
> MrG
>
> On 07/01/2008, Guillaume Lederrey <gu...@gmail.com> wrote:
> > Hello !
> >
> > I have to investigate the migration to Maven in our organisation. We
> > have a pretty large software base : about 100 projects each
> > generating
> > 3 to 6 artifacts. A part of these modules are a framework used by
> > most other projects.
> >
> > For the moment, we are managing versioning with ant, and a script
> > that download the latest version of each library. This script is
> > updated every time a new version of a library is released. The
> > script itself is on a server and accessed by all developers / build tools.
> >
> > I see to major ways to do the same with Maven :
> >
> > 1) replace our script by a parent pom which will contain all
> > dependencies and versions in its <dependencyManagement/> section.
> > This means that every time a new library is released, a new version
> > of this parent pom has to be released as well. And all other
> > projects have to update their reference to the latest parent pom.
> >
> > 2) use version ranges in the parent pom. This way, the new version
> > of the library is used by all projects as soon as it is available in
> > our central repository. Much easier to manage, but it sound a bit
> > scary to have it that much automated ... Other problem, we will
> > loose build reproducibility ...
> >
> > I'll be happy to know how you manage dependency versions in large
> > organizations ...
> >
> > Thanks a lot !
> >
> > Guillaume
> >
> >
> > --
> > Jabber : gehel@amessage.ch
> > Skype : Guillaume.Lederrey
> > Projects :
> > * http://rwanda.wordpress.com/
> > * http://rwandatech.wordpress.com/
> >
>
>
> --
> Jabber : gehel@amessage.ch
> Skype : Guillaume.Lederrey
> Projects :
> * http://rwanda.wordpress.com/
> * http://rwandatech.wordpress.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
--
Jabber : gehel@amessage.ch
Skype : Guillaume.Lederrey
Projects :
* http://rwanda.wordpress.com/
* http://rwandatech.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
**********************************************************************
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependency versions in large multi-projects multi-modules environment
Posted by Guillaume Lederrey <gu...@gmail.com>.
On 09/01/2008, nicklist@planet.nl <ni...@planet.nl> wrote:
> > I have to investigate the migration to Maven in our organisation. We
> > have a pretty large software base : about 100 projects each generating
> > 3 to 6 artifacts. A part of these modules are a framework used by most
> > other projects.
>
> On this basis I would start with three parent poms.
> - On for the company, which would have normal dependencymanagement for common projects outside your company.
> - On for the framework, which is a child of the company pom.
> - On for the other libraries, which is also a child of the company pom and keeps references to the right framework libraries.
That's more or less what I have in place for my tests. (Actually, it
is a bit more complex, as we have 2 levels of framework).
My problem is with our libraries.
* We have a parent pom that references the versions of the framework
(this pom is released by the team responsible for the framework).
* We have a pom that references the versions of all libraries, its
parent is the one above.
* every library defines its own dependency, but no version. Its parent
pom is the one above. So, overall I have :
Company pom
\-- Framework parent pom (defines all versions of the framework dependencies)
\-- Libraries parent pom (defines all versions of the libraries)
|-- Library 1 pom
| |-- module 1
| |-- module 2
| \-- module 3
|-- Library 2 pom
| |-- module 1
| |-- module 2
| \-- module 3
\-- Library 3 pom
|-- module 1
|-- module 2
\-- module 3
Libraries have interdependencies, so we want the libraries themselves
to inherit from a parent pom that declares the versions. And that's
where the snake bite its tail ...
So, if I understand your solution right, it doesnt apply to our
situation, because w cant just "side step" the dependency declaration
... Did I miss something again ?
> Now it is a matter of releasing the framework with its superpom and after that updating the other superpom to reference the right libraries.
>
> Hth,
>
> Nick Stolwijk
>
> -----Original Message-----
> From: Guillaume Lederrey [mailto:guillaume.lederrey@gmail.com]
> Sent: Wed 1/9/2008 11:01 AM
> To: Maven Users List
> Subject: Re: Dependency versions in large multi-projects multi-modules environment
>
> I'm trying to go down the path of option #1 below :
>
> * a super pom which define all dependencies, we can leave it in
> SNAPSHOT state for the dev cycle
> * all libraries reference this parent pom. The libraries can go
> through a couple of version increments during the dev cycle.
>
> Now I have a problem at the time of release :
>
> I have to release a version of both the super pom and the libraries.
> The parent pom has to be updated to reference the versions of the
> libraries at release time, and the libraries have to be updated to
> reference the super pom at release time. So I got a cycle ...
>
> If I release the libraries first, and then update the super pom, I
> then have to release the super pom, and as the super pom has been
> updated, I have to release the libraries as well and so on ...
>
> I think my requirements are pretty standard, so there should be an
> obvious solution that I am missing. What didnt I understand ?
>
> Thanks for your help !
>
> MrG
>
> On 07/01/2008, Guillaume Lederrey <gu...@gmail.com> wrote:
> > Hello !
> >
> > I have to investigate the migration to Maven in our organisation. We
> > have a pretty large software base : about 100 projects each generating
> > 3 to 6 artifacts. A part of these modules are a framework used by most
> > other projects.
> >
> > For the moment, we are managing versioning with ant, and a script that
> > download the latest version of each library. This script is updated
> > every time a new version of a library is released. The script itself
> > is on a server and accessed by all developers / build tools.
> >
> > I see to major ways to do the same with Maven :
> >
> > 1) replace our script by a parent pom which will contain all
> > dependencies and versions in its <dependencyManagement/> section. This
> > means that every time a new library is released, a new version of this
> > parent pom has to be released as well. And all other projects have to
> > update their reference to the latest parent pom.
> >
> > 2) use version ranges in the parent pom. This way, the new version of
> > the library is used by all projects as soon as it is available in our
> > central repository. Much easier to manage, but it sound a bit scary to
> > have it that much automated ... Other problem, we will loose build
> > reproducibility ...
> >
> > I'll be happy to know how you manage dependency versions in large
> > organizations ...
> >
> > Thanks a lot !
> >
> > Guillaume
> >
> >
> > --
> > Jabber : gehel@amessage.ch
> > Skype : Guillaume.Lederrey
> > Projects :
> > * http://rwanda.wordpress.com/
> > * http://rwandatech.wordpress.com/
> >
>
>
> --
> Jabber : gehel@amessage.ch
> Skype : Guillaume.Lederrey
> Projects :
> * http://rwanda.wordpress.com/
> * http://rwandatech.wordpress.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
--
Jabber : gehel@amessage.ch
Skype : Guillaume.Lederrey
Projects :
* http://rwanda.wordpress.com/
* http://rwandatech.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Dependency versions in large multi-projects multi-modules environment
Posted by ni...@planet.nl.
> I have to investigate the migration to Maven in our organisation. We
> have a pretty large software base : about 100 projects each generating
> 3 to 6 artifacts. A part of these modules are a framework used by most
> other projects.
On this basis I would start with three parent poms.
- On for the company, which would have normal dependencymanagement for common projects outside your company.
- On for the framework, which is a child of the company pom.
- On for the other libraries, which is also a child of the company pom and keeps references to the right framework libraries.
Now it is a matter of releasing the framework with its superpom and after that updating the other superpom to reference the right libraries.
Hth,
Nick Stolwijk
-----Original Message-----
From: Guillaume Lederrey [mailto:guillaume.lederrey@gmail.com]
Sent: Wed 1/9/2008 11:01 AM
To: Maven Users List
Subject: Re: Dependency versions in large multi-projects multi-modules environment
I'm trying to go down the path of option #1 below :
* a super pom which define all dependencies, we can leave it in
SNAPSHOT state for the dev cycle
* all libraries reference this parent pom. The libraries can go
through a couple of version increments during the dev cycle.
Now I have a problem at the time of release :
I have to release a version of both the super pom and the libraries.
The parent pom has to be updated to reference the versions of the
libraries at release time, and the libraries have to be updated to
reference the super pom at release time. So I got a cycle ...
If I release the libraries first, and then update the super pom, I
then have to release the super pom, and as the super pom has been
updated, I have to release the libraries as well and so on ...
I think my requirements are pretty standard, so there should be an
obvious solution that I am missing. What didnt I understand ?
Thanks for your help !
MrG
On 07/01/2008, Guillaume Lederrey <gu...@gmail.com> wrote:
> Hello !
>
> I have to investigate the migration to Maven in our organisation. We
> have a pretty large software base : about 100 projects each generating
> 3 to 6 artifacts. A part of these modules are a framework used by most
> other projects.
>
> For the moment, we are managing versioning with ant, and a script that
> download the latest version of each library. This script is updated
> every time a new version of a library is released. The script itself
> is on a server and accessed by all developers / build tools.
>
> I see to major ways to do the same with Maven :
>
> 1) replace our script by a parent pom which will contain all
> dependencies and versions in its <dependencyManagement/> section. This
> means that every time a new library is released, a new version of this
> parent pom has to be released as well. And all other projects have to
> update their reference to the latest parent pom.
>
> 2) use version ranges in the parent pom. This way, the new version of
> the library is used by all projects as soon as it is available in our
> central repository. Much easier to manage, but it sound a bit scary to
> have it that much automated ... Other problem, we will loose build
> reproducibility ...
>
> I'll be happy to know how you manage dependency versions in large
> organizations ...
>
> Thanks a lot !
>
> Guillaume
>
>
> --
> Jabber : gehel@amessage.ch
> Skype : Guillaume.Lederrey
> Projects :
> * http://rwanda.wordpress.com/
> * http://rwandatech.wordpress.com/
>
--
Jabber : gehel@amessage.ch
Skype : Guillaume.Lederrey
Projects :
* http://rwanda.wordpress.com/
* http://rwandatech.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependency versions in large multi-projects multi-modules environment
Posted by Guillaume Lederrey <gu...@gmail.com>.
I'm trying to go down the path of option #1 below :
* a super pom which define all dependencies, we can leave it in
SNAPSHOT state for the dev cycle
* all libraries reference this parent pom. The libraries can go
through a couple of version increments during the dev cycle.
Now I have a problem at the time of release :
I have to release a version of both the super pom and the libraries.
The parent pom has to be updated to reference the versions of the
libraries at release time, and the libraries have to be updated to
reference the super pom at release time. So I got a cycle ...
If I release the libraries first, and then update the super pom, I
then have to release the super pom, and as the super pom has been
updated, I have to release the libraries as well and so on ...
I think my requirements are pretty standard, so there should be an
obvious solution that I am missing. What didnt I understand ?
Thanks for your help !
MrG
On 07/01/2008, Guillaume Lederrey <gu...@gmail.com> wrote:
> Hello !
>
> I have to investigate the migration to Maven in our organisation. We
> have a pretty large software base : about 100 projects each generating
> 3 to 6 artifacts. A part of these modules are a framework used by most
> other projects.
>
> For the moment, we are managing versioning with ant, and a script that
> download the latest version of each library. This script is updated
> every time a new version of a library is released. The script itself
> is on a server and accessed by all developers / build tools.
>
> I see to major ways to do the same with Maven :
>
> 1) replace our script by a parent pom which will contain all
> dependencies and versions in its <dependencyManagement/> section. This
> means that every time a new library is released, a new version of this
> parent pom has to be released as well. And all other projects have to
> update their reference to the latest parent pom.
>
> 2) use version ranges in the parent pom. This way, the new version of
> the library is used by all projects as soon as it is available in our
> central repository. Much easier to manage, but it sound a bit scary to
> have it that much automated ... Other problem, we will loose build
> reproducibility ...
>
> I'll be happy to know how you manage dependency versions in large
> organizations ...
>
> Thanks a lot !
>
> Guillaume
>
>
> --
> Jabber : gehel@amessage.ch
> Skype : Guillaume.Lederrey
> Projects :
> * http://rwanda.wordpress.com/
> * http://rwandatech.wordpress.com/
>
--
Jabber : gehel@amessage.ch
Skype : Guillaume.Lederrey
Projects :
* http://rwanda.wordpress.com/
* http://rwandatech.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org