Hans Dockter wrote:
Hi,
our public API interfaces like Project are used by two different
groups. One group are the Gradle users when writing there build script
as well as our plugins. The other group are internal classes like
BuildConfigurer. Some of the API is only used by the latter (e.g. the
evaluate method of the Project interface). So I think it would be a
good idea to add an interface like ProjectInternal, which extends
Project, for this part of the API.
I was thinking the same thing as I was writing javadocs (the methods on
Project without javadoc are pretty much the ones I reckon belong elsewhere).
I'd almost add a 3rd group of methods, which are the methods that add
the groovy DSL to the java API - eg Project.task(name, closure). These
are all really just convenience methods for the core API methods. I
wonder if these belong on another interface which extends Project? That
way another DSL can have its own interface independent of the groovy one.
There are also some methods on the implementation classes of interfaces
like Project which would be good to add to an API interface somewhere -
mainly so they can be documented. These are the groovy DSL variants of
other methods already on the API, eg Project.dependencies(closure) or
createTask(..., closure).
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
