cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Versioning of blocks
Date Mon, 09 Jan 2006 20:55:37 GMT
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.

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.

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.

With OSGi we will get classloader isolation and more advanced handling 
of dependencies on different versions, but we should get the M2 build in 
a stable state first ;)

/Daniel

Mime
View raw message