My experience this week with groovy and grapes has been one of frustration.
Having an issue with download failed:
org.springframework#spring-asm;3.1.0.RELEASE!spring-asm.jar
So I pared things down to a simple script of four lines:
#!/usr/bin/env groovy
@Grab(group='org.cleartk', module='cleartk-util', version='0.9.2')
import java.io.File;
System.out.println("Hello World with @Grab annotations");
And those four lines still result in the following:
Resolving dependency: org.cleartk#cleartk-util;0.9.2 {default=[default]}
Preparing to download artifact org.cleartk#cleartk-util;0.9.2!cleartk-util.jar
Preparing to download artifact org.apache.uima#uimaj-core;2.4.0!uimaj-core.jar
Preparing to download artifact org.uimafit#uimafit;1.4.0!uimafit.jar
Preparing to download artifact args4j#args4j;2.0.16!args4j.jar
Preparing to download artifact com.google.guava#guava;13.0!guava.jar
Preparing to download artifact com.carrotsearch#hppc;0.4.1!hppc.jar
Preparing to download artifact commons-io#commons-io;2.4!commons-io.jar
Preparing to download artifact commons-lang#commons-lang;2.4!commons-lang.jar
Preparing to download artifact org.apache.uima#uimaj-tools;2.4.0!uimaj-tools.jar
Preparing to download artifact
org.springframework#spring-core;3.1.0.RELEASE!spring-core.jar
Preparing to download artifact
org.springframework#spring-context;3.1.0.RELEASE!spring-context.jar
Preparing to download artifact org.apache.uima#uimaj-cpe;2.4.0!uimaj-cpe.jar
Preparing to download artifact
org.apache.uima#uimaj-document-annotation;2.4.0!uimaj-document-annotation.jar
Preparing to download artifact
org.apache.uima#uimaj-adapter-vinci;2.4.0!uimaj-adapter-vinci.jar
Preparing to download artifact org.apache.uima#jVinci;2.4.0!jVinci.jar
Preparing to download artifact
org.springframework#spring-asm;3.1.0.RELEASE!spring-asm.jar
Preparing to download artifact
commons-logging#commons-logging;1.1.1!commons-logging.jar
Preparing to download artifact
org.springframework#spring-aop;3.1.0.RELEASE!spring-aop.jar
Preparing to download artifact
org.springframework#spring-beans;3.1.0.RELEASE!spring-beans.jar
Preparing to download artifact
org.springframework#spring-expression;3.1.0.RELEASE!spring-expression.jar
Preparing to download artifact aopalliance#aopalliance;1.0!aopalliance.jar
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
General error during conversion: Error grabbing Grapes -- [download failed:
org.springframework#spring-asm;3.1.0.RELEASE!spring-asm.jar]
java.lang.RuntimeException: Error grabbing Grapes -- [download failed:
org.springframework#spring-asm;3.1.0.RELEASE!spring-asm.jar]
I tried deleting .groovy/grapes/org.springframework but get the same error
I don't see this as being friendly for new users if downloading dependencies is
not so simple.
-----Original Message-----
From: dev-return-2317-Masanz.James=mayo....@ctakes.apache.org
[mailto:dev-return-2317-Masanz.James=mayo....@ctakes.apache.org] On Behalf Of
Richard Eckart de Castilho
Sent: Friday, December 13, 2013 12:16 PM
To: dev@ctakes.apache.org
Subject: Re: scala and groovy
On 13.12.2013, at 15:27, Steven Bethard <steven.beth...@gmail.com> wrote:
> P.S. I've stayed out of this whole Groovy thing because we (at
> ClearTK) had some bad experiences with Groovy in the past. Mainly with
> Groovy scripts getting out of sync with the rest of the code base,
> just like XML descriptors, though perhaps the IDEs and Maven are
> better now and that's no longer a problem? But this whole "grape"
> thing instead of standard Maven isn't changing my mind. Not that I
> planned to switch away from Scala for my scripting anyway, but...
I heard and read about your bad experiences with Groovy. I believe
that the IDEs got somewhat better at handling Groovy. However, I think a
difference needs to be made depending on the use case.
Some people use the XML files as a format to exchange pipelines
with each other. However, alone, these files are not of much use.
One benefit of using Groovy as a pipeline-exchange format is, that
it can actually get all its dependencies itself via Grape. The
Groovy script is quite self-contained (although it relies on the
Maven infrastructure for downloading its dependencies).
Another is, that thanks to uimaFIT, the Groovy code is much less
verbose than the XML descriptors.
At the UKP Lab, we also use Groovy sometimes for high-level experiment
logic. For us, it is a good compromise between inflexible and
verbose XML files and flexible and verbose Java code. Groovy is flexible
and concise and the IDE support is meanwhile reasonable.
Mind that the IDE support for Grapes (at least in Eclipse) is hilarious.
Grapes cause the IDE to become quite unresponsive as the artifact resolution
is now well integrated into the IDE.
So here is my summarized opinion when to use or not to use Groovy:
== Examples / Exchange ==
In order to get quick results for new users and to showcase the capabilities
of a component collection such as DKPro Core or cTAKES, I think the Groovy
scripts
are a convenient vehicle. At DKPro Core, we also packaged all the resources
(models)
as Maven artifacts, which gives us an additional edge over the manual
downloading
currently happening in the cTAKES Groovy prototypes.
== High-level experiment orchestration ==
Groovy can be useful for high-level experiment coordination. We mostly use it
to conveniently set up parameter spaces and high-level tasks in DKPro Lab [1]
and DKPro Text Classification [2] to do parameter sweeping experiments. In
particular the closures are helpful here and the shorthand for setting up maps,
lists, etc.
== Reusable code and components ==
I would not recommend Groovy for lower-level code, e.g. for writing
framework-level
code such as reusable analysis engines or library code. Mind, the IDE support
got
better, but is is not perfect. At the lower levels, one definitely wants to have
strict type checking and a picky compiler.
Cheers,
-- Richard
[1] https://code.google.com/p/dkpro-lab/
[2] http://code.google.com/p/dkpro-tc/
