cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Lundquist <lundquist.m...@gmail.com>
Subject Re: Hardcoded artifact versions (was Re: Multiple local snapshots in Maven)
Date Thu, 25 Jan 2007 23:15:09 GMT

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—


Mime
View raw message