On Dec 28, 2008, at 8:44 PM, Adam Murdoch wrote:
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.
Definitely.
- 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).
Right.
Something like this would map to the osgi model pretty naturally, I
think.
From the roadmap in my mind this would be 0.7 stuff. I'm looking
forward to getting this done.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
