cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: [M10N] cocoon-jcr
Date Thu, 12 Jan 2006 07:51:12 GMT
Hash: SHA1

On Thu, 12 Jan 2006, Jorg Heymans wrote:

> Date: Thu, 12 Jan 2006 00:19:47 +0100
> From: Jorg Heymans <>
> Reply-To:
> To:
> 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 -
Orixo, the XML business alliance -
Version: GnuPG v1.4.2 (GNU/Linux)


View raw message