On Aug 18, 2009, at 1:56 AM, Adam Murdoch wrote:
Steve Appling wrote:
Hans Dockter wrote:
On Aug 5, 2009, at 11:58 PM, Adam Murdoch wrote:
Steve Appling wrote:
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?
I think we should call the method Project.getGradle(), rather
then getGradleInvocation()
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.
We could tackle this in a few ways.
- We find some way to distinguish between archives which are
distributions and archives which are not.
- We keep the default we have (which is simple) and make it easy
to override.
- We get rid of the libs and dists tasks and get you to add your
own lifecycle.
- We move the lifecycle stuff to a new plugin which extends the
java plugin, so you can opt in.
For 1), a good approximation might be for dists and libs to
depend on publishable archives, that is, archives which are part
of a configuration.
2) is pretty much the solution we have now.
4) would allow us to have several different lifecycles to choose
from. It would also give us a good place to add concepts like
integration testing without necessarily cluttering the java plugin.
I think it is hard to be smart here as I'm sure there will be many
unanticipated scenarios. So I think it is good to be simple and
yet offer some convenience out-of-the-box stuff. Let's go with 2.)
for the moment. Once we get more information about different
common lifecycle scenarios we might move to 4.).
- Hans
Just so I'm clear here - by 2 you mean "We keep the default we have
(which is simple) and make it easy to override".
I'm fine with what we have as the default (dists includes all
archiving tasks), but how do we override that or opt out?
There's a few options:
- You can replace the dists task:
task dists(overwrite: true, dependsOn: [some tasks])
- You can replace the dependencies of the dists task:
dists.dependsOn = [some tasks]
We could also introduce an exclude filter for the task dependencies of
a task.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
