Groovy magic with Maven POM files

[Jason Dillon]

FYI... the future of Maven3... is very Groovy

http://www.wakaleo.com/blog/237-more-groovy-magic-with-maven-pom-files

--jason

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Jason Dillon schrieb:
> FYI... the future of Maven3... is very Groovy
>
> http://www.wakaleo.com/blog/237-more-groovy-magic-with-maven-pom-files

that looks very good to me.

bye blackdrag


--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-3]

Interesting they've borrowed the syntax from Gradle/Grails

Cheers

On Fri, Oct 30, 2009 at 1:28 PM, Jochen Theodorou <blackdrag@...> wrote:

> Jason Dillon schrieb:
>>
>> FYI... the future of Maven3... is very Groovy
>>
>> http://www.wakaleo.com/blog/237-more-groovy-magic-with-maven-pom-files
>
> that looks very good to me.
>
> bye blackdrag
>
>
> --
> Jochen "blackdrag" Theodorou
> The Groovy Project Tech Lead (http://groovy.codehaus.org)
> http://blackdragsview.blogspot.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>

--
Graeme Rocher
Head of Grails Development
SpringSource - Weapons for the War on Java Complexity
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Guillaume Laforge-2]

Fear of the competition? :-)

On Fri, Oct 30, 2009 at 14:14, Graeme Rocher
<graeme.rocher@...> wrote:

> Interesting they've borrowed the syntax from Gradle/Grails
>
> Cheers
>
> On Fri, Oct 30, 2009 at 1:28 PM, Jochen Theodorou <blackdrag@...> wrote:
>> Jason Dillon schrieb:
>>>
>>> FYI... the future of Maven3... is very Groovy
>>>
>>> http://www.wakaleo.com/blog/237-more-groovy-magic-with-maven-pom-files
>>
>> that looks very good to me.
>>
>> bye blackdrag
>>
>>
>> --
>> Jochen "blackdrag" Theodorou
>> The Groovy Project Tech Lead (http://groovy.codehaus.org)
>> http://blackdragsview.blogspot.com/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>   http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
>
> --
> Graeme Rocher
> Head of Grails Development
> SpringSource - Weapons for the War on Java Complexity
> http://www.springsource.com
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

On Fri, 2009-10-30 at 14:17 +0100, Guillaume Laforge wrote:
> Fear of the competition? :-)

More likely Jason told them what they should do !

> On Fri, Oct 30, 2009 at 14:14, Graeme Rocher
> <graeme.rocher@...> wrote:
> > Interesting they've borrowed the syntax from Gradle/Grails
> >
> > Cheers
> >
> > On Fri, Oct 30, 2009 at 1:28 PM, Jochen Theodorou <blackdrag@...> wrote:
> >> Jason Dillon schrieb:
> >>>
> >>> FYI... the future of Maven3... is very Groovy
> >>>
> >>> http://www.wakaleo.com/blog/237-more-groovy-magic-with-maven-pom-files
> >>
> >> that looks very good to me.

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: [phone], [phone]
41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
London SW11 1EN, UK   m: [phone]   skype: russel_winder

[hdockter]

You can configure a Maven pom with Groovy. So what?

Let's look at what this means. There is a Maven Pom object which which  
is populated by an XML file in Maven 2. In Maven 3 you can populate it  
with an XML or Groovy file. What an achievement ;) That won't solve  
any of the fundamental issues I have with Maven.

Has the model changed for Maven 3? That is the important question.  
Spring has always been very flexible in the way you could declare your  
application context although you had to use XML. This is because they  
have a deep and rich model. If the model sucks and does not let you  
declare what you want to declare, even configuring in LISP won't help  
you ;)

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

On Oct 30, 2009, at 2:17 PM, Guillaume Laforge wrote:

> Fear of the competition? :-)
>
> On Fri, Oct 30, 2009 at 14:14, Graeme Rocher
> <graeme.rocher@...> wrote:
>> Interesting they've borrowed the syntax from Gradle/Grails
>>
>> Cheers
>>
>> On Fri, Oct 30, 2009 at 1:28 PM, Jochen Theodorou  
>> <blackdrag@...> wrote:
>>> Jason Dillon schrieb:
>>>>
>>>> FYI... the future of Maven3... is very Groovy
>>>>
>>>> http://www.wakaleo.com/blog/237-more-groovy-magic-with-maven-pom-files
>>>
>>> that looks very good to me.
>>>
>>> bye blackdrag
>>>
>>>
>>> --
>>> Jochen "blackdrag" Theodorou
>>> The Groovy Project Tech Lead (http://groovy.codehaus.org)
>>> http://blackdragsview.blogspot.com/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>   http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>
>>
>>
>> --
>> Graeme Rocher
>> Head of Grails Development
>> SpringSource - Weapons for the War on Java Complexity
>> http://www.springsource.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
>
> --
> Guillaume Laforge
> Groovy Project Manager
> Head of Groovy Development at SpringSource
> http://www.springsource.com/g2one
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jason Smith-11]

For those of us who use Maven now (and there are - surprisingly - some people who like it), this is pretty good news.

Jason Smith


________________________________________
From: Hans Dockter [mail@...]
Sent: Friday, October 30, 2009 8:58 AM
To: dev@...
Subject: Re: [groovy-dev] Groovy magic with Maven POM files

You can configure a Maven pom with Groovy. So what?

Let's look at what this means. There is a Maven Pom object which which
is populated by an XML file in Maven 2. In Maven 3 you can populate it
with an XML or Groovy file. What an achievement ;) That won't solve
any of the fundamental issues I have with Maven.

Has the model changed for Maven 3? That is the important question.
Spring has always been very flexible in the way you could declare your
application context although you had to use XML. This is because they
have a deep and rich model. If the model sucks and does not let you
declare what you want to declare, even configuring in LISP won't help
you ;)

- Hans
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

On Fri, 2009-10-30 at 15:58 +0100, Hans Dockter wrote:
> You can configure a Maven pom with Groovy. So what?

Actually this is a huge deal.  Being able to use a programmed XML
builder instead of XML directly is a Big Win (tm). (Even if all the
Luddite, XML lovers simply denigrate this change.)

> Let's look at what this means. There is a Maven Pom object which which  
> is populated by an XML file in Maven 2. In Maven 3 you can populate it  
> with an XML or Groovy file. What an achievement ;) That won't solve  
> any of the fundamental issues I have with Maven.

Being able to use Jython, JRuby, Groovy, Clojure, . . . for writing POMs
is a major step forward For Maven (*).  However as you say there are
issues.  I tried using Maven for the new, multi-project Gant build and
after 3 days of banging my head against the wall gave up and switched to
Gradle and had something up and working in 3 hours.  The whole
multi-project system in Gradle is just so much better than Maven -- not
least because you can have all the subproject specifications in the
top-level build.gradle not a static subdirectory in sight (this is a
huge win for me).  So for those who have choice, Gradle beats Maven.
Not everyone has choice though, or they can choose between Maven or
Maven.  For them getting rid of explicitly written XML has to be a big
step forward.

> Has the model changed for Maven 3? That is the important question.  
> Spring has always been very flexible in the way you could declare your  
> application context although you had to use XML. This is because they  
> have a deep and rich model. If the model sucks and does not let you  
> declare what you want to declare, even configuring in LISP won't help  
> you ;)

Clojure rocks.  Definitely the best JVM language.  Of course you have to
like prefix functional programming and parentheses . . .

I think what it would be good to do is to meet the build Framework
competition head on by exposing why Gradle is a better choice than Maven
(or Buildr, or SCons, or Ant (**) ) rather than just denigrating the
opposition.   Let's be positive and constructive about this.

Of course, I think the big loser here is Ant.  There will soon be nigh
on no argument for using Ant.

And I guess Groovy is going to have to have a Groovy POM and a Maven
build? (***)

(*) I wonder if the Ant people will do the same thing or not?

(**) Gant doesn't count here, it no longer considers itself a build
framework.

(***)  Actually I guess we should restart work on the Gradle build for
Groovy now that we have all the new stuff in place.

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: [phone], [phone]
41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
London SW11 1EN, UK   m: [phone]   skype: russel_winder

[hdockter]

On Oct 30, 2009, at 5:23 PM, Russel Winder wrote:

> On Fri, 2009-10-30 at 15:58 +0100, Hans Dockter wrote:
>> You can configure a Maven pom with Groovy. So what?
>
> Actually this is a huge deal.  Being able to use a programmed XML
> builder instead of XML directly is a Big Win (tm). (Even if all the
> Luddite, XML lovers simply denigrate this change.)
>
>> Let's look at what this means. There is a Maven Pom object which  
>> which
>> is populated by an XML file in Maven 2. In Maven 3 you can populate  
>> it
>> with an XML or Groovy file. What an achievement ;) That won't solve
>> any of the fundamental issues I have with Maven.
>

<snip>

>  For them getting rid of explicitly written XML has to be a big
> step forward.

I have a slightly different point of view. Specially for the  
declarative aspects I don't think this alone makes a big difference.

Just to be clear. I haven't made any statement of Maven 3 as a whole.  
I think I have a pretty good idea of what will be in there. But I  
first want to have a beta in my hands before I comment on that. My  
point here is that a Maven 2 model with a thin layer of Groovy coating  
sugar on top, wouldn't change the user experience  significantly .  
People who liked Maven 2 might like it a bit more (other will still  
prefer XML). People who have big issues with Maven 2, would still have  
those issues.

>
>
>> Has the model changed for Maven 3? That is the important question.
>> Spring has always been very flexible in the way you could declare  
>> your
>> application context although you had to use XML. This is because they
>> have a deep and rich model. If the model sucks and does not let you
>> declare what you want to declare, even configuring in LISP won't help
>> you ;)
>
> Clojure rocks.  Definitely the best JVM language.  Of course you  
> have to
> like prefix functional programming and parentheses . . .
>
> I think what it would be good to do is to meet the build Framework
> competition head on by exposing why Gradle is a better choice than  
> Maven
> (or Buildr, or SCons, or Ant (**) ) rather than just denigrating the
> opposition.   Let's be positive and constructive about this.

What do you think I'm doing at all those conferences ;). I fully agree  
that we need a couple of pages where we describe the essence of  
Gradle. This is work in progress and something will hopefully become  
visible next week.

>
> Of course, I think the big loser here is Ant.  There will soon be nigh
> on no argument for using Ant.
>
> And I guess Groovy is going to have to have a Groovy POM and a Maven
> build? (***)
>
> (*) I wonder if the Ant people will do the same thing or not?

As I understand their plans, they will ship Ant 1.8 also with a Groovy  
project builder. Again, I don't think that this will change the Ant  
experience in a fundamental way. Ant will remain a imperative build  
system will all the maintainability issues you currently have with  
larger Ant builds.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

Hans,

On Fri, 2009-10-30 at 18:17 +0100, Hans Dockter wrote:
[ . . . ]
> I have a slightly different point of view. Specially for the  
> declarative aspects I don't think this alone makes a big difference.

I am just a firm believer that human being should never have to write
XML -- it is a language for communication between consenting computers.

Certainly XML can express the declarative data for a build, albeit in a
very clumsy way, but I think algorithmic synthesis of the declarative
data is the crucial distinction that Gradle, Gant and Buildr bring to
the game.
 
> Just to be clear. I haven't made any statement of Maven 3 as a whole.  
> I think I have a pretty good idea of what will be in there. But I  
> first want to have a beta in my hands before I comment on that. My  
> point here is that a Maven 2 model with a thin layer of Groovy coating  
> sugar on top, wouldn't change the user experience  significantly .  
> People who liked Maven 2 might like it a bit more (other will still  
> prefer XML). People who have big issues with Maven 2, would still have  
> those issues.

Indeed.  Apologies if I appeared to put words in your mouth.

[ . . . ]

> What do you think I'm doing at all those conferences ;). I fully agree  
> that we need a couple of pages where we describe the essence of  
> Gradle. This is work in progress and something will hopefully become  
> visible next week.

:-)

We can put the pages on the Gant website as well :-)

[ . . . ]
> > (*) I wonder if the Ant people will do the same thing or not?
>
> As I understand their plans, they will ship Ant 1.8 also with a Groovy  
> project builder. Again, I don't think that this will change the Ant  
> experience in a fundamental way. Ant will remain a imperative build  
> system will all the maintainability issues you currently have with  
> larger Ant builds.

I haven't been following Ant developments recently -- Python has been
paying the bills.  I did moot some time ago that Gant should move to be
a Groovy Ant builder but no-one was positive about it so I dropped it.
Sounds like the Ant people picked up on it and will do it.  If they get
it right then we can probably contemplate deprecating Gant.  Unless of
course they are just integrating Gant into Ant :-)

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: [phone], [phone]
41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
London SW11 1EN, UK   m: [phone]   skype: russel_winder

[Jim White]

Hans Dockter wrote:

> You can configure a Maven pom with Groovy. So what?
>
> Let's look at what this means. There is a Maven Pom object which which  
> is populated by an XML file in Maven 2. In Maven 3 you can populate it  
> with an XML or Groovy file. What an achievement ;) That won't solve  any
> of the fundamental issues I have with Maven.
> ...

Well, it is some sort of an achievement.  Now that POMs will be
expressed as executable code rather than as static data, the structure
of the project won't be inspectable by deterministic means.

To find out what the project's dependencies and build steps are, it will
be necessary to execute an aribitrary big program with unbounded
resource usage.  So we'll be exactly back where we were with make.

In what part of the POM is the dependency on the version of Groovy
stated?  Obviously there must be some way to find out which language
implementation to use before the executable POM is interpreted.

If it is assumed by the configuration of the Maven 3 installation, that
would be a horrible situation.

OTOH, if the Maven 3 build process is going to construct a static POM
and publish that as an artifact, then all this dire warning business can
be ignored.  And I have to figure that is what they'll do.

Jim


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jason Dillon]

On Oct 31, 2009, at 8:11 PM, Jim White wrote:

> Hans Dockter wrote:
>
>> You can configure a Maven pom with Groovy. So what?
>> Let's look at what this means. There is a Maven Pom object which  
>> which  is populated by an XML file in Maven 2. In Maven 3 you can  
>> populate it  with an XML or Groovy file. What an achievement ;)  
>> That won't solve  any of the fundamental issues I have with Maven.
>> ...
>
> Well, it is some sort of an achievement.  Now that POMs will be  
> expressed as executable code rather than as static data, the  
> structure of the project won't be inspectable by deterministic means.
>
> To find out what the project's dependencies and build steps are, it  
> will be necessary to execute an aribitrary big program with  
> unbounded resource usage.  So we'll be exactly back where we were  
> with make.

This is not really the case, there is a very small layer that reads  
various supported pom formats and spits out an  
org.apache.maven.model.Model.


> If it is assumed by the configuration of the Maven 3 installation,  
> that would be a horrible situation.
>
> OTOH, if the Maven 3 build process is going to construct a static  
> POM and publish that as an artifact, then all this dire warning  
> business can be ignored.  And I have to figure that is what they'll  
> do.

Only pom.xml files are ever going to be published.  pom.groovy,  
pom.yml or pom.rb files are simply a nicer format for developers that  
prefer them over the canonical xml.

--jason

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Mike Dillon-4]

begin Jason Dillon quotation:
> This is not really the case, there is a very small layer that reads  
> various supported pom formats and spits out an  
> org.apache.maven.model.Model.

Jim's point remains. How exactly does the build control exactly which
version of Groovy is used to interpret the pom.groovy file?

One example of a place where this could matter is if you're using Groovy
1.6 v. 1.7 and your pom.groovy uses multiple assignment. Even worse
would be a case where a pom.groovy file that works one day stops working
because it had been relying on buggy behavior in the version of Groovy
their script happened to be interpreted with.

None of this is a problem for consumers of the package since the POM
they see is in the canonical XML format, but it has deep implications
for exact reproducibility of builds when the behavior of the build tool
is version-dependent and the necessary version is not included as part
of the project requirements.

You already have this problem to some extent with pom.xml files that
need a certain version of Maven to work properly, but at least the POM
has a way to declare this via the <prerequisites> element. That
mechanism still has its problems because it only allows you to assert a
lower bound and assumes that future versions will be backwards
compatible, but I understand why that compromise was made to avoid
having to make people install 10 different versions of Maven to build 10
different projects. (Yes, I know you can get more deterministic
prerequisite enforcement with the enforcer plugin)

-md

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jim White]

Mike Dillon wrote:

> begin Jason Dillon quotation:
>
>>This is not really the case, there is a very small layer that reads  
>>various supported pom formats and spits out an  
>>org.apache.maven.model.Model.
>
>
> Jim's point remains. How exactly does the build control exactly which
> version of Groovy is used to interpret the pom.groovy file?

I think the answer is that there should be a convenient way to generate
the pom.xml and check that in along with any change to the "source" POM.

Then CI and other users can build reliably.

For folks building from the "source" POM, there could be some metadata
recorded in the pom.xml that records what the dependencies were for
generating it.  The user could then use that information to configure
their environment (and a smart enough Maven 3 could configure itself
from it if asked to).

Jim

> One example of a place where this could matter is if you're using Groovy
> 1.6 v. 1.7 and your pom.groovy uses multiple assignment. Even worse
> would be a case where a pom.groovy file that works one day stops working
> because it had been relying on buggy behavior in the version of Groovy
> their script happened to be interpreted with.
>
> None of this is a problem for consumers of the package since the POM
> they see is in the canonical XML format, but it has deep implications
> for exact reproducibility of builds when the behavior of the build tool
> is version-dependent and the necessary version is not included as part
> of the project requirements.
>
> You already have this problem to some extent with pom.xml files that
> need a certain version of Maven to work properly, but at least the POM
> has a way to declare this via the <prerequisites> element. That
> mechanism still has its problems because it only allows you to assert a
> lower bound and assumes that future versions will be backwards
> compatible, but I understand why that compromise was made to avoid
> having to make people install 10 different versions of Maven to build 10
> different projects. (Yes, I know you can get more deterministic
> prerequisite enforcement with the enforcer plugin)
>
> -md

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jason Dillon]

The version of Groovy is controlled by the language support plugin  
providing the Groovy language features.

--jason


On Nov 1, 2009, at 12:27 AM, Mike Dillon wrote:

> begin Jason Dillon quotation:
>> This is not really the case, there is a very small layer that reads
>> various supported pom formats and spits out an
>> org.apache.maven.model.Model.
>
> Jim's point remains. How exactly does the build control exactly which
> version of Groovy is used to interpret the pom.groovy file?
>
> One example of a place where this could matter is if you're using  
> Groovy
> 1.6 v. 1.7 and your pom.groovy uses multiple assignment. Even worse
> would be a case where a pom.groovy file that works one day stops  
> working
> because it had been relying on buggy behavior in the version of Groovy
> their script happened to be interpreted with.
>
> None of this is a problem for consumers of the package since the POM
> they see is in the canonical XML format, but it has deep implications
> for exact reproducibility of builds when the behavior of the build  
> tool
> is version-dependent and the necessary version is not included as part
> of the project requirements.
>
> You already have this problem to some extent with pom.xml files that
> need a certain version of Maven to work properly, but at least the POM
> has a way to declare this via the <prerequisites> element. That
> mechanism still has its problems because it only allows you to  
> assert a
> lower bound and assumes that future versions will be backwards
> compatible, but I understand why that compromise was made to avoid
> having to make people install 10 different versions of Maven to  
> build 10
> different projects. (Yes, I know you can get more deterministic
> prerequisite enforcement with the enforcer plugin)
>
> -md
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jason Dillon]

On Nov 1, 2009, at 8:41 AM, Jim White wrote:

> Mike Dillon wrote:
>
>> begin Jason Dillon quotation:
>>> This is not really the case, there is a very small layer that  
>>> reads  various supported pom formats and spits out an  
>>> org.apache.maven.model.Model.
>> Jim's point remains. How exactly does the build control exactly which
>> version of Groovy is used to interpret the pom.groovy file?
>
> I think the answer is that there should be a convenient way to  
> generate the pom.xml and check that in along with any change to the  
> "source" POM.

There is a bin/translate command which takes an input pom and and  
output pom.  So you can easily:

./bin/translate pom.groovy pom.xml

or

./bin/translate pom.xml pom.groovy

or even:

./bin/translate pom.groovy pom.yml

The later converts the Groovy pom to a Yaml pom.  It can translate  
between any supported/installed language plugin format.

--jason

> Then CI and other users can build reliably.
>
> For folks building from the "source" POM, there could be some  
> metadata recorded in the pom.xml that records what the dependencies  
> were for generating it.  The user could then use that information to  
> configure their environment (and a smart enough Maven 3 could  
> configure itself from it if asked to).
>
> Jim
>
>> One example of a place where this could matter is if you're using  
>> Groovy
>> 1.6 v. 1.7 and your pom.groovy uses multiple assignment. Even worse
>> would be a case where a pom.groovy file that works one day stops  
>> working
>> because it had been relying on buggy behavior in the version of  
>> Groovy
>> their script happened to be interpreted with.
>> None of this is a problem for consumers of the package since the POM
>> they see is in the canonical XML format, but it has deep implications
>> for exact reproducibility of builds when the behavior of the build  
>> tool
>> is version-dependent and the necessary version is not included as  
>> part
>> of the project requirements.
>> You already have this problem to some extent with pom.xml files that
>> need a certain version of Maven to work properly, but at least the  
>> POM
>> has a way to declare this via the <prerequisites> element. That
>> mechanism still has its problems because it only allows you to  
>> assert a
>> lower bound and assumes that future versions will be backwards
>> compatible, but I understand why that compromise was made to avoid
>> having to make people install 10 different versions of Maven to  
>> build 10
>> different projects. (Yes, I know you can get more deterministic
>> prerequisite enforcement with the enforcer plugin)
>> -md
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jason Dillon]

On Oct 30, 2009, at 9:58 PM, Hans Dockter wrote:
> You can configure a Maven pom with Groovy. So what?
>
> Let's look at what this means. There is a Maven Pom object which  
> which is populated by an XML file in Maven 2. In Maven 3 you can  
> populate it with an XML or Groovy file. What an achievement ;) That  
> won't solve any of the fundamental issues I have with Maven.

Have you collected a concise list of reasons why you have issues with  
Maven somewhere?  I'd be interested to read it...


> Has the model changed for Maven 3? That is the important question.  
> Spring has always been very flexible in the way you could declare  
> your application context although you had to use XML. This is  
> because they have a deep and rich model. If the model sucks and does  
> not let you declare what you want to declare, even configuring in  
> LISP won't help you ;)

What part of the Maven model are you talking about?

--jason

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jason Dillon]

On Oct 30, 2009, at 8:57 PM, Russel Winder wrote:
> On Fri, 2009-10-30 at 14:17 +0100, Guillaume Laforge wrote:
>> Fear of the competition? :-)
>
> More likely Jason told them what they should do !

More than that, I wrote it... so I guess I did tell myself what to  
do. :-P  Initially it started along the lines of Graven (http://code.google.com/p/graven/ 
), using MarkupBuilder, to generate XML and then go the default  
pom.xml route.  But after I spent several days trying to figure out  
how to make a rich builder (using FactoryBuilderSupport) the impl  
changed dramatically.

Builders are great, but I wish there were better javadocs and non-
trivial examples on how to build a builder, would have saved me  
several days...

--jason


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jason Dillon]

I didn't borrow any syntax, its just a builder :-P

--jason


On Oct 30, 2009, at 8:14 PM, Graeme Rocher wrote:

> Interesting they've borrowed the syntax from Gradle/Grails
>
> Cheers
>
> On Fri, Oct 30, 2009 at 1:28 PM, Jochen Theodorou  
> <blackdrag@...> wrote:
>> Jason Dillon schrieb:
>>>
>>> FYI... the future of Maven3... is very Groovy
>>>
>>> http://www.wakaleo.com/blog/237-more-groovy-magic-with-maven-pom-files
>>
>> that looks very good to me.
>>
>> bye blackdrag
>>
>>
>> --
>> Jochen "blackdrag" Theodorou
>> The Groovy Project Tech Lead (http://groovy.codehaus.org)
>> http://blackdragsview.blogspot.com/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>   http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
>
> --
> Graeme Rocher
> Head of Grails Development
> SpringSource - Weapons for the War on Java Complexity
> http://www.springsource.com
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jim White]

Jason Dillon wrote:

> On Nov 1, 2009, at 8:41 AM, Jim White wrote:
>
>> Mike Dillon wrote:
>>
>>> begin Jason Dillon quotation:
>>>
>>>> This is not really the case, there is a very small layer that  
>>>> reads  various supported pom formats and spits out an  
>>>> org.apache.maven.model.Model.
>>>
>>> Jim's point remains. How exactly does the build control exactly which
>>> version of Groovy is used to interpret the pom.groovy file?
>>
>>
>> I think the answer is that there should be a convenient way to  
>> generate the pom.xml and check that in along with any change to the  
>> "source" POM.
>
>
> There is a bin/translate command which takes an input pom and and  
> output pom.  So you can easily:
>
> ./bin/translate pom.groovy pom.xml
>
> or
>
> ./bin/translate pom.xml pom.groovy
>
> or even:
>
> ./bin/translate pom.groovy pom.yml
>
> The later converts the Groovy pom to a Yaml pom.  It can translate  
> between any supported/installed language plugin format.

Okay.  But as I say below, the translation process is better if it is
automated and includes metadata so that once performed can be repeated
using the same configuration.

The translate command should put a translate step into the pom.xml, so
that simply doing "m3" will check whether the pom.xml is out-of-date
wrt. the source pom, and if it is then use the right plug-in to
retranslate the pom.xml.

So actually there is no reason for the m3 command to do anything but
process pom.xml.  Bring in a non-XML source POM using the translate
command, then after that m3 will always do the right thing.

Jim

> --jason
>
>
>> Then CI and other users can build reliably.
>>
>> For folks building from the "source" POM, there could be some  
>> metadata recorded in the pom.xml that records what the dependencies  
>> were for generating it.  The user could then use that information to  
>> configure their environment (and a smart enough Maven 3 could  
>> configure itself from it if asked to).
>>
>> Jim
>>
>>> One example of a place where this could matter is if you're using  
>>> Groovy
>>> 1.6 v. 1.7 and your pom.groovy uses multiple assignment. Even worse
>>> would be a case where a pom.groovy file that works one day stops  
>>> working
>>> because it had been relying on buggy behavior in the version of  Groovy
>>> their script happened to be interpreted with.
>>> None of this is a problem for consumers of the package since the POM
>>> they see is in the canonical XML format, but it has deep implications
>>> for exact reproducibility of builds when the behavior of the build  tool
>>> is version-dependent and the necessary version is not included as  part
>>> of the project requirements.
>>> You already have this problem to some extent with pom.xml files that
>>> need a certain version of Maven to work properly, but at least the  POM
>>> has a way to declare this via the <prerequisites> element. That
>>> mechanism still has its problems because it only allows you to  assert a
>>> lower bound and assumes that future versions will be backwards
>>> compatible, but I understand why that compromise was made to avoid
>>> having to make people install 10 different versions of Maven to  
>>> build 10
>>> different projects. (Yes, I know you can get more deterministic
>>> prerequisite enforcement with the enforcer plugin)
>>> -md

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email