Adam Murdoch wrote:
Steve Appling wrote:
Adam Murdoch wrote:
Steve Appling wrote:
I've been playing with the use of the new build task in my company's
projects and in gradle's own build. I found a couple of issues that
I would like to discuss:
1) The name 'build' unfortunately collides with Project.getBuild()
when used unquoted in a build.gradle. Since I think this task will
be referred to frequently, we need to resolve this. I really liked
'build' for the task you would use most often :(. Any better ideas
for yet another name? Anyone want to support changing the
Project.getBuild() method to something else?
This would make sense. What would we call the method?
It's longer, but we could change the interface to BuildInvocation and
the method to getBuildInvocation.
We could call it Gradle or GradleInvocation or GradleInstance, and
rename what is currently called Gradle to GradleLauncher or
GradleExecuter or GradleInvoker or something like that.
Maybe we should call the task something like 'fullbuild' or 'buildall'?
I like leaving the task name as 'build' and renaming the interface to
GradleInvocation. Is it OK for me to do this?
2) The build task currently depends on dists. It seemed to make
sense at the time to build everything the plugin could. I tried
using a more recent version of the trunk to build gradle itself and
updated explodedDistBase to depend on 'build' instead of libs.
Why should explodedDistBase depend on build?
It currently depends on libs, but after my recent change that will no
longer run the tests or style checks. It seemed to make sense to hook
those in by using the build task instead of listing them explicitly.
But the build task doesn't mean run the tests and checks. It means build
and test everything. It doesn't make sense for explodedDistBase to
depend on build. It's part of the 'build everything' bit.
Ignoring this, why should explodedDistBase depend on test and check?
This is introducing exactly the same problem that we're trying to solve
with jar and test. I don't think worker tasks like explodedDistBase
should impose any lifecycle, by depending on test or check.
I think we want something like:
explodedDistBase dependOn libs
explodedDist dependsOn explodedDistBase + the doc tasks
testedDists dependsOn dists, test, check, integTest
Then, uploadDists, nightlyBuild and developerBuild would dependOn
testedDists
We probably want release dependsOn testedDists as well, to make this
really explicit.
I'd get rid of install dependsOn integTest. I can't say I've ever wanted
to run the tests before installing Gradle.
We should probably get rid of developerBuild, and use build instead,
adding build dependsOn integTest.
I agree with you on this.
This caused an indirect circular dependency because the allZip task
(of type Zip) dependsOn explodedDist and the JavaPlugin adds all
Zip tasks to dists.
a) Should build have depended on libs instead? I had wanted to
make and test everything in this one task, but perhaps making the
other zips is just overkill.
I think build should continue to depend on dists. Having it depend on
libs doesn't make sense to me. What does it mean for 'build' to build
only part of the project?
I think I could argue either way. If I'm going to use build as my
most common task to compile, test, and style check, I might not want
to also always take the time to do things like zip up the source.
This is were the 'tested<Thing>' synthetic tasks would be useful. What
you're describing above is simply the 'testedJar' task. Being able to
execute, or depend on, testedLibs or testedJar or testedMyProductDist,
instead of build would provide the building blocks for defining any
lifecycle I want.
Also, we don't necessarily need to solve this for every build in the
world, provided it's easy to code up the new lifecycle. For example, you
could code up the above with:
build.dependsOn = [{ tasks.withType(Jar) }, test, check]
BTW, this is a good example of why we want to keep worker and lifecycle
tasks separate. I can safely overwrite the dependencies of the build
task, because it contains only lifecycle dependencies. I couldn't do
this when jar depended on test, check.
b) Should there be some way for Zip tasks to "opt out" of being
included in the dist task. Adding all jars and zips automatically
to the libs and dists tasks always seemed easy to use, but I've also
always been a little uncomfortable with this.
Any thoughts on why this is? Do you have any examples of why you'd
want to exclude an archive?
Well, if explodedDistBase depended on build, this would be one :).
I'm not sure that the plugin can assume that every Zip is intended to
be part of a distribution. I can see times where you might have zips
that are only created as part of preparing for integration tests or
other purposes. In the Ant world we have had tasks that just prepared
zipped up test systems (captive databases and simulated user files).
These were not considered part of the distribution, but were Zip tasks
in the project.
Again, the synthetic tasks would help solve this. You can use the
testedMyProductZip task to express the above.
This isn't a big issue to me and I'm willing to live with it for now, but I
don't think synthetic tasks help with this concern. I have had several cases in
the past where build scripts included tasks that zipped things up which were not
a part of making a distribution. That's why I have been uncomfortable with the
automatic dependency of dists on all Zip tasks.
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
