You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Mark Lundquist <lu...@gmail.com> on 2007/01/24 10:43:51 UTC
Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
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—
Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
Posted by Mark Lundquist <lu...@gmail.com>.
On Jan 27, 2007, at 6:39 AM, Jorg Heymans wrote:
> Mark Lundquist wrote:
>
>> :-/ It's also kind of a heavy-handed kluge that goes against the
>> spirit of Maven (IMHO alternative local repo locations should only be
>> used for testing purposes), but that's a secondary issue.
>
> well that's what you were describing no?
Not really, by "testing" I mean testing Maven, or testing repositories,
etc.
> Thanks for your interesting thoughts!
Y.W... After bumbling my way through learning more about Maven, e.g.
profiles, what <dependencyManagement> is/isn't supposed to be able to
do, etc., I'm convinced it's primary Maven functionality that's
required by this scenario. I've just posted a request for discussion
on the Maven dev list, if anybody cares to follow along (or chip in!
:-) over there...
cheers,
—ml—
Re: Hardcoded artifact versions (was Re: Multiple local snapshots
in Maven)
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, 27 Jan 2007, Jorg Heymans wrote:
> Date: Sat, 27 Jan 2007 15:39:02 +0100
> From: Jorg Heymans <jh...@apache.org>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: Re: Hardcoded artifact versions (was Re: Multiple local snapshots in
> Maven)
>
> Mark Lundquist wrote:
>
>> LOL, Reinhard suggested the same thing earlier on in this thread. I
>
> ah true i see that now, sorry !
>
>> might end up trying to do it this way temporarily, if that's what it takes
>> to get some work done. The main problem with it is that because it's not
>> location-dependent, it's not set-and-forget, which means it's not
>> foolproof, which means that ML is guaranteed to cock it up within the
>> first 24 hours (either through confusion or sheer forgetfulness)
>
> true, but that's how it is. Anyway I'm sure you can batch-script your way
> around this.
>
>> :-/ It's also kind of a heavy-handed kluge that goes against the spirit
>> of Maven (IMHO alternative local repo locations should only be used for
>> testing purposes), but that's a secondary issue.
>
> well that's what you were describing no? Keeping trunk for testing purposes
> and a local build to tinker with without impacting the other?
>
>> Anyway [ahem]... Maven may not be perfect yet, but like Eric Raymond said,
>> "all bugs are shallow given enough eyeballs", and there are a lot of
>> eyeballs on Maven right now, so I think it will get better.
>
> eventually yes. But for such a high profile project it surprises me that
> their last release is dated almost a year now.
You should take into account that Maven is build upon plugins which it
can update by itself (without the need of a new official Maven release).
So a release of Maven itself is most probably just it's core
(admittedly, I dunno exactly what all is in the Maven core ;-)
Ciao
- --
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)
iD8DBQFFvhGiLNdJvZjjVZARAmUXAKCp9F5YKiNI9u2+BOblkhr561uAmACeNtfO
9uXHOLRkIoKTtVDzfSuyCzI=
=cxUU
-----END PGP SIGNATURE-----
Re: Hardcoded artifact versions (was Re: Multiple local snapshots
in Maven)
Posted by Jorg Heymans <jh...@apache.org>.
Mark Lundquist wrote:
> LOL, Reinhard suggested the same thing earlier on in this thread. I
ah true i see that now, sorry !
> might end up trying to do it this way temporarily, if that's what it
> takes to get some work done. The main problem with it is that because
> it's not location-dependent, it's not set-and-forget, which means it's
> not foolproof, which means that ML is guaranteed to cock it up within
> the first 24 hours (either through confusion or sheer forgetfulness)
true, but that's how it is. Anyway I'm sure you can batch-script your
way around this.
> :-/ It's also kind of a heavy-handed kluge that goes against the spirit
> of Maven (IMHO alternative local repo locations should only be used for
> testing purposes), but that's a secondary issue.
well that's what you were describing no? Keeping trunk for testing
purposes and a local build to tinker with without impacting the other?
> Anyway [ahem]... Maven may not be perfect yet, but like Eric Raymond
> said, "all bugs are shallow given enough eyeballs", and there are a lot
> of eyeballs on Maven right now, so I think it will get better.
eventually yes. But for such a high profile project it surprises me that
their last release is dated almost a year now.
>> Also, if you cram the dependencies of 100+ modules and their version
>> numbers in the root pom then this can become a management bottleneck
>> as well as this pom will need to be managed and included in the
>> release process of every module.
>
> Yes — a pain. I don't like centralizing this. Anyway, w.r.t. while
> there may yet be a role for <dependencyManagement> in our build system,
> it looks to me like it does not help with the intra-project
> dependencies, because it only addresses the dependent side and not the
> installing side. The reference [1] doesn't say anything about
> <dependencyManagement> affecting the <version> of any artifact being
> built. It just says "anybody that uses artifact Foo, you get version
> XYZ of it". If I'm actually building Foo though, this doesn't make it
> build version XYZ, it still builds whatever its <project/version> says.
Yes dependencyMgmt is all about managing the dependencies of your
project, not the artifacts it produces. Note that its usage is currently
discouraged as it doesn't really work as advertised. I think it was
scheduled to be fixed for 2.0.5, then pushed to 2.0.6 ...
Thanks for your interesting thoughts!
Jorg
Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
Posted by Mark Lundquist <lu...@gmail.com>.
On Jan 25, 2007, at 11:46 AM, Jorg Heymans wrote:
> How about having 2 local repositories ? Put a settings.xml in your
> reference checkout and invoke maven using -s settings.xml. Do the
> same for your local dev checkout and make sure that the
> <localRepository> element [1] in both is different.
LOL, Reinhard suggested the same thing earlier on in this thread. I
might end up trying to do it this way temporarily, if that's what it
takes to get some work done. The main problem with it is that because
it's not location-dependent, it's not set-and-forget, which means it's
not foolproof, which means that ML is guaranteed to cock it up within
the first 24 hours (either through confusion or sheer forgetfulness)
:-/ It's also kind of a heavy-handed kluge that goes against the
spirit of Maven (IMHO alternative local repo locations should only be
used for testing purposes), but that's a secondary issue...
> Maven2 is not bug-free by any means, and some of its advertised ways
> of how it "should" work (eg dependencyManagement) simply don't. For
> example, my experience with version properties in the root pom is that
> the variable interpolation on artifact deployment time is buggy.
> Perhaps this has been fixed already, if so then great but everyone
> will need to upgrade to 2.0.5-SNAPSHOT for it to work.
Right, and I realize that Maven 2 is a work in progress. In spite of
that, and even though it gets harshed on by a lot of people in the Java
world, I think the Mavenization of Cocoon will turn out to have been
one of the best decisions for Cocoon ever. That and the
Springification... so 2.2 is really something to hang your hat on.
Many thx to all you guys for all the great work.
Anyway [ahem]... Maven may not be perfect yet, but like Eric Raymond
said, "all bugs are shallow given enough eyeballs", and there are a lot
of eyeballs on Maven right now, so I think it will get better.
> Also, if you cram the dependencies of 100+ modules and their version
> numbers in the root pom then this can become a management bottleneck
> as well as this pom will need to be managed and included in the
> release process of every module.
Yes — a pain. I don't like centralizing this. Anyway, w.r.t. while
there may yet be a role for <dependencyManagement> in our build system,
it looks to me like it does not help with the intra-project
dependencies, because it only addresses the dependent side and not the
installing side. The reference [1] doesn't say anything about
<dependencyManagement> affecting the <version> of any artifact being
built. It just says "anybody that uses artifact Foo, you get version
XYZ of it". If I'm actually building Foo though, this doesn't make it
build version XYZ, it still builds whatever its <project/version> says.
cheers,
—ml—
Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
Posted by Mark Lundquist <lu...@gmail.com>.
On Jan 25, 2007, at 11:46 AM, Jorg Heymans wrote:
> "countervailing decomposition by hierarchical project aggregation",
> mind if i use that one in my next presentation to senior management?
> :P
Ha Jorg, I *challenge* you to slip it in somewhere into your very next
presentation to senior management, whatever that may be! :-) :-)
—ml—
Re: Hardcoded artifact versions (was Re: Multiple local snapshots
in Maven)
Posted by Reinhard Poetz <re...@apache.org>.
Jorg Heymans wrote:
> Maven2 is not bug-free by any means, and some of its advertised ways of
> how it "should" work (eg dependencyManagement) simply don't. For
> example, my experience with version properties in the root pom is that
> the variable interpolation on artifact deployment time is buggy.
not only deployment of artifacts seems to be still buggy, also the calculation
of transitive dependencies versions doesn't work always as expected. Just
recently I've had problems to build the docs at the zone (got the infamous
version "2.5.1" of an artifact can't be found) altough it worked at my local
machine using Maven 2.0.4.
> Perhaps
> this has been fixed already, if so then great but everyone will need to
> upgrade to 2.0.5-SNAPSHOT for it to work.
see above, I'm not sure if all the bugs about dependency resolution are solved
there either ...
Also, if you cram the
> dependencies of 100+ modules and their version numbers in the root pom
> then this can become a management bottleneck as well as this pom will
> need to be managed and included in the release process of every module.
yep. IMO we shouldn't use any properties/dependency-management "magic" within
Cocoon trunk.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Hardcoded artifact versions (was Re: Multiple local snapshots
in Maven)
Posted by Jorg Heymans <jh...@apache.org>.
Mark Lundquist wrote:
>
> What I'm trying to have is (a) a "reference" build of trunk that does
> not have any of my local fingerprints on it, and (b) a local development
> build (or even, potentially, more than one of those). Then I can play
How about having 2 local repositories ? Put a settings.xml in your
reference checkout and invoke maven using -s settings.xml. Do the same
for your local dev checkout and make sure that the <localRepository>
element [1] in both is different.
> Each lower-level pom would use the appropriate ${cocoon.verision...}
> property in setting its <version>, and would similarly use these
> properties to define <version>s of its <dependency>s. If e.g. trunk
> development requires, say, that some level have a different version
> number, then it would be changed at that level in the root pom's tree of
> version property definitions. (I'm talking about controlled changes in
> Subversion here, not local changes). (Note, there would be no more need
> for the pom-updater in this scheme).
sure.
>
> Now, this breaks good design because the root pom has to know details
> about the whole project tree, which countervails decomposition by
> hierarchal project aggregation. But... it does allow me to have
"countervailing decomposition by hierarchical project aggregation", mind
if i use that one in my next presentation to senior management? :P
> multiple builds that can coexist because they do not create artifact
> clashes in my local maven repo, because I can trigger a build profile
> that overrides whichever version properties I require to be unique for
> that build.
>
Mark, i think you have a lot of great ideas about improving our build.
At this point i cannot say whether any of them will fully work, you
should just try it out a bit and report back.
Maven2 is not bug-free by any means, and some of its advertised ways of
how it "should" work (eg dependencyManagement) simply don't. For
example, my experience with version properties in the root pom is that
the variable interpolation on artifact deployment time is buggy. Perhaps
this has been fixed already, if so then great but everyone will need to
upgrade to 2.0.5-SNAPSHOT for it to work. Also, if you cram the
dependencies of 100+ modules and their version numbers in the root pom
then this can become a management bottleneck as well as this pom will
need to be managed and included in the release process of every module.
Regards
Jorg
[1] http://maven.apache.org/settings.html
Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
Posted by Mark Lundquist <lu...@gmail.com>.
Hi Alex,
On Jan 24, 2007, at 5:10 AM, Alexander Klimetschek wrote:
> 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.
Right, but still... :-)
> 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.
The pom-updater is unsatisfactory for this because it still doesn't
really allow multiple builds of Cocoon to co-exist on my machine. At
best it just makes it slightly less tedious to set up the builds in the
first place, but still, installing either of the builds renders the
other unusable (until the other in turn is rebuilt).
What I'm trying to have is (a) a "reference" build of trunk that does
not have any of my local fingerprints on it, and (b) a local
development build (or even, potentially, more than one of those). Then
I can play with the reference build it or debug it and see "oh, this is
how it's supposed to work"... or, maybe sometimes I would see "ah, so
this is really broken in trunk, it's not the fault of my local
changes," etc. This is not possible right now, and I think it's the
hard-coded versions numbers that are standing in the way. If they were
implemented with properties, I could override them in a profile.
The other bad thing currently would be having local mods in my
development poms — if I'm going to submit a patch then I have to make
sure to strip out those local changes before generating the patch...
but that's not sustainable going forward because it defeats the purpose
of maintaining a local development branch, e.g. in svk. For you
committers it's no big, because you don't have to JIRA a patch and then
wait 'til when and if your patch gets accepted, you just commit it and
then you are in sync again. For other contributors it is harder, and
local development branches have the potential to make Cocoon
development tractable in the Mavenized world... but only if they work
:-/
I'm still pretty much a noob to the ways of Maven so bear with me for a
moment... but instead of inheriting <version> in the aggregated project
poms, suppose (just for the sake of discussion!) that the root-level
pom defined a tree of parameters that is isomorphic to the project
hierarchy, like this:
<property>
<cocoon.version>2.2.whatever</cocoon.version> <!-- (e.g.) -->
<cocoon.version.core>${cocoon.version}</cocoon.verision.core>
<cocoon.version.core.cocoon-core>${cocoon.version.core}</
cocoon.version.core.cocoon-core>
<cocoon.version.core.cocoon-pipeline>${cocoon.version.core}</
cocoon.version.core.cocoon-pipeline>
.
.
<cocoon.version.blocks>${cocoon.version}<cocoon.version.blocks>
<cocoon.version.blocks.ajax>${cocoon.version.blocks}<cocoon.version.bloc
ks.ajax>
.
.
Each lower-level pom would use the appropriate ${cocoon.verision...}
property in setting its <version>, and would similarly use these
properties to define <version>s of its <dependency>s. If e.g. trunk
development requires, say, that some level have a different version
number, then it would be changed at that level in the root pom's tree
of version property definitions. (I'm talking about controlled changes
in Subversion here, not local changes). (Note, there would be no more
need for the pom-updater in this scheme).
Now, this breaks good design because the root pom has to know details
about the whole project tree, which countervails decomposition by
hierarchal project aggregation. But... it does allow me to have
multiple builds that can coexist because they do not create artifact
clashes in my local maven repo, because I can trigger a build profile
that overrides whichever version properties I require to be unique for
that build.
So the question is, is there another way that can work like this idea,
but without the smelliness of the root pom having to contain details
about the whole hierarchy?
cheers,
—ml—
Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
Posted by Mark Lundquist <lu...@gmail.com>.
On Jan 25, 2007, at 11:12 AM, Alexander Klimetschek wrote:
> Mark Lundquist schrieb:
>> <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!
>
> Full ACK. When I read about what you can put in a profile and what
> not, I was thinking the same thing. They should have simply allowed
> it, but with a big warning sign in the documentation to not use it the
> wrong way...
Well, I've been studying this some more, and I think that even if
<dependencyManagement> were overridable within an external profile, it
would not be enough (see my recent reply to Jorg)...
>> 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?
>
> What's with the properties idea you suggested? Put properties for all
> child-pom-versions in the root pom and overwrite them in your profile.
It's just sort of disgusting :-/. I think it would work, but... there
are like 248 poms in Cocoon, up to 4 levels deep. I doubt we really
want to mirror that structure in the root pom. This would have to be
kept in sync with the source tree at all times, even for local changes,
and that introduces new friction for refactoring efforts, or even just
adding a new block. Also, modules will go away and people will forget
to delete the corresponding properties from the root pom, so it will
get cluttered with obsolete stuff.
As I was thinking about this, at one point just a bit ago it seemed to
me that this really cries out for "IOC for poms"! I was thinking, what
if your external profile could "intercept" any pom in the build and
override something therein? Then I started looking through the pom
elements, and it appears the only thing that's at all reasonable to
override on an ad hoc basis (i.e. without touching controlled files
like poms) is the version id for subprojects. I also realized that I
was too liberal in my criticism of the Maven approach to ad hoc
profiles, because this is a very legitimate measure to preserve build
reproducibility in the committer => repository direction. Everything
else in the pom would break reproducibility under local overriding, but
this one thing does not: the version id to use for (a) building module
X and (b) for satisfying dependencies on X within this top-level
project. So we don't need or want a general-purpose "IOC" here. What
we need is a very specific profile-driven mechanism in Maven for
addressing the specific problem of allowing multiple coexisting project
builds on one machine so as to not result in artifact clashes in the
repository. That's it.
A very quick and dirty workaround would be to for Maven to introduce a
<localRepository> element (a la settings.xml) in an external profile.
It's un-Maveny and inelegant, but it would be relatively easy and
low-risk.
cheers,
—ml—
Re: Hardcoded artifact versions (was Re: Multiple local snapshots
in Maven)
Posted by Alexander Klimetschek <al...@mindquarry.com>.
Mark Lundquist schrieb:
> <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!
Full ACK. When I read about what you can put in a profile and what not,
I was thinking the same thing. They should have simply allowed it, but
with a big warning sign in the documentation to not use it the wrong way...
> 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?
What's with the properties idea you suggested? Put properties for all
child-pom-versions in the root pom and overwrite them in your profile.
Alex
--
Alexander Klimetschek
http://www.mindquarry.com
Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
Posted by Mark Lundquist <lu...@gmail.com>.
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?
thx,
—ml—
[1]
http://maven.apache.org/guides/introduction/introduction-to-
profiles.html
Re: Hardcoded artifact versions (was Re: Multiple local snapshots
in Maven)
Posted by Giacomo Pati <gi...@apache.org>.
-----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 <al...@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-----
Re: Hardcoded artifact versions (was Re: Multiple local snapshots
in Maven)
Posted by Alexander Klimetschek <al...@mindquarry.com>.
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