cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Lundquist <lundquist.m...@gmail.com>
Subject Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
Date Wed, 24 Jan 2007 17:23:35 GMT
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—

Mime
View raw message