On Wed, Feb 3, 2010 at 12:13 PM, Matthias Pfau <[email protected]> wrote:
> > The basic idea is that scripts and things that implement Plugin are more >> or less the same thing: They contain build logic which configures or extends >> the project in some way. So, to reflect this, they are used in exactly the >> same way from the build script. >> >> > Hi Adam, > I really like the idea to simplify things where possible. However, this is > a new facet that might be hard to understand for users. I think what you > mean with apply is 'apply a [Plugin or Script] to the current buildscript' > which is perfectly understandable for someone who knows of gradles internal > structure and implementation. > 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. BTW: If Gradle would provide an additional Java DSL, the Java build "script" would implement the current Plugin interface. > > However, from a users point of view, a plugin is "used" as part of the > current script. Another script might also be "used" or "included" as part of > the script. > 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. Use would be a good alternative to apply if it were not reserved. As said above, I like the fact that apply raises the notion that statements are executed against an obect. I wouldn't be happy with usePlugin as the term plugin can be misleading. - Hans -- Hans Dockter Founder, Gradle http://www.gradle.org, http://twitter.com/gradleorg CEO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz > That is why I would stay with 'usePlugin' or just 'use'. > > Kind regards > Matthias > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
