Well, I think I've got the 3 votes, assuming I can include myself...
or did I forget to vote again... hrm.
+1
Though, it was just called to my attention that there is a wee bug in
the Groovy plugin descriptor extractor, which causes problems when
you have both Groovy and Java mojos defined in the same project:
http://jira.codehaus.org/browse/MGROOVY-40
So, maybe there will be another alpha after this after all...
--jason
On May 18, 2007, at 1:18 PM, Garvin LeClaire wrote:
I don't think it would be right if I stuff the ballot box
;-o)
--
Regards,
Garvin LeClaire
[EMAIL PROTECTED]
On 5/18/07, Jason Dillon <[EMAIL PROTECTED]> wrote:
Any more votes?
--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
