Build failure

[Russel Winder-4]

I am getting:

        :gradle-core:compile
        Note: Some input files use unchecked or unsafe operations.
        Note: Recompile with -Xlint:unchecked for details.
        org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed, /home/users/russel/Repositories/Git/Git/Gradle_Working/subprojects/gradle-core/src/main/groovy/org/gradle/api/tasks/util/FileSet.groovy: 34: Can't have an abstract method in a non-abstract class. The class 'org.gradle.api.tasks.util.FileSet' must be declared abstract or the method 'org.gradle.api.file.FileTree matching(groovy.lang.Closure)' must be implemented.
         @ line 34, column 1.
           class FileSet extends AbstractFileTree implements ConfigurableFileTree {
           ^
       
        1 error



--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: [phone], [phone]
41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
London SW11 1EN, UK   m: [phone]   skype: russel_winder

[hdockter]

On Sep 16, 2009, at 9:20 AM, Russel Winder wrote:

> I am getting:
>
>        :gradle-core:compile
>        Note: Some input files use unchecked or unsafe operations.
>        Note: Recompile with -Xlint:unchecked for details.
>        
> org.codehaus.groovy.control.MultipleCompilationErrorsException:  
> startup failed, /home/users/russel/Repositories/Git/Git/
> Gradle_Working/subprojects/gradle-core/src/main/groovy/org/gradle/
> api/tasks/util/FileSet.groovy: 34: Can't have an abstract method in  
> a non-abstract class. The class 'org.gradle.api.tasks.util.FileSet'  
> must be declared abstract or the method  
> 'org.gradle.api.file.FileTree matching(groovy.lang.Closure)' must be  
> implemented.
>         @ line 34, column 1.
>           class FileSet extends AbstractFileTree implements  
> ConfigurableFileTree {
>           ^
>
>        1 error

me too

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org


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

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

On Wed, 2009-09-16 at 09:48 +0200, Hans Dockter wrote:

> On Sep 16, 2009, at 9:20 AM, Russel Winder wrote:
>
> > I am getting:
> >
> >        :gradle-core:compile
> >        Note: Some input files use unchecked or unsafe operations.
> >        Note: Recompile with -Xlint:unchecked for details.
> >        
> > org.codehaus.groovy.control.MultipleCompilationErrorsException:  
> > startup failed, /home/users/russel/Repositories/Git/Git/
> > Gradle_Working/subprojects/gradle-core/src/main/groovy/org/gradle/
> > api/tasks/util/FileSet.groovy: 34: Can't have an abstract method in  
> > a non-abstract class. The class 'org.gradle.api.tasks.util.FileSet'  
> > must be declared abstract or the method  
> > 'org.gradle.api.file.FileTree matching(groovy.lang.Closure)' must be  
> > implemented.
> >         @ line 34, column 1.
> >           class FileSet extends AbstractFileTree implements  
> > ConfigurableFileTree {
> >           ^
> >
> >        1 error
>
> me too

On the one hand, I am glad it isn't just me, on the other hand:

1.  It is a bit annoying that the mainline has a compilation error.
2.  We have lost the emails generated by Codehaus Bamboo CI server.

The emails from Bamboo were very useful for deciding whether to update
and install from the mainline, losing them is problematic to workflow --
cf. 1 above.  I appreciate Grails has given up on all Codehaus
infrastructure, but that doesn't mean Gradle has to.  Is there no way of
getting a commit from GitHub to either the Codehaus Subversion
repository or a new Codehaus Git repository so that there can be a
Bamboo build.

My guess would be that commits to GitHub could trigger a mirror push to
a Codehaus Git repository which would then allow the extant Codehaus
infrastructure to go to work.

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: [phone], [phone]
41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
London SW11 1EN, UK   m: [phone]   skype: russel_winder

[hdockter]

On Sep 16, 2009, at 9:48 AM, Hans Dockter wrote:

>
> On Sep 16, 2009, at 9:20 AM, Russel Winder wrote:
>
>> I am getting:
>>
>>       :gradle-core:compile
>>       Note: Some input files use unchecked or unsafe operations.
>>       Note: Recompile with -Xlint:unchecked for details.
>>        
>> org.codehaus.groovy.control.MultipleCompilationErrorsException:  
>> startup failed, /home/users/russel/Repositories/Git/Git/
>> Gradle_Working/subprojects/gradle-core/src/main/groovy/org/gradle/
>> api/tasks/util/FileSet.groovy: 34: Can't have an abstract method in  
>> a non-abstract class. The class 'org.gradle.api.tasks.util.FileSet'  
>> must be declared abstract or the method  
>> 'org.gradle.api.file.FileTree matching(groovy.lang.Closure)' must  
>> be implemented.
>>        @ line 34, column 1.
>>          class FileSet extends AbstractFileTree implements  
>> ConfigurableFileTree {
>>          ^
>>
>>       1 error
>
> me too

Try to build with a clean.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

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

    http://xircles.codehaus.org/manage_email

[hdockter]

On Sep 16, 2009, at 10:23 AM, Russel Winder wrote:

> On Wed, 2009-09-16 at 09:48 +0200, Hans Dockter wrote:
>> On Sep 16, 2009, at 9:20 AM, Russel Winder wrote:
>>
>>> I am getting:
>>>
>>>       :gradle-core:compile
>>>       Note: Some input files use unchecked or unsafe operations.
>>>       Note: Recompile with -Xlint:unchecked for details.
>>>
>>> org.codehaus.groovy.control.MultipleCompilationErrorsException:
>>> startup failed, /home/users/russel/Repositories/Git/Git/
>>> Gradle_Working/subprojects/gradle-core/src/main/groovy/org/gradle/
>>> api/tasks/util/FileSet.groovy: 34: Can't have an abstract method in
>>> a non-abstract class. The class 'org.gradle.api.tasks.util.FileSet'
>>> must be declared abstract or the method
>>> 'org.gradle.api.file.FileTree matching(groovy.lang.Closure)' must be
>>> implemented.
>>>        @ line 34, column 1.
>>>          class FileSet extends AbstractFileTree implements
>>> ConfigurableFileTree {
>>>          ^
>>>
>>>       1 error
>>
>> me too
>
> On the one hand, I am glad it isn't just me, on the other hand:
>
> 1.  It is a bit annoying that the mainline has a compilation error.
> 2.  We have lost the emails generated by Codehaus Bamboo CI server.
>
> The emails from Bamboo were very useful for deciding whether to update
> and install from the mainline, losing them is problematic to  
> workflow --
> cf. 1 above.

Thanks for pointing this out. Our main CI server is anyhow TeamCity.  
So I have just configured TeamCity to send emails to scm@...
.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

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

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

On Wed, 2009-09-16 at 10:36 +0200, Hans Dockter wrote:

> Try to build with a clean.

Seems to have worked. :-)

Java compilation dependency checking is really rubbish.  I wonder if
going the SCons route of handling all the dependency activity rather
than just offloading the problem to javac/groovyc might be worth it.

Currently it seems that any Java project can only be compiled from a
clean slate, which seems a bit naff.

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: [phone], [phone]
41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
London SW11 1EN, UK   m: [phone]   skype: russel_winder

[Russel Winder-4]

On Wed, 2009-09-16 at 10:50 +0200, Hans Dockter wrote:
> On Sep 16, 2009, at 10:23 AM, Russel Winder wrote:
[ . .  .]

> > On the one hand, I am glad it isn't just me, on the other hand:
> >
> > 1.  It is a bit annoying that the mainline has a compilation error.
> > 2.  We have lost the emails generated by Codehaus Bamboo CI server.
> >
> > The emails from Bamboo were very useful for deciding whether to update
> > and install from the mainline, losing them is problematic to  
> > workflow --
> > cf. 1 above.
>
> Thanks for pointing this out. Our main CI server is anyhow TeamCity.  
> So I have just configured TeamCity to send emails to scm@...

Splendid.  I actually don't care which CI server is used as long as it
tells me about the the 32-bit and 64-bit Ubuntu builds by email :-)

Thanks.

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: [phone], [phone]
41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
London SW11 1EN, UK   m: [phone]   skype: russel_winder

[Adam Murdoch-2]

Russel Winder wrote:

On Wed, 2009-09-16 at 10:36 +0200, Hans Dockter wrote:

  

Try to build with a clean.
    

Seems to have worked. :-)

Java compilation dependency checking is really rubbish.  I wonder if
going the SCons route of handling all the dependency activity rather
than just offloading the problem to javac/groovyc might be worth it.

  

That's my plan for 0.9. I really want to have fast, accurate, incremental java builds (and groovy and scala builds, too).


Adam

[Steve Appling]

Using the depend option actually helps with many of these kinds of problems now:
compile.options.depend()

Gradle's own build just doesn't use it.

Russel Winder wrote:

> On Wed, 2009-09-16 at 10:36 +0200, Hans Dockter wrote:
>
>> Try to build with a clean.
>
> Seems to have worked. :-)
>
> Java compilation dependency checking is really rubbish.  I wonder if
> going the SCons route of handling all the dependency activity rather
> than just offloading the problem to javac/groovyc might be worth it.
>
> Currently it seems that any Java project can only be compiled from a
> clean slate, which seems a bit naff.
>

--
Steve Appling
Automated Logic Research Team

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

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

Adam,

On Wed, 2009-09-16 at 21:26 +1000, Adam Murdoch wrote:

> That's my plan for 0.9. I really want to have fast, accurate,
> incremental java builds (and groovy and scala builds, too).

I don't know what is happening in Waf, but I half-way volunteered to
improve the way SCons handles Java compilations.  I use SCons a lot for
C++ and LaTeX work (also Fortran, C, Erlang, Haskell, and to some extent
Java, Scala, and Python).  It annoys me increasingly that the JVM-based
build world and the non-JVM-based build world are so full of tools that
just do not work across the boundaries :-(

But I guess this is my problem for being too eclectic :-)

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: [phone], [phone]
41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
London SW11 1EN, UK   m: [phone]   skype: russel_winder

[hdockter]

On Sep 16, 2009, at 2:02 PM, Steve Appling wrote:

> Using the depend option actually helps with many of these kinds of  
> problems now:
> compile.options.depend()

I have almost forgotten about that. We discussed it in our last dev  
skype conference whether to make it default or not. I argued not to  
make it default but I was very tired then. On the next my arguments  
didn't make sense to me but I forgot to pick it up again.

As far as I can tell the only reason not to make it default would be,  
if it actually increases the compile time for smaller projects.

>
> Gradle's own build just doesn't use it.

I'm all for changing this or to make it default.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org


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

    http://xircles.codehaus.org/manage_email

[Steve Appling]

Hans Dockter wrote:

>
> On Sep 16, 2009, at 2:02 PM, Steve Appling wrote:
>
>> Using the depend option actually helps with many of these kinds of
>> problems now:
>> compile.options.depend()
>
> I have almost forgotten about that. We discussed it in our last dev
> skype conference whether to make it default or not. I argued not to make
> it default but I was very tired then. On the next my arguments didn't
> make sense to me but I forgot to pick it up again.
>
> As far as I can tell the only reason not to make it default would be, if
> it actually increases the compile time for smaller projects.
>
>>
>> Gradle's own build just doesn't use it.
>
> I'm all for changing this or to make it default.
>
> - Hans
>

Actually I think I'll have to retract my previous assertion.  The depend option
is only useful for java compiles, not for groovy compiles.  It is only
implemented in AntJavac because the ant depend task only works with Java sources
:(  If you did change AntGroovyc to try to use this task, it would force
deletion of all classes generated from Groovy sources each time - not what you want.

I don't think this will be helpful for mixed Java/Groovy source trees.

The gradle-ui project could probably use this since (in spite of being under
src/main/groovy) it currently only uses java sources (it has some groovy tests).
The gradle-core project, however, is a truly mixed source project.

--
Steve Appling
Automated Logic Research Team

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

    http://xircles.codehaus.org/manage_email

[hdockter]

On Sep 16, 2009, at 8:15 PM, Steve Appling wrote:

>
>
> Hans Dockter wrote:
>> On Sep 16, 2009, at 2:02 PM, Steve Appling wrote:
>>> Using the depend option actually helps with many of these kinds of  
>>> problems now:
>>> compile.options.depend()
>> I have almost forgotten about that. We discussed it in our last dev  
>> skype conference whether to make it default or not. I argued not to  
>> make it default but I was very tired then. On the next my arguments  
>> didn't make sense to me but I forgot to pick it up again.
>> As far as I can tell the only reason not to make it default would  
>> be, if it actually increases the compile time for smaller projects.
>>>
>>> Gradle's own build just doesn't use it.
>> I'm all for changing this or to make it default.
>> - Hans
>
> Actually I think I'll have to retract my previous assertion.  The  
> depend option is only useful for java compiles, not for groovy  
> compiles.  It is only implemented in AntJavac because the ant depend  
> task only works with Java sources :(  If you did change AntGroovyc  
> to try to use this task, it would force deletion of all classes  
> generated from Groovy sources each time - not what you want.
>
> I don't think this will be helpful for mixed Java/Groovy source trees.
>
> The gradle-ui project could probably use this since (in spite of  
> being under src/main/groovy) it currently only uses java sources (it  
> has some groovy tests).
> The gradle-core project, however, is a truly mixed source project.

Right. Should we set it as the default for Java projects?

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

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

    http://xircles.codehaus.org/manage_email