Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Received-SPF: pass (athena.apache.org: domain of nicolas.deloof@gmail.com
 designates 72.14.220.159 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=f+XrpW4GaPMnGpKEcrLpaN4EGHcKL2VhhBAkXIyCgoAInkSnCpesEOrI8EbCfJHZAR
         D13hmI1nY4+RM0hjYlNEk7fqlca4V8ZE2igfXl/9RP6+WCuVUbXjl9wkSGf/kszC5Oqa
         eAtZ4CMcOzdhnLv7zAPo3Tu9Kcc2ZHjJS3x6E=
MIME-Version: 1.0
In-Reply-To: <262c6c680905190009ucdfccd0l43ea1a51d2904863@mail.gmail.com>
References: <4A121D65.5000806@commonjava.org>
 <262c6c680905190009ucdfccd0l43ea1a51d2904863@mail.gmail.com>
From: nicolas de loof <nicolas.deloof@gmail.com>
Date: Wed, 20 May 2009 10:10:18 +0200
Message-ID: <4c39e3030905200110u56a80244gffb7d82d8ec39507@mail.gmail.com>
Subject: Re: [PROPOSAL] POM Version-Expression Transformation
To: Maven Developers List <dev@maven.apache.org>
Content-Type: multipart/alternative; boundary=000e0cd28956072f75046a53905b

--000e0cd28956072f75046a53905b
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I like the idea to have a new plugin normalize the POM before it gets
installed / deployed
This could be used also to translate the project POM from another XML schema
version / alternative language (groovy, json, or whatever) to 4.0.0
retro-compatible POM before beeing made public. This is not the subject of
your proposal, but with such a POM Transformation plugin attached to all
lifecycle we could open the POM format to enhancements (see for example the
current discution on apache-commons about commons-logging global exclusion,
or the proposal for an attribute-based 4.1.0 schema)

Cheers,
Nicolas


2009/5/19 Arnaud HERITIER <aheritier@gmail.com>

> Thx a lot John for this good sum-up about this issue.Seing your thoughts
> about how to fix it, I understand that we have few solutions.
> You are talking about Maven 3.0. How will it handle this case ?
> Can't we reuse something from it ?
>
> Arnaud
>
> On Tue, May 19, 2009 at 4:45 AM, John Casey <jdcasey@commonjava.org>
> wrote:
>
> > I've been grappling with version-expression interpolation since before
> > Maven 2.1.0 (See MNG-3057, MNG-4140, and now MNG-4167). It seems that
> doing
> > this transformation within an ArtifactTransformation implementation is a
> > flawed concept, since it means that plugins are using old content when
> they
> > produce derivative files/metadata from a POM that contains version
> > expressions.
> >
> > I've written up my thoughts on what exactly the problem is here, what I
> see
> > as our options for solving it, and how I think we ought to proceed. You
> can
> > find them here:
> >
> >
> http://docs.codehaus.org/display/MAVEN/Transforming+POM+Version+Expressions
> >
> > Please, read it over and let me know what you think. If you have a
> > completely different direction you think the solution should go, I want
> to
> > hear from you! If you have something you think I haven't considered in
> this
> > write-up, say so. I took a shot at fixing the version-expression problem
> in
> > 2.1.0, and opened up a pretty big bug for projects that want GPG
> signatures
> > of their POMs. I'd rather not repeat that mistake.
> >
> > Thanks!
> >
> > -john
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> --
> Arnaud
>

--000e0cd28956072f75046a53905b--