-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 12 Jan 2006, Giacomo Pati wrote:
Date: Thu, 12 Jan 2006 08:51:12 +0100 (CET)
From: Giacomo Pati <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: [M10N] cocoon-jcr
--[PinePGP]--------------------------------------------------[begin]--
On Thu, 12 Jan 2006, Jorg Heymans wrote:
Date: Thu, 12 Jan 2006 00:19:47 +0100
From: Jorg Heymans <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: [M10N] cocoon-jcr
Giacomo Pati wrote:
> In a big multiproject Maven 1 project we solved this by an entity file
> in the root directory where all dependant jar had entities for their
> groupId, artifactId and version (strictly sorted by groupId and
> artifactId) and each (sub) project.xml file included it and used those
> entity to define their individual dependency. This way we prevented
> version clashes easily and relatively early. This has worked fine (even
> if not recommended by Maven itself. In another project it has hit us
> hard when we used automated integration tests with Continuum which
> wasn't able to locate the entity file anymore because of relative paths
> in the project.xml.
I've never actually used it, but the dependencyManagement [1] element is
all about centrally managing dependency versions.
Thanks. I've probably overlooked that. Seems to be a possibility we have
to keep an eye on in case we do have to manage dependencies in a more
general and centralized way for all our blocks to prevent version
clashes (until we have classloader isolation for blocks).
And BTW this might help keeping oversight for upgrading dependencies
(which version do we use compared to which are available)
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDxhABLNdJvZjjVZARAralAJ4+EDOR4Gjn9cCYI+KX0Lx/inCDhACg2+V1
U50pJpAQYOJnR3SlzG0tOGw=
=38L8
-----END PGP SIGNATURE-----
