James, 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.. --Pei
> -----Original Message----- > From: Masanz, James J. [mailto:masanz.ja...@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....@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/
