Using Groovy++ with Maven
Note, an update is available.
Groovy++ artifacts are now deployed in Maven repository at:
http://groovypp.artifactoryonline.com/groovypp/libs-releases-local/
and
http://groovypp.artifactoryonline.com/groovypp/libs-snapshots-local/
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:
<dependency> <groupid>org.codehaus.groovy</groupid> <artifactid>groovy</artifactid> <version>1.8.0-beta-1-SNAPSHOT</version> </dependency> <dependency> <groupid>org.codehaus.groovy</groupid> <artifactid>groovypp</artifactid> <version>0.1.18</version> </dependency> <dependency> <groupid>asm</groupid> <artifactid>asm-all</artifactid> <version>3.2</version> </dependency> <dependency> <groupid>antlr</groupid> <artifactid>antlr</artifactid> <version>2.7.7</version> </dependency> <dependency> <groupid>commons-cli</groupid> <artifactid>commons-cli</artifactid> <version>1.2</version> </dependency>
- Use groovypp-all:
<dependency> <groupid>org.codehaus.groovy</groupid> <artifactid>groovypp-all</artifactid> <version>0.1.18</version> </dependency>
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:
<properties> <repo>http://groovypp.artifactoryonline.com/groovypp</repo> </properties> <repositories> <repository> <id>libs-releases</id> <url>${repo}/libs-releases</url> </repository> <repository> <id>libs-snapshots</id> <url>${repo}/libs-snapshots</url> </repository> </repositories> <pluginrepositories> <pluginrepository> <id>plugins-releases</id> <url>${repo}/plugins-releases</url> </pluginrepository> <pluginrepository> <id>plugins-snapshots</id> <url>${repo}/plugins-snapshots</url> </pluginrepository> </pluginrepositories>
.. and configure GMaven plugin:
<plugin> <groupid>org.codehaus.gmaven</groupid> <artifactid>gmaven-plugin</artifactid> <version>1.2</version> <executions> <execution> <id>compile-groovy</id> <phase>process-sources</phase> <goals> <goal>compile</goal> </goals> <configuration> <providerselection>1.7</providerselection> <verbose>true</verbose> <debug>true</debug> <stacktrace>true</stacktrace> <sources> <fileset> <directory>${project.basedir}/src</directory> <includes> <include>**/*.groovy</include> </includes> </fileset> </sources> </configuration> </execution> </executions> <dependencies> <dependency> <groupid>org.codehaus.gmaven.runtime</groupid> <artifactid>gmaven-runtime-1.7</artifactid> <version>1.2</version> <exclusions> <exclusion> <groupid>org.codehaus.groovy</groupid> <artifactid>groovy-all</artifactid> </exclusion> </exclusions> </dependency> <dependency> <groupid>org.codehaus.groovy</groupid> <artifactid>groovypp-all</artifactid> <version>0.1.18</version> </dependency> </dependencies> </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.
Hello,
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
Joern
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
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 …
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
Joern
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.
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.
Actually, just read your other more recent post and noticed the groupId change, don’t bother, sorry for the noise 🙂
Yes, it was changed exactly for that reason. Older deployments with “org.codehaus.groovy” groupId will be removed from Artifactory repo