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