[groovy-user] Groovy-Eclipse compiler plugin for Maven replacing gmaven

[Kenneth Kousen]

There have been some hints on this list that the Groovy-Eclipse compiler plugin for Maven http://groovy.codehaus.org/Groovy-Eclipse+compiler+plugin+for+Maven is eventually going to become the primary option for using Groovy with Maven.

1. Is that true?

2. When is it likely to happen? Will it be part of the Groovy 2.0 transition, or unrelated?

3. Is GMaven under development any more?

4. Why doesn't either option generate a decent Eclipse project? When I run the eclipse:eclipse target, Eclipse doesn't even understand that the result is a Groovy project, much less get the paths configured properly. It's a real disaster, especially considering how easy that is to do with Gradle.

I have some clients that have to use Maven instead of Gradle, and they're having a tough time introducing Groovy because the Maven support is, at best, awkward, and, at worst, unusable.

Am I missing something?

Thanks,

Ken

--
Kenneth A. Kousen
President
Kousen IT, Inc.

[Sebastien Blanc]

Maybe you should ask this question on the groovy-eclipse-plugin ML to
get more answers ? (eclipse-p...@groovy.codehaus.org)
Best Regards,
Seb

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

http://xircles.codehaus.org/manage_email

[Guillaume Laforge]

Hi Ken,

On Mon, May 21, 2012 at 1:07 PM, Kenneth Kousen <ken.k...@kousenit.com> wrote:

There have been some hints on this list that the Groovy-Eclipse compiler plugin for Maven http://groovy.codehaus.org/Groovy-Eclipse+compiler+plugin+for+Maven is eventually going to become the primary option for using Groovy with Maven.

1. Is that true?

GMaven and the Groovy Eclipse compiler are two independent projects, so one can't really say that one will supersede the other or anything like that.

So I can't say if the Eclipse variant will be the "primary" option for using Groovy with Maven.

I quite recently updated a project (Groovy XML-RPC) to use the Groovy Eclipse compiler maven plugin, which worked "better" (I could actually build the project) for my case than the GMaven plugin, but that's just anecdotical evidence, so your mileage may vary.

 

2. When is it likely to happen? Will it be part of the Groovy 2.0 transition, or unrelated?

It's unrelated, since the Maven integration is not really part of the Groovy distribution itself.

In general, I'd suggest you try both options, and see what works best for your own project.

 

3. Is GMaven under development any more?

Keegan (in CC) is the one maintaining the GMaven plugin, whereas Andrew (in CC as well) is the one who takes care of the Groovy Eclipse maven plugin. Both can give you a bit more details about the status of these projects.

 

4. Why doesn't either option generate a decent Eclipse project? When I run the eclipse:eclipse target, Eclipse doesn't even understand that the result is a Groovy project, much less get the paths configured properly. It's a real disaster, especially considering how easy that is to do with Gradle.

I'm not an expert, so I'll let either Andrew or Keegan answer here.

 

I have some clients that have to use Maven instead of Gradle, and they're having a tough time introducing Groovy because the Maven support is, at best, awkward, and, at worst, unusable.

Am I missing something?

Me? :-D

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

[Andrew Eisenberg]

I'll just add a but to Guillaume's great answers.

>> 3. Is GMaven under development any more?
>
>
> Keegan (in CC) is the one maintaining the GMaven plugin, whereas Andrew (in
> CC as well) is the one who takes care of the Groovy Eclipse maven plugin.
> Both can give you a bit more details about the status of these projects.

I can't speak about gmaven, but groovy-eclipse-compiler is still being
maintained. We will release another version of it that supports
Groovy 2.0 when we release groovy-eclipse 2.7.0, sometime around the
end of June.

>> 4. Why doesn't either option generate a decent Eclipse project? When I run
>> the eclipse:eclipse target, Eclipse doesn't even understand that the result
>> is a Groovy project, much less get the paths configured properly. It's a
>> real disaster, especially considering how easy that is to do with Gradle.

The behavior you are seeing is the expected, default behavior of
maven. There are two ways to solve your problem:

1. Use the build-helper-maven-plugin to add the correct source folders
and project nature. (this is a bit of a pain to configure properly
and adds a bunch of cruft to your pom that is eclipse specific, so
many people don't like this). See here:
http://mojo.codehaus.org/build-helper-maven-plugin/

2. Use m2e, the eclipse tooling for maven. It is available on the
indigo update site, the eclipse market place, and here:
http://eclipse.org/m2e. To use this properly, you will have to also
install the groovy-eclipse configurator, which let's your eclipse
install know about groovy/maven projects. The configurator is
available from the groovy-eclipse update site.

There is, of course, a third option. Use gradle. :)

I hope this helps get you started. Feel free to ask more questions if
anything doesn't make sense or you can't quite configure things
properly.

[Keegan Witt]

Thanks for CCing me on this.  I haven't checked the Groovy lists in a while.  There does seem to be a notion that the GMaven project is dead.  I think this is mostly due to a long inactive period it recenlty went through (which is what got me on board) and maybe that it's not a super-active project (because its pretty much whatever time I can spare).  I should probably write up a little something to help people choose their build tool for working with Groovy.

For the moment, I don't see either plugin going away.  It'd be nice to combine them into a single solution, but I'm not sure how that would work or if it is even possible, given the somewhat different goals of each respective project.  While I've not have any of the stub generation issues that seem to have been very frustrating for some (OCLC, where I work, uses the GMaven plugin without issue), for working with Eclipse, the Groovy-Eclipse compiler might be the better option.  As someone that hasn't used Eclipse in some time, I can't really comment on that.  There are some advantages GMaven has over the Groovy-Eclipse compiler that might important depending on your use case (and several of these are documented on Groovy-Eclipse compiler's page):  you can use it to build Maven plugins, you can specify groovyc options to pass to the Groovy compiler, you can execute Groovy scripts in a pom, you can specify the exact version of Groovy to use for compiling (usually doesn't matter except there's breaking changes), you can have joint Scala/Java/Groovy projects, you have the choice between the Eclipse compiler and the standard Java one (if I understand how groovy-eclipse works they cannot do this currently, though I'm not sure if it matters in practice), and lastly you can run the Groovy shell or console without any additional installation or configuration.  If none of these features really matter to you and you're not integrating with Eclipse, either option (or even groovyc with throug the antrun plugin) should work fine.

I'm fine with the Groovy-Eclipse compiler becoming the standard Maven way of doing things, but there are some design issues that would have to be overcome.  The strength of the Groovy-Eclipse compiler option is that it avoids stub generation, but there are cases where you actually need the source (such as when building a Maven plugin since they use Commons Attributes instead of Java5 annotations to be compatible with older versions of Java).  Another example is if you want to use Groovy, Scala, and Java together, Scala would currently need Groovy's stubs unless support for Scala were also added to the JDT (if I'm understanding this right).  This being the case, could/should a single tool provide two different ways of handling joint compilation?  Do you have thoughts on this Andrew?

As part of a larger discussion on the Groovy compiler ecosystem (as I think has been stated by myself and Jason Dillon), I think the future of compiling Groovy should be tied to the modularization effort.  That is, there should be a single core module that is used by Maven (be that GMaven or groovy-eclipse), IDEs, Ant's groovyc, etc to provide a solid and uniform compiling experience.  This means creating a single compilation API that won't change from version to version.  Currently there are slight variations between each tool (both groovy-eclipse and GMaven have at least one class from the core that is patched) and between the various versions of Groovy that the tool might want to support that seem to make the whole thing kinda brittle.  But I don't have much experience with this stuff and don't know how realistic this is to expect and what impact this would have on groovy-eclipse.

-Keegan

[Andrew Eisenberg]

> For the moment, I don't see either plugin going away.  It'd be nice to
> combine them into a single solution, but I'm not sure how that would work or
> if it is even possible, given the somewhat different goals of each
> respective project.  While I've not have any of the stub generation issues
> that seem to have been very frustrating for some (OCLC, where I work, uses
> the GMaven plugin without issue), for working with Eclipse, the
> Groovy-Eclipse compiler might be the better option.  As someone that hasn't
> used Eclipse in some time, I can't really comment on that.  There are some
> advantages GMaven has over the Groovy-Eclipse compiler that might important
> depending on your use case (and several of these are documented on
> Groovy-Eclipse compiler's page):  you can use it to build Maven plugins, you
> can specify groovyc options to pass to the Groovy compiler, you can execute
> Groovy scripts in a pom, you can specify the exact version of Groovy to use
> for compiling (usually doesn't matter except there's breaking changes), you
> can have joint Scala/Java/Groovy projects, you have the choice between the
> Eclipse compiler and the standard Java one (if I understand how
> groovy-eclipse works they cannot do this currently, though I'm not sure if
> it matters in practice), and lastly you can run the Groovy shell or console
> without any additional installation or configuration.  If none of these
> features really matter to you and you're not integrating with
> Eclipse, either option (or even groovyc with throug the antrun plugin)
> should work fine.

If the groovy-eclipse-compiler (optionally) produced stubs, then
several of these problems would go away. With the stubs, the
groovy-eclipse-compiler would be able to do things like build plugins,
produce groovydoc, etc. It may even be possible to build
java-groovy-scala projects, but I am not sure about that.

There would be a bit of work involved with stub generation, but since
the stubs would be coming from a more semantically rich model of the
groovy code than gmaven has access to, many of the stub problems that
gmaven could be avoided if the groovy-eclipse-compiler were used.

Surprisingly, we don't already have an issue logged for this in jira,
so I created one:
https://jira.codehaus.org/browse/GRECLIPSE-1438

This is not something that I will likely be able to get to in the near
future, but I will gladly mentor someone produce a (high-quality)
patch for this.

> I'm fine with the Groovy-Eclipse compiler becoming the standard Maven way of
> doing things, but there are some design issues that would have to be
> overcome.  The strength of the Groovy-Eclipse compiler option is that it
> avoids stub generation, but there are cases where you actually need the
> source (such as when building a Maven plugin since they use Commons
> Attributes instead of Java5 annotations to be compatible with older versions
> of Java).  Another example is if you want to use Groovy, Scala, and Java
> together, Scala would currently need Groovy's stubs unless support for Scala
> were also added to the JDT (if I'm understanding this right).  This being
> the case, could/should a single tool provide two different ways of handling
> joint compilation?  Do you have thoughts on this Andrew?

Inside of maven, scala code is compiled differently than it is inside
of eclipse. So, it is theoretically possible to get the scala-groovy
projects compilable in maven as long as scala can compile against
stubs. (I think this is already possible using gmaven...) We just
need to create the feature in groovy-eclipse-compiler. Note that this
would only work when running maven on the command line, and not inside
of eclipse.

> As part of a larger discussion on the Groovy compiler ecosystem (as I think
> has been stated by myself and Jason Dillon), I think the future of compiling
> Groovy should be tied to the modularization effort.  That is, there should
> be a single core module that is used by Maven (be that GMaven or
> groovy-eclipse), IDEs, Ant's groovyc, etc to provide a solid and uniform
> compiling experience.  This means creating a single compilation API that
> won't change from version to version.  Currently there are slight variations
> between each tool (both groovy-eclipse and GMaven have at least one class
> from the core that is patched) and between the various versions of Groovy
> that the tool might want to support that seem to make the whole thing kinda
> brittle.  But I don't have much experience with this stuff and don't know
> how realistic this is to expect and what impact this would have on
> groovy-eclipse.

Compared to maven and ant, Groovy-Eclipse has very different
requirements as to how to interact with code and what kind of model
should be exposed. Maven and ant are just batch compilers. They take
source and produce byte code. Groovy-Eclipse on the other hand needs
to do much more with source code (eg- create models with enough detail
to support refactoring, searching and navigation). So, groovy-eclipse
needs much more api exposed than gmaven does.

This may not really answer your question, but does explain the reason
why there are differences between the two tools.

[Kenneth Kousen]

Let me ask a simpler question. Why are there two gmaven artifacts? One is under the group id org.codehaus.gmaven:

http://mvnrepository.com/artifact/org.codehaus.gmaven/gmaven/1.4

and the other is under the group id org.codehaus.groovy.maven:

http://mvnrepository.com/artifact/org.codehaus.groovy.maven/gmaven/1.0

Which is the preferred one?

Thanks,

Ken

[Guillaume Laforge]

GMaven became a top level project at Codehaus and changed its group id.

Use the one with the highest version number.

Guillaume

[Evgeny Goldin]

Hi,

Is there any information available regarding GMaven release supporting
Groovy 2.0? Tried using version 1.4 but it failed to work with
groovy-all:2.0.0 :(

Thanks!

-----
Best regards,

Evgeny

evgeny-goldin.com

--
View this message in context: http://groovy.329449.n5.nabble.com/Groovy-Eclipse-compiler-plugin-for-Maven-replacing-gmaven-tp5709858p5710467.html
Sent from the groovy - user mailing list archive at Nabble.com.

[Guillaume Laforge]

Hi Evgeny,

I think I had tried with one of the RCs (or was it a beta?) and it worked, when GMaven is configured properly.

It's supposed to work when using the right provider, when putting the groovy dependency twice, in your project and in the plugin configuration.

What does your pom look like?

Guillaume

[Evgeny Goldin]

Right now GMaven 1.4 declares its dependency on "2.0.0-beta-2". Here's
https://github.com/evgeny-goldin/maven-plugins/blob/44c4867ea6b6acf13a24d84266b9d1ca1aca4bbd/pom.xml#L182
my POM and when run it throws the following NPE (
http://groovy.329449.n5.nabble.com/file/n5710471/log.txt log.txt ):

-----
Best regards,

Evgeny

evgeny-goldin.com

--

View this message in context: http://groovy.329449.n5.nabble.com/Groovy-Eclipse-compiler-plugin-for-Maven-replacing-gmaven-tp5709858p5710471.html

[Guillaume Laforge]

When I tried, I got it working by excluding the 2.0.0-beta-2 version from my dependencies, as far as I recall.

Could you try that?

[Evgeny Goldin]

I already excluded beta from plugin's dependencies and replaced it with
release. If I delete
".m2/repository/org/codehaus/groovy/groovy-all/2.0.0-beta-2/" and run the
build then only the POM ("2.0.0-beta-2/groovy-all-2.0.0-beta-2.pom") gets
downloaded so no jar is brought, meaning it's not used.

-----
Best regards,

Evgeny

evgeny-goldin.com

--

View this message in context: http://groovy.329449.n5.nabble.com/Groovy-Eclipse-compiler-plugin-for-Maven-replacing-gmaven-tp5709858p5710475.html

[Guillaume Laforge]

Okay, well, I'll let Keegan jump in the discussion to shed more light in this topic.

[Keegan Witt]

Sorry for not replying earlier.  I don't get much done when I'm visiting the folks.  Please do use the GMaven user list (us...@gmaven.codehaus.org) for questions about GMaven.  I monitor those lists a lot more than I do the Groovy lists.  After I finish up things for the 1.5 release, I'm going to try to improve documentation on this, since it seems to confuse a fair number of people (looking back at some of my older Groovy projects, it looks like I was one of them).  Do note that you cannot currently use the invoke dynamic feature of 2.0.  I'm working on this and a few other issues for our 1.5 release which I hope to push out in about a week.  In the mean time, here is how you could use 2.0 release with the 1.4 version of the plugin:

 

<properties>

  <gmavenVersion>1.4</gmavenVersion>
  <gmavenProviderSelection>2.0</gmavenProviderSelection>
  <groovyVersion>2.0.0</groovyVersion>

</properties>

<dependencies>
  <dependency>
    groupId>org.codehaus.groovy</groupId>
    artifactId>groovy-all</artifactId>
    <version>${groovyVersion}</version>
  dependency>
</dependencies>

<build>

  <plugins>

    <plugin>

      <groupId>org.codehaus.gmaven</groupId>
        <artifactId>gmaven-plugin</artifactId>
        <version>${gmavenVersion}</version>
        <configuration>
          <providerSelection>${gmavenProviderSelection}</providerSelection>
          <sourceEncoding>UTF-8</sourceEncoding>
        </configuration>
        <executions>
          <execution>
            <goals>
              <goal>generateStubs</goal>
              <goal>compile</goal>
              <goal>generateTestStubs</goal>
              <goal>testCompile</goal>
            </goals>
          </execution>
        </executions>
        <dependencies>
         <dependency>
           <groupId>org.codehaus.groovy</groupId>
           <artifactId>groovy-all</artifactId>
           <version>${groovyVersion}</version>
         </dependency>
       </dependencies>

    </plugin>

  </plugins>

</build>

 

-Keegan

[Andrew Eisenberg]

Not trying to upstage Keegan's great work on GMaven, but I have just
released the Groovy-eclipse-compiler snapshot for 2.7.0, which
includes Groovy 2.0 support. See here for more information:

http://groovy.codehaus.org/Groovy-Eclipse+compiler+plugin+for+Maven

You must use the following repository to access the snapshot:
http://nexus.codehaus.org/snapshots/

For this version, if left unspecified, the groovy version being
compiled against is 2.0. If you want to compile against 1.8.6 or
1.7.10, then you must specify this explicitly. See the link above for
more details and feedback is appreciated.