Build is broken.

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Build is broken.

hans_d
Administrator
Hi Adam,

the introduction of the task dependencies had a surprising side  
effect. When I have triggered the release build an exception occured  
in the following snippet.

zip(classifier: 'all-jdk14').doFirst {Task task ->
         task.configure {
             zipFileSet(dir: explodedDistDir, prefix: zipRootFolder) {
                 exclude 'bin/*'
                 exclude 'lib/gradle*.jar'
                 exclude 'lib/logback*.jar'
             }
             zipFileSet(dir: distsRetroLibsFolder, prefix:  
"$zipRootFolder/lib")
             dependencies.resolve('retrotranslatorAntTask').each  
{ File file ->
                 zipFileSet(dir: file.parentFile, prefix:  
"$zipRootFolder/lib") {
                     include file.name
                 }
             }

dependencies is no now longer interpreted as he dependency manager  
but as the task property. The call to resolve fails. We could make  
the build work by saying owner.resolve. But as the dependency manager  
is such an important entity and accessed by the dependencies name I  
don't know if we should use the same names. Do you think the name  
dependencies (for dependency manager) is a good choice?

This problem has been hidden as our normal builds usually skip the  
jdk14 distribution task.

- Hans

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





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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Build is broken.

Adam Murdoch-2


Hans Dockter wrote:

> Hi Adam,
>
> the introduction of the task dependencies had a surprising side
> effect. When I have triggered the release build an exception occured
> in the following snippet.
>
> zip(classifier: 'all-jdk14').doFirst {Task task ->
>         task.configure {
>             zipFileSet(dir: explodedDistDir, prefix: zipRootFolder) {
>                 exclude 'bin/*'
>                 exclude 'lib/gradle*.jar'
>                 exclude 'lib/logback*.jar'
>             }
>             zipFileSet(dir: distsRetroLibsFolder, prefix:
> "$zipRootFolder/lib")
>             dependencies.resolve('retrotranslatorAntTask').each { File
> file ->
>                 zipFileSet(dir: file.parentFile, prefix:
> "$zipRootFolder/lib") {
>                     include file.name
>                 }
>             }
>
> dependencies is no now longer interpreted as he dependency manager but
> as the task property. The call to resolve fails. We could make the
> build work by saying owner.resolve. But as the dependency manager is
> such an important entity and accessed by the dependencies name I don't
> know if we should use the same names. Do you think the name
> dependencies (for dependency manager) is a good choice?
>

Oops. I didn't think that through.

I think 'dependencies' should refer to the dependency manager, and we
should rename Task.getDependencies(). I wonder if we have this problem
anywhere else?


Adam

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

    http://xircles.codehaus.org/manage_email