On Tuesday 06 April 2010 15:36:30, Hans Dockter wrote:
> On Tue, Apr 6, 2010 at 12:38 PM, Geronimo M. H. <[email protected]>wrote:
> >
> > 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"
> }
I think, my mental blockade arised from the difference between gradle task and
ant-target. I'm used to think in ant-targets, where a target can consist of
several tasks.
So writing gradle tasks and thinking of ant-targets will probly fail - as it
used to happen to me.
So, I think I have to change my way of thinking - but to really get into this
part of gradle, I'd need to understand much more of gradle task-graphs, how
they are built and how they could be changed. I have to learn about
gradles "black magick" :)
> Applying the files method to a fileTree destroys the hierarchy and returns
> a plain file collection. I guess this is not what you want
You're completely right. I changed it that way:
task srcDist(type: Tar) {
appendix = 'src-with-depends'
destinationDir = projectDir
extension = 'tgz'
subprojects.each { project ->
from (project.projectDir) {
into project.name
exclude '**/.svn/**'
exclude 'xdist/**'
}
}
from (projectDir.absolutePath + '/buildSrc') {
into 'buildSrc'
exclude '**/.svn/**'
exclude '.gradle/**'
}
from (projectDir.absolutePath + '/common') {
into 'common'
exclude '**/.svn/**'
exclude 'lib/**'
}
from (projectDir) {
include '**.gradle'
}
}
which will now copy my local repository "as is" and not use gradles dependency
graph. It might be object of improvement, when I know more about gradle.
> > 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 })
That's fine so far.
But can I do the opposite?
I use the java plugin - and I guess, something similar of the above is part of
the plugin.
Do I need to write my own plugin to break that "hidden" dependencies, or can I
change that behavior by configuration?
kind regards
Geronimo
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
