Home > Artifactory, Groovy, Maven > Using Groovy++ with Maven

Using Groovy++ with Maven

Note, an update is available.

Groovy++ artifacts are now deployed in Maven repository at:



So you can compile your Groovy++ sources with Maven.
As in Groovy, where you pick up either groovy.jar or groovy-all.jar – you can do the same here:

  • Use groovy + groovypp + asm + antlr + commons-cli:

  • Use groovypp-all:

As you see, the second way is much simpler so I suggest you stick to “groovypp-all”. It’s the same as a longer version but with all required libraries packaged nicely in one bigger jar. 

Of course, you’ll need to instruct Maven about repository:




.. and configure GMaven plugin:


Full examples:

If you didn’t do so yet – you’re welcome to join a community to take part in Groovy++ discussions and be notified about new releases (@groovypp is available as well).

Also, you can follow Alex Tkachman who is Groovy++ inventor at @alextkachman and DZone.

  1. Joern Schimmelpfeng
    March 21, 2010 at 12:31


    Evgene thanks a lot for providing a groovypp by Maven!

    Using groovypp-all seems indeed simpler. But actually I would prefer a solution with all jars decomposed.

    Why don’t you provide the transitive dependencies with the groovypp POM and let Maven care for them? Than both options would be equally simple.

    Thanks again

  2. March 21, 2010 at 15:10

    Hi Joern, I’m glad to help Groovy and Groovy++.

    I think I didn’t put transitive dependencies to “groovypp” POM to discourage people from using it but you’re right – it should definitely have them. Will add it today.

    Just out of curiosity – where decomposed jars are more comfortable for use? Why? I though everyone is using “groovy-all” and will be using “groovypp-all” similarly

    • March 21, 2010 at 16:23

      Of course, I can think of cases where your application is already using ASM and Antlr so you probably wouldn’t like them packed inside Groovy++ jar as well. Btw, they’re packed there under modified package names so there will be no conflict, only an extra weight …

  3. Joern Schimmelpfeng
    March 22, 2010 at 10:20

    Well you are right. There is no risk of conflicts. This was my first concern.

    On the other hand I think we should avoid unnecssary overhead. On large deployments the overhead might sum up if we start to duplicate libraries.

    But anyway, I appreciate your work a lot!
    Thanks again

  4. March 22, 2010 at 13:57

    Sure, you’re right – I’ve just posted an update yesterday (https://evgenyg.wordpress.com/2010/03/22/using-groovypp-with-maven-3/) so it now works both ways. It is much better now, I appreciate your input, Joern.

  5. March 24, 2010 at 22:16

    By the way, the groupId should be changed, as the project is hosted on Google Code, and not on the Codehaus infrastructure, it should be something else than org.codehaus.groovy, but something like com.mtbe.something, like the packages used in the source.

  6. March 24, 2010 at 22:17

    Actually, just read your other more recent post and noticed the groupId change, don’t bother, sorry for the noise 🙂

    • March 25, 2010 at 13:37

      Yes, it was changed exactly for that reason. Older deployments with “org.codehaus.groovy” groupId will be removed from Artifactory repo

  1. March 22, 2010 at 01:10
  2. April 2, 2010 at 14:36
  3. June 26, 2010 at 13:35

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: