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:[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]
