[ 
https://issues.apache.org/jira/browse/GROOVY-7407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14525142#comment-14525142
 ] 

Jex Jexler commented on GROOVY-7407:
------------------------------------

Side remark, resp. idea for a possible alternative to Ivy - in case some issues 
should be too "hairy" to tackle:

{panel}Enable Grape to use *Gradle*'s dependency resolution?{panel}

Originally, Gradle's dependency resolution was based on Ivy, until Gradle 1.0:

    http://gradle.org/docs/1.0/release-notes
{quote}
In Gradle 1.0 we've moved away from using Ivy for dependency resolution. The 
dependency resolution engine has been rebuilt from the ground up; it is now 
faster, more accurate and more flexible. [...]

Fast, accurate and reliable dependency cache

In Gradle 1.0 we've replaced the ivy artifact cache with our own 
implementation, targetting performance, consistency and reliability. Our new 
cache has advanced features that help avoid subtle (and not so subtle) problems 
permitted by other cache implementations, where a build that runs correctly on 
one machine fails on another.
{quote}
More specifically, the idea could be a {{class groovy.grape.GrapeGradle extends 
groovy.grape.GrapeEngine}}, plus a way to select the engine (system property?).

> Compilation not thread safe if Grape / Ivy is used in Groovy scripts
> --------------------------------------------------------------------
>
>                 Key: GROOVY-7407
>                 URL: https://issues.apache.org/jira/browse/GROOVY-7407
>             Project: Groovy
>          Issue Type: Bug
>          Components: Compiler, Grape
>    Affects Versions: 2.4.3
>         Environment: Essentially independent of the environment, as long as 
> Groovy scripts use Grape; also this bug seems to be present since at least 
> Groovy 1.7.5.
>            Reporter: Jex Jexler
>            Assignee: Paul King
>            Priority: Minor
>              Labels: Compile, Grape, Groovy, Ivy
>         Attachments: GrapeAndGroovyShellConcurrencyTest.java, 
> GroovyCompileConcurrencyTest.java, 
> stacktrace-GrapeAndGroovyShellConcurrencyTest-1.txt, 
> stacktrace-GrapeAndGroovyShellConcurrencyTest-2.txt, 
> stacktrace-GroovyCompileConcurrencyTest-1.txt, 
> stacktrace-GroovyCompileConcurrencyTest-2.txt
>
>
> If Groovy scripts that import the same libraries via Grape are compiled in 
> separate threads, compilation may fail due to race conditions.
> This does not happen if several threads use the *same* instance of 
> GroovyClassLoader (GCL), because parseClass() uses synchronization.
> But as soon as different GCLs are used in separate threads or if the compiler 
> is used directly (CompilationUnit.compile()), the issue occurs and 
> compilation can fail.
> Two Java unit tests have be attached, which reproduce the issue, although 
> this cannot be guaranteed with 100% certainty, because there is a race 
> condition.
> Two different stacktraces have been observed for each unit test (with origins 
> in Grape and in Ivy), which have also been attached (plus in a different 
> environment (Tomcat webapp CentOS) once a an exception down in Ivy had been 
> observed that seemed to be related to unzipping a JAR file, but no precise 
> record of that exists any more).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to