Hans Dockter wrote:
On Dec 27, 2008, at 12:32 AM, Tom Eyckmans wrote:
I like the idea of an ide plugin very much. We could do something
similar with ide as with testframeworks ( renamed from testconvention
to testframework to prevent confusion ):
like in test:
test {
useJunit() / useTestNG() / ...
}
ide {
useIntelliJ() / useEclipse() / ...
retrieveSources ( default for all dependency configurations ?
transitive yes/no? )
}
just a thougth
I think it makes a lot of sense to have an common abstraction on top
of IntelliJ/Eclipse/NetBeans for IDE stuff. Steven Devijver had
another idea on top of this which I really like. Plugins should be
able to communicate which each other. In the case of our future IDE
plugin this means. A plugin which is not written by us marks itself as
IDEAware. In this case, the IDE plugin passes an IDEConf object to
this external plugin and the external plugin can read/modify the IDEConf.
I like this idea, though I would tweak it to look like this:
- A plugin can provide the APIs for an abstraction, such as test
framework, IDE, application server, VCS, along with the configuration
for the abstraction.
- Another plugin can declare that it requires a certain abstraction, and
Gradle (rather than the provider plugin) takes care of injecting an
implementation into the client plugin.
- The provider plugin may optionally provide extension points, and a
plugin can declare that it provides an extension to an abstraction (eg
integration with git, say), and Gradle takes care of registering it with
the provider plugin.
- Some abstractions will be provided by Gradle core (eg dependency
management), but otherwise used and extended in the same way as if they
were provided by a plugin (which they might end up doing if we were to
later bust up the core into plugins).
Something like this would map to the osgi model pretty naturally, I think.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
