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.
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.
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.
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.
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
