cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: Versioning of blocks
Date Mon, 09 Jan 2006 21:37:57 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 9 Jan 2006, Daniel Fagerstrom wrote:

> Date: Mon, 09 Jan 2006 21:55:37 +0100
> From: Daniel Fagerstrom <danielf@nada.kth.se>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: Re: Versioning of blocks
> 
> Giacomo Pati skrev:
>>  On Sun, 8 Jan 2006, Jorg Heymans wrote:
>> >  Carsten Ziegeler wrote:
>> > 
>> > >  Hmm, yes, like I wrote in my latest answer to Daniels post, I'm not 
>> > >  sure
>> > >  if this is the right approach. I think, blocks will be totally
>> > >  independent wrt to releases/versioning from the core in the future. 
>> > >  And
>> > 
>> >  Yes the release cycle of blocks will be totally independent of the core
>> >  release cycle. The actual versioning is independent as well.
>> > 
>> >  The fact that my suggestion copies ./trunk to ./branch does not mean
>> >  that we tie the release or versioning of blocks in ./branch to that
>> >  core. It just means that we explicitly state that those blocks are only
>> >  guaranteed to be working with that particular core. The branch would
>> >  effectively be in maintenance mode, meaning you'ld only backport
>> >  *critical* bugfixes.
>>
>>
>>  Hmm.. it seems we get a complicated thing here:
>>
>>  What about if I write a block that depends on
>>
>>  1. block A 1.0 which depends on cocoon-core-2.2
>>  2. block B 1.1 which depends on cocoon-core-2.3
>>
>>  than?
>>
>>  Does this mean I have to make sure that my block A only depends on blocks
>>  that all depend on the very same version of the same dependant block?
>
> In the general case, yes. But that is a fact of life rather than something 
> that has to do with the particular build system.

Yes, but the impression M2 is giving make it sometimes hard to see the 
transient dependency conflicts.

> What we can and should do about it is:
>
> * Split the core and large blocks into smaller blocks. This reduces 
> interdependencies as you don't suffer from changes of a block that didn't 
> have to do with what you used from it.
>
> * Strenghten and respect contracts of blocks. If all blocks has well defined 
> external apis (and the user only depend on them) and we keep the apis back 
> compatible, a block can use newer versions of the dependent block than it was 
> designed with.

Let's hope so, by goodness!

> M2 have a transitive dependency resolution system. In the case above it will 
> find out that the dependency set of your block contains two versions of the 
> cocoon-core block. In this case it will try to compile it with the latest 
> version. This automatic behaviour can in turn be overided by explicitly 
> depend on a specific version of cocoon-core in your blocks pom.

Good to make everybody know of it.

> With OSGi we will get classloader isolation and more advanced handling of 
> dependencies on different versions,

Yes, I knew that but I didn't mention it as it is not clear when that 
will be available (and things ATM are not in 2.2.0 IIRC).

> but we should get the M2 build in a 
> stable state first ;)

Yes, but than everybodyd need to be aware of the mechanisms M2 will 
follow t resolve dependencies which sometime wasn't clear as some 
said that "M2 will handle dependencies automa(gt)ically" ;-)

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

iD8DBQFDwte3LNdJvZjjVZARAg9LAKCCdN+xnso1PtBAz5fwiOYkS75rpgCggFNi
hNLxt4uolGh8X5c2TFDTaTs=
=Yjdi
-----END PGP SIGNATURE-----

Mime
View raw message