Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Mon, 9 Jan 2006 22:37:57 +0100 (CET)
From: Giacomo Pati <giacomo@apache.org>
Sender: giacomo@lapgp.otego.com
To: dev@cocoon.apache.org
Subject: Re: Versioning of blocks
In-Reply-To: <43C2CDC9.10802@nada.kth.se>
Message-ID: <Pine.LNX.4.64.0601092232080.13692@lapgp.otego.com>
References: <43C145ED.5050908@apache.org> <43C14F7F.1060507@nada.kth.se>
 <43C17055.2000708@apache.org> <dprti1$d7h$1@sea.gmane.org>
 <43C188D0.3070006@apache.org>
 <dps2q5$u7e$1@sea.gmane.org>
 <Pine.LNX.4.64.0601092116150.13692@lapgp.otego.com>
 <43C2CDC9.10802@nada.kth.se>
X-GPG-PUBLIC_KEY: 
 http://pks.gpg.cz:11371/pks/lookup?op=get&search=0x2CD749BD98E35590
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Scanned: ClamAV version 0.87.1,
 clamav-milter version 0.87 on smtp-01.tornado.cablecom.ch
X-Virus-Status: Clean
X-DCC-spamcheck-02.tornado.cablecom.ch-Metrics: smtp-01.tornado.cablecom.ch
 32701; Body=1
	Fuz1=1 Fuz2=1
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

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