On Tue, Apr 6, 2010 at 12:38 PM, Geronimo M. H. <[email protected]>wrote:
> Hello,
>
> on experimenting with archive tasks, I got surprised by the way, things
> work.
> An excerpt from my build-file is this:
>
> task tellSources << {
> def sources = files(subprojects.collect { project->
> [ project.sourceSets.main.allJava ] })
>
> // sources.each { println it }
> copy {
> from sources
> into file(rootProject.buildDir).absolutePath + '/src'
> }
> }
>
As an alternative:
task tellSources(type: Copy) {
from subprojects.collect { project -> project.sourceSets.main.allJava }
into "$buildDir/src"
}
or
task tellSources(type: Copy) {
sources = subprojects.collect { project ->
project.sourceSets.main.allJava }
from sources
into "$buildDir/src"
}
Some notes:
- buildDir returns an absolute file. It does not hurt to feed it into the
project.file method but it is not necessary.
- Assuming the tellSources task is in root, you don't need to say
rootProject.buildDir.
- The from method can digest a lot of different inputs: File, String, Object
(resolved by toString()), FileCollection, FileTree. Any Java collection you
pass as an argument is flattened. There is an important difference between
FileTree and FileCollection. A FileTree preserves a hierarchy, wheras a
plain FileCollection represents just a set of files. Applying the files
method to a fileTree destroys the hierarchy and returns a plain file
collection. I guess this is not what you want in the example above where you
probably would like to preserve the hierarchy. In any case, you can allJava
returns a fileTree which you can directly feed into the from.
subprojects.collect { project -> project.sourceSets.main.allJava }
transforms a list [project1, project2] into [allJava (project1),
allJava(project2)]. The latter is a list with file tree objects which you
can pass to the from and where it gets flattened. from [a, b] is similar to
from a, b.
The Javadoc for FileTree and FileCollection and Copy/CopySpec is pretty
informative to learn more about those types.
> task myArchive(type: Tar) << {
> baseName = 'rednose'
> destinationDir = rootProject.buildDir
> from(file(rootProject.buildDir).absolutePath + '/src') {
> include '**/*.java'
> }
> }
> myArchive.dependsOn tellSources
>
> My defaultTasks are 'clean' and 'build' - so when I run gradle without any
> argument, I was very surprised, that the build-dir contained a
> src-directory
> which all sources in.
> From my point of view, none of my bizarre task-definition is part of the
> standard task-graph (or at least should not be).
>
> When I look at the executed tasks, I'll find this:
>
> ...$ fgradle
> :clean UP-TO-DATE
> :SRLibAppBase:clean
> :SRLibDA:clean
> :SRLibGui:clean
> :SRServiceManager:clean
> :SRSrvSample:clean
> :SRStarter:clean
> :compileJava UP-TO-DATE
> :processResources UP-TO-DATE
> :classes UP-TO-DATE
> :jar
> :tellSources
> :myArchive UP-TO-DATE
> :assemble
> :compileTestJava UP-TO-DATE
> :processTestResources UP-TO-DATE
> :testClasses UP-TO-DATE
> :uploadArchives
> :test UP-TO-DATE
> :check UP-TO-DATE
> :build
> ...
>
> So how did my creepy task definitions find their way into
> the 'build'-task-graph?
>
The assemble task is a task with a dynamic dependsOn. You could define a
similar task as a one liner:
task myAssemble(dependsOn: { tasks.withType(Zip).all })
Watch the closure as a dependsOn argument. This defines lazy evaluation,
which means even zips or jars defined after myAssemble will be picked up.
> And even more strange:
> when I execute "gradle myArchive", I get the message, that "myArchive is
> UP-TO-DATE, but no archive has been created.
> Can anybody shine me a light on what's happening?
>
Gradle defines a task also as up to date if no work was done. Your
tellSources task did not copy anything. Therefore the archive had no input
and no archive was created.
- Hans
--
Hans Dockter
Founder, Gradle
http://www.gradle.org, http://twitter.com/gradleorg
CEO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
>
> kind regards
>
> Geronimo
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
