cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: [M10N] cocoon-jcr
Date Thu, 12 Jan 2006 07:51:12 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 12 Jan 2006, Jorg Heymans wrote:

> Date: Thu, 12 Jan 2006 00:19:47 +0100
> From: Jorg Heymans <jh@domek.be>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> 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).

- -- 
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)

iD8DBQFDxgp4LNdJvZjjVZARAjzkAJ9kJEL46BDHw3wX5C6MF2igeCXKEQCgtXda
PSOLSfpogxJMT22sEfdtJho=
=LIJM
-----END PGP SIGNATURE-----

Mime
View raw message