cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
Date Thu, 25 Jan 2007 11:01:03 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 24 Jan 2007, Alexander Klimetschek wrote:

> Date: Wed, 24 Jan 2007 14:10:53 +0100
> From: Alexander Klimetschek <alexander.klimetschek@mindquarry.com>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: Re: Hardcoded artifact versions (was Re: Multiple local snapshots in
>     Maven)
> 
> 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.
>
> 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.

Ciao

> Mark Lundquist schrieb:
>>
>>  On Jan 21, 2007, at 12:09 PM, Mark Lundquist wrote:
>> 
>> >  I need to learn how to manage multiple local artifact sets in my Maven 
>> >  repo.  I have *two* different trunk build areas on my machine under svk 
>> >  (my local mirror of the ASF repo, and a local development branch), but I 
>> >  haven't put all the pieces of that story together w.r.t. Maven...
>>
>>  I think what is standing in my way right now is all the hard-coded version
>>  ids in poms.  What's the deal with that?  There are a handful of unique
>>  ones in trunk right now, there must be some reason why they are all
>>  hardcoded into the individual project poms instead of defined as
>>  properties in the root pom or the several intermediate parent poms... and
>>  I just don't know the reason?
>>
>>  If they were properties, then I could trigger a profile using <file>
>>  activation in my settings.xml and override the version property/ies,
>>  setting them uniquely for whatever local branch I'm building in.

- -- 
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.1 (GNU/Linux)

iD8DBQFFuI35LNdJvZjjVZARAp4YAJ9MMR8ET0EocPLPu1KUtO1237UoZQCg8Gw8
agjaAlYsInzEzGJBtGSLCQE=
=YmHx
-----END PGP SIGNATURE-----

Mime
View raw message