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
