However there is currently an issue being discussed: @Grab is Unusably Slow in Groovy-User mailing list.
Fortunately there is a solution (actually, workaround) before the powers that be (either Grapes and/or the http-builder guys) implements a proper solution.
The following is a verbatim copy of Sébastien Launay's post:
.
I also got the same issue which is a pain because scripting Rest Web Service in Groovy is very powerful especially when it is easy to share with Grape / @Grab.
The dynamic (version range) dependency is actually defined by http-builder himself. IMHO using version range is often a bad practice, at least on production release, because for the same sources the build result can be different when launched again which renders difficult bug analysis and maintenance.
The other thing is that Apache Ivy configuration tries all remote repositories to check for a new version even if it was resolved before but this is appropriate as it is a dynamic dependency. This can be tuned in Ivy with the cache TTL feature.
Indeed, I had the following logs:
== resolving dependencies
org.codehaus.groovy.modules.
...
downloadGrapes: Checking cache for: dependency:
org.codehaus.groovy#groovy;[1.5,1.7.99] ...
default-cache: cached resolved revision expired for
faster startup, this can be done by creating the file ~/.groovy/grapeConfig.xml from the one found in svn and
editing the file to have:
<ivysettings>
<property name="ivy.cache.ttl.default" value="15m"/>
...
Thanks!
ReplyDeleteAwesome post, this has been a HUGE headache for me. Thanks for posting.
ReplyDeleteYou are a hero man! This was a huge slowdown for me!
ReplyDelete