Thanks a lot for all the feedback !
I am still not completely convinced ... see below.
On 09/01/2008, Beelen, M. - SPLXL <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> 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, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> > 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 <[EMAIL PROTECTED]> 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 : [EMAIL PROTECTED]
> > > Skype : Guillaume.Lederrey
> > > Projects :
> > > * http://rwanda.wordpress.com/
> > > * http://rwandatech.wordpress.com/
> > >
> >
> >
> > --
> > Jabber : [EMAIL PROTECTED]
> > Skype : Guillaume.Lederrey
> > Projects :
> > * http://rwanda.wordpress.com/
> > * http://rwandatech.wordpress.com/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
>
> --
> Jabber : [EMAIL PROTECTED]
> Skype : Guillaume.Lederrey
> Projects :
> * http://rwanda.wordpress.com/
> * http://rwandatech.wordpress.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> **********************************************************************
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Jabber : [EMAIL PROTECTED]
Skype : Guillaume.Lederrey
Projects :
* http://rwanda.wordpress.com/
* http://rwandatech.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
