Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (herse.apache.org: domain of lundquist.mark@gmail.com
 designates 64.233.184.233 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:mime-version:in-reply-to:references:content-type:message-id:from:subject:date:to:x-mailer;
        b=QR5JExAK5icL1CwFfkpyGIVdPXyjAcNy/3viwrsUNUkTiXczZN4JTm9Zh0Br1/9UbbjfpeLw2dU4CJJS515kCZR+dpxGpVNfTFFJEq2CIX/Kx2jj5n+Um564pwj7ixCRPTYIqAh11jEYJ+IBDVXU42Pgqc5PDL3Ex7TCoKGOZNU=
Mime-Version: 1.0 (Apple Message framework v624)
In-Reply-To: <epavev$700$1@sea.gmane.org>
References: <7e5128fa33b3c678f6697c83fdaadf90@comcast.net>
 <45B37295.4030300@nada.kth.se> <d56d9d36ffad48a053adca98ec8da7bd@gmail.com>
 <ddbc8003688391fce25e4673538ba2d9@gmail.com> <ep7lst$vqm$1@sea.gmane.org>
 <Pine.LNX.4.64.0701251156390.950@lapgp.otego.com>
 <336d0efe8e960a49383dab4e5efb11a9@gmail.com> <epavev$700$1@sea.gmane.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-32-333664776
Message-Id: <868ba744c737e393e56dfb79677c25ac@gmail.com>
From: Mark Lundquist <lundquist.mark@gmail.com>
Subject: Re: Hardcoded artifact versions (was Re: Multiple local snapshots in
 Maven)
Date: Thu, 25 Jan 2007 15:15:09 -0800
To: dev@cocoon.apache.org


--Apple-Mail-32-333664776
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=WINDOWS-1252;
	format=flowed


On Jan 25, 2007, at 11:12 AM, Alexander Klimetschek wrote:

> Mark Lundquist schrieb:
>> <dependencyMangement> of course does not help me, because the only=20
>> things you can set in an ad hoc local profile are repository=20
>> locations and properties.  Everything else was deemed too dangerous=20=

>> [1] by the Maven developers, because it militates against build=20
>> reproducibility (they call it "portability").  IMHO, that was a bad=20=

>> decision and the wrong solution to the reproducibility problem!
>
> Full ACK. When I read about what you can put in a profile and what=20
> not, I was thinking the same thing. They should have simply allowed=20
> it, but with a big warning sign in the documentation to not use it the=20=

> wrong way...

Well, I've been studying this some more, and I think that even if=20
<dependencyManagement> were overridable within an external profile, it=20=

would not be enough (see my recent reply to Jorg)...

>> How can I have multiple local builds of the same artifact coexisting=20=

>> on my machine, without modifying any Subversion-controlled resources=20=

>> (e.g. poms)?  That's the question.  I'm in need of some brilliant=20
>> ideas here, does somebody have any?
>
> What's with the properties idea you suggested? Put properties for all=20=

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

are like 248 poms in Cocoon, up to 4 levels deep.  I doubt we really=20
want to mirror that structure in the root pom.  This would have to be=20
kept in sync with the source tree at all times, even for local changes,=20=

and that introduces new friction for refactoring efforts, or even just=20=

adding a new block.  Also, modules will go away and people will forget=20=

to delete the corresponding properties from the root pom, so it will=20
get cluttered with obsolete stuff.

As I was thinking about this, at one point just a bit ago it seemed to=20=

me that this really cries out for "IOC for poms"!  I was thinking, what=20=

if your external profile could "intercept" any pom in the build and=20
override something therein?  Then I started looking through the pom=20
elements, and it appears the only thing that's at all reasonable to=20
override on an ad hoc basis (i.e. without touching controlled files=20
like poms) is the version id for subprojects.  I also realized that I=20
was too liberal in my criticism of the Maven approach to ad hoc=20
profiles, because this is a very legitimate measure to preserve build=20
reproducibility in the committer =3D> repository direction.  Everything=20=

else in the pom would break reproducibility under local overriding, but=20=

this one thing does not: the version id to use for (a) building module=20=

X and (b) for satisfying dependencies on X within this top-level=20
project.  So we don't need or want a general-purpose "IOC" here.  What=20=

we need is a very specific profile-driven mechanism in Maven for=20
addressing the specific problem of allowing multiple coexisting project=20=

builds on one machine so as to not result in artifact clashes in the=20
repository.  That's it.

A very quick and dirty workaround would be to for Maven to introduce a=20=

<localRepository> element (a la settings.xml) in an external profile. =20=

It's un-Maveny and inelegant, but it would be relatively easy and=20
low-risk.

cheers,
=97ml=97


--Apple-Mail-32-333664776
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
	charset=WINDOWS-1252


On Jan 25, 2007, at 11:12 AM, Alexander Klimetschek wrote:


<excerpt>Mark Lundquist schrieb:

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

</excerpt>

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

</excerpt>

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


<excerpt><excerpt>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.=20
I'm in need of some brilliant ideas here, does somebody have any?

</excerpt>

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.

</excerpt>

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 <italic>ad hoc</italic> 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 <italic>ad hoc</italic> profiles, because this is a very legitimate
measure to preserve build reproducibility in the committer =3D>
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 (<italic>a la</italic> settings.xml) in an
external profile.  It's un-Maveny and inelegant, but it would be
relatively easy and low-risk.


cheers,

=97ml=97


--Apple-Mail-32-333664776--