-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 11 Jan 2006, Daniel Fagerstrom wrote:
Date: Wed, 11 Jan 2006 16:48:10 +0100
From: Daniel Fagerstrom <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
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
- --
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)
iD8DBQFDxWhMLNdJvZjjVZARAtLnAJ0VcA+4JV4/jrOfzkKCXIeOGz+YZwCeM/Df
WRP4gWw6BIHKVCQQXLwOI8U=
=z4gn
-----END PGP SIGNATURE-----
