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]
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
