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.
Alex
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.
???
—ml—
--
Alexander Klimetschek
http://www.mindquarry.com
