On Sep 9, 2009, at 1:13 AM, Adam Murdoch wrote:
Hans Dockter wrote:
On Sep 4, 2009, at 1:56 AM, Adam Murdoch wrote:
Hi,
I'd like to make some changes to our lifecycle tasks, which I
think will simplify things, and make the intent a bit clearer:
1. Collapse 'libs' and 'dists' into a single task. I like the term
'package'.
Which is unfortunately a reserved word, isn't it?
True. Perhaps 'assemble'?
Assemble is good I think.
That is, you package a java project into a deployable thing, which
might be a library, a web app, a command-line app, or whatever.
I guess it depends very much on your project. For some project it
makes sense to have the two different tasks we have now. They
sometimes want to produce the jars, other times the zips. On the
other hand often one of both is superfluous. So it might make sense
to settle on something more abstract which fits every project.
To me, these are the key reasons to collapse them:
- For most projects, you want to build the actual production
artifacts for the project in some usable state. For a library
project, you'd want the jar(s), for a web app, you'd want the war,
for an app, you'd want the dist. For a project that combines these
aspects, you'd want the combined artifacts. Having a task which
expresses this intent would be good. This is particularly true in a
mixed-type multi-project build (eg Gradle's build), as you can
gradle assemble from the root dir and this assembles the appropriate
artifacts for each sub-projects, based on its type. Without this,
you need to run gradle dists from the root dir, which potentially
builds more stuff than you need, and which potentially misses
certain projects.
- 'libs' and 'dists' don't work for all java projects. They're too
specific and assume a certain type of project. For a java
application, libs is irrelevent. For a library project, dists is.
For a web app, both of them are. We really should have a lifecycle
task which is more general, and works for all java projects.
- It's so very easy to add 'libs' or 'dists' in your build script if
you want them: tasks libs(dependsOn: {tasks.withType(Jar) }
- The task names 'libs' and 'dists' aren't verbs, which is a smell
to me.
For example in the gradle build, the root project would produce the
dist and gradle-core the jar. And then people can somehow customize
something more fine grained on top of that, if needed.
2. Move 'check' from the code quality plugin to the java plugin
(or maybe the base plugin). Change 'check' to depend on 'test'.
Possibly rename it to 'verify'. That is, verification becomes a
basic concept, and tests become a type of verification.
I like this very much.
3. Move the 'dists' configuration out of the java plugin. It would
be added by any plugin which actually produces a distribution,
such as a java application plugin. Perhaps the war plugin should
add the war to this configuration.
As I understood you above, they would use the 'package' task for
this, wouldn't they?
In point 3, I'm suggesting we move the 'dists' configuration, not
the task.
Sorry for not reading this properly. This makes sense.
We might also think about renaming the archives configuration to
assemblies.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
