-----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-----