|
I'm trying to use HTTP Builder 0.5.1 (the latest released version) in a script using grape @Grab annotation. Every time I execute the script, it sits there and resolves for 30+ seconds and then finally just works. I'm sure there is a misconfigured dependency file somewhere, but I'm having trouble parsing the grape output to figure out what I should do. The annotation that I'm using is the standard one from the website (http://groovy.codehaus.org/modules/http-builder/download.html): @Grab(group='org.codehaus.groovy.modules.http-builder', module='http-builder', version='0.5.1' ) I've tried to look into what's going on with the grape command line tool: grape -i resolve org.codehaus.groovy.modules.http-builder http-builder 0.5.1 It seems like it's actually getting hung up on the groovy dependency download. I'm using groovy 1.7.10, any insight is appreciated. Thanks, -Ted |
|
If it matters, I'm also using the default grapeConfig.xml file without any changes that comes with groovy (in src/main/groovy/grape/defaultGrapeConfig.xml, though I've got a copy at ~/.groovy/grapeConfig.xml): <!-- * Copyright 2003-2008 the original author or authors. * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. --> <ivysettings> <settings defaultResolver="downloadGrapes"/> <resolvers> <chain name="downloadGrapes"> <filesystem name="cachedGrapes"> <ivy pattern="${user.home}/.groovy/grapes/[organisation]/[module]/ivy-[revision].xml"/> <artifact pattern="${user.home}/.groovy/grapes/[organisation]/[module]/[type]s/[artifact]-[revision](-[classifier]).[ext]"/> </filesystem> <!-- todo add 'endorsed groovy extensions' resolver here --> <ibiblio name="codehaus" root="http://repository.codehaus.org/" m2compatible="true"/> <ibiblio name="ibiblio" m2compatible="true"/> <ibiblio name="java.net2" root="http://download.java.net/maven/2/" m2compatible="true"/> </chain> </resolvers> </ivysettings>
On Sunday, April 17, 2011 at 2:02 PM, Ted Naleid wrote:
|
|
Sorry to spam the list, but it seems like it's actually downloading groovy 1.7.10 every time (?!). Here's the install list run a 2nd time where it shows that it's downloading it again:
grape -i install org.codehaus.groovy.modules.http-builder http-builder 0.5.1 :: loading settings :: url = jar:file:/usr/local/groovy/lib/ivy-2.2.0.jar!/org/apache/ivy/core/settings/ivysettings.xml :: resolving dependencies :: caller#all-caller;working confs: [default] found org.codehaus.groovy.modules.http-builder#http-builder;0.5.1 in codehaus found org.apache.httpcomponents#httpclient;4.0.3 in ibiblio found org.apache.httpcomponents#httpcore;4.0.1 in ibiblio found commons-logging#commons-logging;1.1.1 in ibiblio found commons-codec#commons-codec;1.3 in ibiblio found net.sf.json-lib#json-lib;2.3 in ibiblio found commons-beanutils#commons-beanutils;1.8.0 in ibiblio found commons-collections#commons-collections;3.2.1 in ibiblio found commons-lang#commons-lang;2.4 in ibiblio found net.sf.ezmorph#ezmorph;1.0.6 in ibiblio found org.codehaus.groovy#groovy;1.7.10 in codehaus [1.7.10] org.codehaus.groovy#groovy;[1.5,1.7.99] found antlr#antlr;2.7.7 in ibiblio found asm#asm;3.2 in ibiblio found asm#asm-commons;3.2 in ibiblio found asm#asm-tree;3.2 in ibiblio found asm#asm-util;3.2 in ibiblio found asm#asm-analysis;3.2 in ibiblio found net.sourceforge.nekohtml#nekohtml;1.9.9 in ibiblio found xerces#xercesImpl;2.8.1 in ibiblio found xml-apis#xml-apis;1.3.03 in ibiblio found xml-resolver#xml-resolver;1.2 in ibiblio Any reason why it'd do this and is there any way to prevent it? -Ted
On Sunday, April 17, 2011 at 2:12 PM, Ted Naleid wrote:
|
|
I confirmed that removing the groovy dependency from the ~/.groovy/grapes/org.codehaus.groovy.modules.http-builder/http-builder/ivy-0.5.1.xml sped things up a ton:
46,50d45 < <dependency org="org.codehaus.groovy" name="groovy" rev="[1.5,1.7.99]" force="true" conf="compile->compile(*),master(*);runtime->runtime(*)"> < <exclude org="org.apache.ant" module="ant" name="*" type="*" ext="*" conf="" matcher="exact"/> < <exclude org="jline" module="jline" name="*" type="*" ext="*" conf="" matcher="exact"/> < <exclude org="org.fusesource.jansi" module="jansi" name="*" type="*" ext="*" conf="" matcher="exact"/> < </dependency> Not sure if something changed with the groovy dependency that's causing it to never cache, but that seems to be the case with all default repos that come with groovy/grapeConfig. -Ted
On Sunday, April 17, 2011 at 2:17 PM, Ted Naleid wrote:
|
|
There was a recent thread on this topic as well, and it seemed the version range used for the Groovy dependency was causing such issues.
On Mon, Apr 18, 2011 at 02:59, Ted Naleid <[hidden email]> wrote:
-- Guillaume Laforge Groovy Project Manager Head of Groovy Development at SpringSource http://www.springsource.com/g2one |
|
Indeed, you can find workarounds here:
http://markmail.org/message/deho3ybdx7q6nlgs 2011/4/18 Guillaume Laforge <[hidden email]>: > There was a recent thread on this topic as well, and it seemed the version > range used for the Groovy dependency was causing such issues. -- Sébastien Launay --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
Thanks for the replies. The linked blog post in the thread you sent (where you answered this question a couple of years ago) is insightful:
I agree with the conclusion in the original thread that maven xml files are not the appropriate place to express version compatibility.
This version range compatibility should be documented somewhere for the project. The maven xml files should have a particular tested version that they're compatible with that they'll download.
Having the grape take 20-30 seconds every time is unacceptable for quick command line scripts (it never caches appropriately) and makes the grape pretty much unusable for most applications where you'd want to use it.
-Ted On Mon, Apr 18, 2011 at 9:50 AM, Sébastien Launay <[hidden email]> wrote: Indeed, you can find workarounds here: |
| Powered by Nabble | Edit this page |
