-----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 <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
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-----

Reply via email to