cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Lundquist <>
Subject Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
Date Thu, 25 Jan 2007 18:05:18 GMT

On Jan 25, 2007, at 3:01 AM, Giacomo Pati wrote:

> On Wed, 24 Jan 2007, Alexander Klimetschek wrote:
>> 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.
> We've managed other projects with lots of module by the  
> <dependencyManagement> section in the root pom where all dependencies  
> are listed with version numbers. Module poms will thus never have a  
> version defined in their dependencies.

For the standard case (not my local branch problem), I think  
<dependencyManagement> could be used and we could get rid of the  
pom-updater.  At first I (Maven noob) thought it wouldn't work because  
Cocoon is no longer a monolithic project, i.e. a person should be able  
to do an isolated checkout of a block and build and develop on it,  
without having all of trunk checked out.  But then I realized (d'oh!)  
that the root pom and other aggregating poms are in artifacts that will  
be fetched into the local maven repo, they don't have to be built  
locally.  So, it looks like using the standard <dependencyManagement>  
instead of custom pom-updater is using the right tool for the right  
job, WDOT?

Now can we please get back to talking about my local branch problem? :-)

<dependencyMangement> of course does not help me, because the only  
things you can set in an ad hoc local profile are repository locations  
and properties.  Everything else was deemed too dangerous [1] by the  
Maven developers, because it militates against build reproducibility  
(they call it "portability").  IMHO, that was a bad decision and the  
wrong solution to the reproducibility problem!

How can I have multiple local builds of the same artifact coexisting on  
my machine, without modifying any Subversion-controlled resources (e.g.  
poms)?  That's the question.  I'm in need of some brilliant ideas here,  
does somebody have any?



View raw message