Aighty... well, 3 days... and 3 votes later:

+1 "Yeah, baby, yeah (release it)": jason (me), jeff, Garvin

No jive smack or sharks with frickin' laser beams were busted out.

* * *

A user (wow neat to know there are actually users), Andrew
Perepelytsya reported some minor issues with the Groovy plugin
extractor (thanks for that btw) and how it was causing conflicts with
the Java plugin extractor.

The changes were relatively minor, so I fixed them, and plan to
include them in this release, jiras are here:

   http://jira.codehaus.org/browse/MGROOVY-40
   http://jira.codehaus.org/browse/MGROOVY-41

AFAICT these fixes only make things work better, all of the plugins
I'm written with this stuff are happy, and the integration tests just
keep growing, and they are all happy too.

So, rather than re-roll the vote, and wait more days (er would be more
like a week due to the weekend I'd imagine) I'm just going to proceed
and release it... unless someone balks in short-term.

It's freedom, baby, yeah!

:-P

--jason


On 5/15/07, Jason Dillon <[EMAIL PROTECTED]> wrote:

Folks, I've been working more on the Groovy integration with Maven 2 and I
think its time again for another release.

The major changes in this release are for supporting Maven plugins
implemented in Groovy (Yeah, baby, yeah).  With this, a few more modules
were added, which were organized into a new groupId
"org.codehaus.mojo.groovy".  You can see the layout here:

    http://svn.codehaus.org/mojo/trunk/mojo/groovy/

<snip>
Release Notes - Maven 2.x Groovy Plugin - Version 1.0-alpha-3

** Bug
    * [MGROOVY-29] - Property resolving in the 'project' delegate is not
working correctly when run from the Maven reactor

** Improvement
    * [MGROOVY-24] - When maven.test.skip=true skip groovy:testCompile
    * [MGROOVY-28] - Re-package all Groovy modules into
org.codehaus.mojo.groovy
    * [MGROOVY-30] - Fix dependency injection of the plexus
GroovyComponentFactory
    * [MGROOVY-31] - Add ant = new AntBuilder() to groovy:execute
    * [MGROOVY-32] - Maven ${} resolution of inlined Groovy scripts is
causing problems with GStrings
    * [MGROOVY-33] - Allow optional handling of AssertionError (which is
produced by Groovy's assert keyword) to omit evil stacktrace
    * [MGROOVY-34] - Hook up to the Plexus/Maven ExpressionEvaluator muck
for property expansion
    * [MGROOVY-36] - Hookup AntBuilder's output to Maven's plugin Log
    * [MGROOVY-37] - Create plugin development guide for implementing
plugins in Groovy

** New Feature
    * [MGROOVY-1] - Support mojo plugin.xml generation for Groovy mojos
    * [MGROOVY-26] - Add an archetype for groovy-mojo projects
    * [MGROOVY-27] - Split up the mojo support from the
compilation/execution support
    * [MGROOVY-35] - Add fail() helper to GroovyMojoSupport
</snip>

The new site has just been deployed here:

    http://mojo.codehaus.org/groovy/

And includes the new guide to developing plugins with Groovy:


 http://mojo.codehaus.org/groovy/guide-groovy-plugin-development.html

Snapshots have been published here with the latest and greatest Groovy bits:


 http://snapshots.repository.codehaus.org/org/codehaus/mojo/groovy/

Aside from the groupId change, the other significant change was to the
groovy:execute goal and how the source code was specified.  Previously this
was the syntax:

<configuration>
    <source>
        <body>
            println "Groovy baby!"
        </body>
    </source>
</configuration>

This was using a nested type under <source> to determine the type, one of
<body>, <file> or <url>.  The new syntax does not need the child element, so
one can:

<configuration>
    <source>
        println "Groovy baby!"
    </source>
</configuration>

or:

<configuration>

 <source>${pom.basedir}/src/main/groovy/whatever.groovy</source>
</configuration>

Both syntaxes for configuration are supported in this release, though when
1.0-beta-1 roles around the nested element syntax will be dropped.

Other significant improvements are:

 * Allowing GStrings to be used in inline source bodies
 * Improved property resolution which behaves normally in the reactor and
supports the same expansion of variables as plugin configuration (ie.
${session} will resolve to a MavenSession, etc).

I think this is going to be the last of the alpha releases, next release is
probably going to be 1.0-beta-1.

 * * *

[+1]  Yeah, baby, yeah (release it)
[+0]  Begin the unnecessarily slow-moving dipping mechanism! (eh, whatever)
[-1] Sorry, I have one simple request. And that is to have sharks with
frickin' laser beams attached to their heads! (don't release)

Vote will conclude on Friday 10pmish (pacific).

Please vote :-)

--jason



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

   http://xircles.codehaus.org/manage_email

Reply via email to