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 Wed, 11 Jan 2006 20:44:59 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 11 Jan 2006, Giacomo Pati wrote:

> Date: Wed, 11 Jan 2006 21:19:22 +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 Wed, 11 Jan 2006, Daniel Fagerstrom wrote:
>
>>  Date: Wed, 11 Jan 2006 16:48:10 +0100
>>  From: Daniel Fagerstrom <danielf@nada.kth.se>
>>  Reply-To: dev@cocoon.apache.org
>>  To: dev@cocoon.apache.org
>>  Subject: Re: [M10N] cocoon-jcr
>>
>>  Carsten Ziegeler wrote:
>>  ...
>> 
>> >  (And it would be good if people would not forget about the licence file
>> >  when they add jars)
>> > 
>> >
>>  With M2s transitive dependence handling it is harder to keep track of what
>>  we
>>  actually depend on. Is there some reporting plugin or switch, so that one
>>  can
>>  get a report of all dependencies of a block or a multi project POM?
>>
>>  Otherwise we risk to get an unwelcome suprise when we genrate a binary
>>  release.
>
> I was to write a mail about it but you raised it before.
>
> We are at the same trap as Maven 1 multiproject concerning dependencies.
> We will fall into it as well (maybe even faster because of transitive
> deps).
>
> BlockA depends on jarB-1.0 which depends on jarC-1.0
> BlockD depends on jarE-1.0 which depends on jarC-2.0
> BlockF depends on BlockA   and   depends on BlockD
>
> Version 1.0 and 2.0 of jarC are incompatible wrt backward compatibility.
>
> And voila we have the desaster. The above chain might look overseeable
> but imagine the chain is 5 times deeper. You might exclude jarC-2.0 from
> dependency resolution, after a possibly excessive debugging session
> where you finally figured you have a version problem, and hope all still
> runs well.
>
> OSGI blocks may solve this (with classloader isolation) but ATM we don't
> have it.
>
> Anybody solved this in an elegant way

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.

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

iD8DBQFDxW5OLNdJvZjjVZARAnB8AKDGx4MFW2/BX3oXdr+KPySYzQV0lQCfRl7n
B/CJ8ikMJjRF8RqQ1J9wXOo=
=bmDr
-----END PGP SIGNATURE-----

Mime
View raw message