Quantcast

HTTP Client grape resolve takes 30+ seconds on groovy 1.7.10 dependency

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

HTTP Client grape resolve takes 30+ seconds on groovy 1.7.10 dependency

Ted Naleid
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTP Client grape resolve takes 30+ seconds on groovy 1.7.10 dependency

Ted Naleid
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:

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTP Client grape resolve takes 30+ seconds on groovy 1.7.10 dependency

Ted Naleid
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:

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
 *
 *
 * 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:

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTP Client grape resolve takes 30+ seconds on groovy 1.7.10 dependency

Ted Naleid
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:

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
:: 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:

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
 *
 *
 * 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:

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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTP Client grape resolve takes 30+ seconds on groovy 1.7.10 dependency

Guillaume Laforge-4
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:
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:

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
:: 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:

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
 *
 *
 * 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:

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






--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTP Client grape resolve takes 30+ seconds on groovy 1.7.10 dependency

Sébastien Launay-2
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HTTP Client grape resolve takes 30+ seconds on groovy 1.7.10 dependency

Ted Naleid
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:
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



Loading...