On 27 Feb 2014, at 10:40 am, Ioan Eugen Stan <[email protected]> wrote:
> Hello,
>
> I've been watching the thread. I've cloned gradle and changed the
> groovy dependency to 2.0.7
We might as well jump straight to the latest Groovy 2.2.x release.
> and got some errors:
>
> ----
> efaultScriptCompilationHandler.java:95: error:
> visitSource(String,String) in <anonymous
> org.gradle.groovy.scripts.internal.DefaultScriptCompilationHandler$1$1$1>
> cannot override visitSource(String,String) in ClassWriter
> public void visitSource(String sourcePath,
> String debugInfo) {
> ^
> overridden method is final
For the purposes of getting something to work, you can just comment out that
overridden visitSource(). It doesn’t do anything important (at this stage).
> ----
>
> Forked the project, I'll try some changes when I get some free time.
>
> Thanks,
>
>
>
> On Wed, Feb 26, 2014 at 7:31 PM, Daz DeBoer
> <[email protected]> wrote:
>> On Tue, Feb 25, 2014 at 2:42 AM, Jochen Theodorou <[email protected]> wrote:
>>>
>>> Am 24.02.2014 00:48, schrieb Daz DeBoer:
>>>>
>>>> On Sun, Feb 23, 2014 at 3:25 AM, Ioan Eugen Stan <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> Short version question: What would it take to make gradle build with
>>>> groovy 2 - (before Debian Jessie Freeze at start of this November) ?
>>>>
>>>>
>>>> Short answer: we can't switch to Groovy 2 without breaking compiled
>>>> plugins, and we have a strict backward compatibility standard for minor
>>>> releases.
>>>
>>>>
>>>>
>>>> Since we haven't deprecated support for Groovy 1.8.6, it's unlikely
>>>> we'll remove support for this version in Gradle 2.0, our next major
>>>> release.
>>>
>>>
>>> your comment implies binary incompatibility. Maybe you did not mean that,
>>> but Groovy 2 is binary compatible with even Groovy 1.0 - afaik
>>>
>>> What you might wanted to say is that there have been API changes. If they
>>> are only in DefaultGroovyMethods (and friends), then gradle can use an
>>> extension module to provide a different behaviour quite easily.
>>
>>
>> Thanks for the clarification. It seems like a few members of the Gradle team
>> (myself included) were operating under the incorrect assumption that there
>> was binary incompatibility between 1.x and 2.0, and that by moving to 2.0
>> _every_ plugin that was compiled against Groovy 1.x would need to be
>> recompiled. This was considered an unacceptable situation, even moving to
>> Gradle 2.0.
>>
>> If the majority of compiled plugins would continue to function even if we
>> changed Gradle to use Groovy 2.x, then we'd probably make the switch for the
>> next major version of Gradle, which will happen in the next 6 months.
>>
>>>
>>> Imho the real question is: what would really break if you used Groovy 2?
>>> And I get th feeling, that nobody can answer that really in any, but one
>>> case (a change in DefaultGroovyMethods, which gradle can fix on the gradle
>>> side)
>>>
>>
>> @Ioan, if you're still interested in helping out, it would be great to know
>> just how many things will break with a change to Groovy 2. You could fork
>> the Gradle project, make the change and the work on getting things running.
>> @Jochen if you've got bandwidth to assist, I'm sure your Groovy expertise
>> would be greatly appreciated.
>>
>> cheers
>> Daz
>>
>
>
>
> --
> Ioan Eugen Stan
> 0720 898 747
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
