-----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 <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
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-----
