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