[prev in list] [next in list] [prev in thread] [next in thread] 

List:       groovy-dev
Subject:    Re: [groovy-dev] Re: Change to groovyc Ant task in 1.7.11/1.8.7/2.0.1 causes problems for Gradle
From:       Cédric_Champeau <cedric.champeau () gmail ! com>
Date:       2012-07-27 10:23:36
Message-ID: 50126C28.5040101 () gmail ! com
[Download RAW message or body]

Yes, it's setting them both to false that causes a problem (and a real 
one). If it's a breaking change for Gradle to throw an 
IllegalArgumentException like we do now, I see two possible solutions:

     1. replace the exception with a LOG.warn (which would require a 
logger, but not a big deal)
     2. maybe a bit overkill, but instead of directly calling throw new 
IAE(...), call 
GroovyValidationFactory().getInstance().throwValidationError(...), where 
you would provide your own factory (by setting 
GroovyValidationFactory.setFactory(...)). It's a bit overkill in the 
sense that it only contains one method now, but it would allow us to 
continue throwing an error if run using regular groovy, and you to 
continue with the old behaviour...

Le 27/07/2012 12:11, Peter Niederwieser a écrit :
> Jochen Theodorou wrote
> > I think we did that, because the options really excludes each other
> > effectively. I remember Cedric and I had a longer discussion about
> > this... sadly I don't remember the details so much any more. I only
> > remember forking plus includeAntRuntime set to true makes problems
> > beyond our control.
> > 
> What's now prevented is setting both to *false*. I'm aware that this may
> never have had the desired effect (there is a Javadoc comment in the Gradle
> codebase about this), but the validation is a breaking change for us and
> forces us to use includeAntRuntime=true, which causes the aforementioned
> compilation problems (and least when used from Gradle).
> 
> 
> Jochen Theodorou wrote
> > > This breaks existing Gradle builds
> > > where Groovy compilation is configured with useAnt=true and fork=false
> > > because Gradle always sets includeAntRuntime to false. I've changed this
> > > to
> > > set includeAntRuntime to !fork, but then I run into a new problem when
> > > includeAntRuntime=true and fork=false. Specifically, I get a
> > > NoClassDefFoundError: org/junit/TestCase whenever I compile a Groovy
> > > class
> > > that extends GroovyTestCase.
> > Doesn't that mean your ant runtime loads TestCase? Why not adding junit
> > to the Groovy compilation classpath?
> > 
> JUnit is on the Groovy compiler's compile class path. Here is the test build
> that's failing with NoClassDefFoundError:
> https://github.com/gradle/gradle/tree/master/subprojects/plugins/src/integTest/resou \
> rces/org/gradle/groovy/compile/BasicGroovyCompilerIntegrationSpec/canCompileAgainstGroovyClassThatDependsOnExternalClass
>  
> 
> Jochen Theodorou wrote
> > > Some time ago, we've had exactly the same problem with Gradle's native
> > > Groovy compiler integration, and it turned out to be a nasty class loader
> > > problem that took several attempts to fix. The problem occurred when the
> > > code to be compiled referenced a class from the Groovy Jar that in turn
> > > referenced a (non-JDK) third-party class. I haven't tried the groovyc Ant
> > > task standalone, but it seems to be suffering from a similar problem.
> > And what was that final solution? That solution may solve the problem we
> > couldn't solve.
> > 
> Basically, we changed our class loader setup. We now have three class
> loaders in place:
> 
> 1. A class loader for loading the compile class path, including the Groovy
> Jar(s). Isolated from 2. and 3.
> 2. A class loader for loading the compiler itself.
> 3. A class loader for loading transforms. Selectively delegates to 2. for
> compiler classes.
> 
> I think that earlier, 1. had 2. as its parent (and 1. and 3. were the same),
> but once you are loading from 2., you can't go back to 1. to satisfy
> dependencies like GroovyTestCase -> org.junit.TestCase. 3. has to deal with
> the same problem and at the same time *must* delegate to 2. for compiler
> classes. We solved this by hardcoding some knowledge about which Groovy
> classes definitely aren't part of the compiler and don't need to be
> delegated to 2. Currently this list only contains GroovyTestCase and
> GroovyServlet.
> 
> For details see:
> https://github.com/gradle/gradle/blob/master/subprojects/plugins/src/main/groovy/org/gradle/api/internal/tasks/compile/ApiGroovyCompiler.java
>  
> Cheers,
> Peter
> 
> 
> 
> --
> View this message in context: \
> http://groovy.329449.n5.nabble.com/Change-to-groovyc-Ant-task-in-1-7-11-1-8-7-2-0-1-causes-problems-for-Gradle-tp5710832p5710836.html
>  Sent from the groovy - dev mailing list archive at Nabble.com.
> 
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
> 
> http://xircles.codehaus.org/manage_email
> 
> 
> 
> 


-- 
Cédric Champeau
SpringSource - A Division Of VMware
http://www.springsource.com/
http://twitter.com/CedricChampeau


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


[prev in list] [next in list] [prev in thread] [next in thread]