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 08:14:56 GMT
-----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 <giacomo@apache.org>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> 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 <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).

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

Mime
View raw message