On Thu, Feb 4, 2010 at 9:14 AM, Matthias Pfau <[email protected]> wrote:
> 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. > > I agree that the term plugin is not wrong. What is important to me is that we have a single concept in our design. That should be reflected in the way we talk about things. Either everything is a plugin including a normal build script. Or we find a different term for plugin. To some degree the best name (e.g. applying, using) for calling a plugin/configurer depends on the name for the latter. > The term configurer might be a bit too easy to misunderstand because of > Configurations (which are something completely different). That is a very good point. We were never happy with the term configuration for a dependency/artifact container. Therefore we plan to deprecate the term configuration and replace it with dependencySet/artifactSet. That will be for 0.10 (which might be 1.0 RC1). Once 0.9 is out we will start discussing this on the dev list. - Hans -- Hans Dockter Founder, Gradle http://www.gradle.org, http://twitter.com/gradleorg CEO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz > 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 > > >
