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—
