Hans Dockter wrote:
I think this is not an internal structure. To successfully work with
Gradle, I think it is important to have in mind that there is a
distinct project object for every subproject. And that a build script
is most of all a bunch of statements that are applied against that
project object, thus configuring the project object. This is a first
level concept and not an implementation detail. A plugin does exactly
the same and I think it is important to understand that. I think the
only thing that makes a plugin special is that it is supposed to be
used from multiple projects/builds. But this is not a technical
difference. This becomes very clear if you use script plugins. Those
are just lying around somewhere locally, or remote and are applied
against project objects. May be they are only used from one other
script for decomposing your build or it is used from thousands of
different build scripts. Only in the latter case people would
intuitively see them as a plugin. Therefore I'm not sure whether we
should continue to use the term plugin. An alternative would be to
introduce the term Configurer or something similar. Any build script
would be a Configurer as well as the classes that currently implement
Plugin. People often have a certain notion regarding plugins that
might be different to what Gradle plugins are and that would solve that.
In my opinion, the DSL is the only thing that is not an implementation
detail. Most people that will use gradle will never write a plugin or
dig deeper than writing simple build scripts to get their build
automated. Because of this, it is extremely important to provide a DSL
which is easy to understand.
I think that a plugin is sth. that extends the features of an
application at a certain extension point. This is exactly what is done,
when a plugin or another build script is applied to a project
configuration. If another build script is applied against a project, it
plugs into the project configuration, which might include extending it's
runtime functionality by providing additional tasks.
The term configurer might be a bit too easy to misunderstand because of
Configurations (which are something completely different).
I think included would suggest that this is equivalent to a copy and
paste of the other script into the build script. But this is not the
case and might lead to wrong expectations. For example each script has
its own classloader and might have a different classpath.
I am with you regarding 'include', this was not a good suggestion.
Kind regards
Matthias
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
