groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keegan Witt <>
Subject Re: Building Groovy with Maven?
Date Tue, 19 May 2015 19:30:21 GMT
I give this link to everyone that asks this question:

Edit mercilessly.


On Tue, May 19, 2015 at 3:27 PM, Winnebeck, Jason <> wrote:

> I recommend gmavenplus. I've used GMaven (before it was deprecated), the
> groovy-eclipse-compiler, and gmavenplus. I'm using gmavenplus for all of my
> projects now that aren't Gradle. The reason why I didn't like
> groovy-eclipse-compiler is that I found differences quite often in
> @CompileStatic code between groovy and groovy-eclipse compiler, and until
> very recently Intellij compiled with groovy only, so I'd have situations
> where IntelliJ-compiled code worked and Maven-compiled code didn't or
> vice-versa. Now this was in the Groovy 2.0/2.1 days when static compilation
> was very, very rough. The other major issue I had was that
> groovy-eclipse-compiler lagged significantly behind groovyc because it was
> a fork, and due to the rough static compilation issues I was upgrading as
> soon as a 2.1.x came out.
> If groovy-eclipse-compiler has fixed the freshness issue and is perfectly
> consistent with groovyc, and now that IntelliJ can use
> groovy-eclipse-compiler too (and Eclipse of course) so you can compile in
> IDE same as Maven, then it could be a better sell than gmaven because it
> doesn't require stubs when compiling groovy and java in the same jar. If
> your project is all Groovy source, then I'm not sure there is any advantage
> to one way or the other.
> Jason
> -----Original Message-----
> From: Henrik Martin []
> Sent: Tuesday, May 19, 2015 3:20 PM
> To:
> Subject: Building Groovy with Maven?
> Hi there. I'm working on a product that consists of a mix of Java and
> Grails 2.X projects, all built with Maven. The Grails code is in the
> process of being migrated to 3.0 and Maven is getting replaced by Gradle,
> but that hasn't happened yet. I'm writing some tools in Groovy, and I'm
> using Gradle to build them. Now I'm in this situation where one of the
> legacy Java projects needs to use some of the new Groovy utilities. I
> solved this by having the Bamboo CI server build a "fat jar" of the Groovy
> code first (using Gradle), and then simply declaring the dependency to the
> fat jar in the pom.xml file in the Java project.
> Certainly not ideal, but the Java project is going away in a few months,
> and as mentioned, Maven is getting replaced by Gradle for the entire
> project, so this is a short-lived temporary kludge (yeah, right...).
> Then I thought that maybe I should just keep a pom.xml file in the Groovy
> project, basically duplicating the dependencies from build.gradle, so that
> I can build the jar produced by the Groovy project either with Maven or
> Gradle. Neither of these solutions are desirable, but I can't really think
> of anything better at the moment.
> So, if I were to go down the path of trying to build the Groovy project
> with Maven, it comes down to using either GMaven, or the groovy-eclipse
> Maven plugin (maybe there are other alternatives too?). While searching for
> more info, all I come across are some blog posts and stackoverflow articles
> that are a couple of years old. I guess that means that a lot of shops have
> migrated to Gradle :-) Anyway, I just wanted to ask if anyone has a good
> recommendation for either. I don't want to spend a lot of time/effort on
> this, but I'd like to know which approach would be the least painful in
> this situation before I do any work on it. It doesn't have to be very
> future proof. In
> 6 months or so, Maven will be long gone.
> Apologies in advance if I'm abusing the Groovy Users list for Maven
> related questions, but since I've seen some discussions related to
> Maven/GMaven in the past, I thought I might be forgiven. Thanks,
> -H
> ----------------------------------------------------------------------
> This email message and any attachments are for the sole use of the
> intended recipient(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply email and destroy all copies of the original
> message and any attachments.

View raw message