In the beginning we had simply a DefaultTask and a DefaultProject
class to implement our Project and Task interface. Then we
decided that to improve performance and for some other reasons we
want to implement as much as possible in Java. We did this pretty
much in a rush. The current state is not as concise as I would
like it to be.
One may define three layers for this space:
1.) Java classes which use only other java classes
2.) Java classes which use also Groovy classes
3.) Groovy classes
To objective for separating the layers 1.) from 2.) and 3.) is to
separate the pure Java core from a specific DSL. This separation
adds complexity to the design (e.g. introduction of Action
classes) although right now we have only one DSL language. We
don't know when we start to develop an engine for another DSL
language and what exactly the requirements for this would be. I
think the current separation smells a little bit like
'speculative generality'. I'm wondering if we should merge this
layers again. Also this layerign is only partly implemented.
What would the merged layers look like? What would you change?
We would remove the interfaces DagAction, ProjectAction and
TaskAction and the respective methods like Task.doFirst
(TaskAction), etc .... and we would only work with Closures and use
only methods like doFirst(Closure action). AbstractTask would merge
into the class DefaultTask. AbstractProject would merge into
DefaultProject (which would then be a Java class) as soon as the
Groovy bug mentioned above is fixed. But I'm not sure yet if this
is a good idea.
I don't think any longer that this is a good idea. I see two use
cases were this strict layering is beneficial.
Embedded Usage: I love tools like Jetty or Ivy which are usually
driven by some descriptor files like web.xml or ivy.xml, but also
expose their functionality via an API. This usually does open up
unanticipated use cases. And I think there shouldn't be a groovy
requirement for this usage scenario.
Offering a Java Build Script Engine: Although Groovy is usually the
most convenient build script engine an additional Java build script
engine has some benefits if:
- performance and startup requirements are very strict
- for whatever reason, only Java is possible to use (e.g. company
policy)
- very useful for performance profiling (no dynamic dispatches).
The biggest pain point of a Java build script engine is probably the
lack of an Ant Builder. Using Ant via its API is pretty inconvenient.
But that is another story.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
