ctakes-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chen, Pei" <Pei.C...@childrens.harvard.edu>
Subject RE: scala and groovy
Date Fri, 13 Dec 2013 21:44:44 GMT
If you enable the verbose debugging, it may help identify the cause:
Try removing the artifact in question from your .m2 directory and your .groovy
And then:
$grape -d install org.springframework spring-asm 3.1.0.RELEASE
Which should output the full path it will take in attempting to resolve..

> -----Original Message-----
> From: Masanz, James J. [mailto:Masanz.James@mayo.edu]
> Sent: Friday, December 13, 2013 4:15 PM
> To: 'dev@ctakes.apache.org'
> Subject: RE: scala and groovy
> 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.edu@ctakes.apache.org
> [mailto:dev-return-2317-Masanz.James=mayo.edu@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.bethard@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/

View raw message