Hi Alex,
On Jan 24, 2007, at 5:10 AM, Alexander Klimetschek wrote:
I think the idea is to have separate release cycles and thus different
versions for each block. So there is no general cocoon version any
more, this version, like currently 2.2, only regards the core modules.
Right, but still... :-)
But as we are having our own version of cocoon 2.2 including our
patches during development, I know the problem of going through all
poms and changing the version number... At least there is this
pom-updater tool in tools/ which automatically modifies all poms. It
can be modified quite easily (it's XSLT) to do other things with the
version number.
The pom-updater is unsatisfactory for this because it still doesn't
really allow multiple builds of Cocoon to co-exist on my machine. At
best it just makes it slightly less tedious to set up the builds in the
first place, but still, installing either of the builds renders the
other unusable (until the other in turn is rebuilt).
What I'm trying to have is (a) a "reference" build of trunk that does
not have any of my local fingerprints on it, and (b) a local
development build (or even, potentially, more than one of those). Then
I can play with the reference build it or debug it and see "oh, this is
how it's supposed to work"... or, maybe sometimes I would see "ah, so
this is really broken in trunk, it's not the fault of my local
changes," etc. This is not possible right now, and I think it's the
hard-coded versions numbers that are standing in the way. If they were
implemented with properties, I could override them in a profile.
The other bad thing currently would be having local mods in my
development poms â if I'm going to submit a patch then I have to make
sure to strip out those local changes before generating the patch...
but that's not sustainable going forward because it defeats the purpose
of maintaining a local development branch, e.g. in svk. For you
committers it's no big, because you don't have to JIRA a patch and then
wait 'til when and if your patch gets accepted, you just commit it and
then you are in sync again. For other contributors it is harder, and
local development branches have the potential to make Cocoon
development tractable in the Mavenized world... but only if they work
:-/
I'm still pretty much a noob to the ways of Maven so bear with me for a
moment... but instead of inheriting <version> in the aggregated project
poms, suppose (just for the sake of discussion!) that the root-level
pom defined a tree of parameters that is isomorphic to the project
hierarchy, like this:
<property>
<cocoon.version>2.2.whatever</cocoon.version> <!-- (e.g.) -->
<cocoon.version.core>${cocoon.version}</cocoon.verision.core>
<cocoon.version.core.cocoon-core>${cocoon.version.core}</
cocoon.version.core.cocoon-core>
<cocoon.version.core.cocoon-pipeline>${cocoon.version.core}</
cocoon.version.core.cocoon-pipeline>
.
.
<cocoon.version.blocks>${cocoon.version}<cocoon.version.blocks>
<cocoon.version.blocks.ajax>${cocoon.version.blocks}<cocoon.version.bloc
ks.ajax>
.
.
Each lower-level pom would use the appropriate ${cocoon.verision...}
property in setting its <version>, and would similarly use these
properties to define <version>s of its <dependency>s. If e.g. trunk
development requires, say, that some level have a different version
number, then it would be changed at that level in the root pom's tree
of version property definitions. (I'm talking about controlled changes
in Subversion here, not local changes). (Note, there would be no more
need for the pom-updater in this scheme).
Now, this breaks good design because the root pom has to know details
about the whole project tree, which countervails decomposition by
hierarchal project aggregation. But... it does allow me to have
multiple builds that can coexist because they do not create artifact
clashes in my local maven repo, because I can trigger a build profile
that overrides whichever version properties I require to be unique for
that build.
So the question is, is there another way that can work like this idea,
but without the smelliness of the root pom having to contain details
about the whole hierarchy?
cheers,
âmlâ
