Hi,
based on the contribution by Phil Messenger I have submitted tasks
for generating Eclipse files.
First I would like to explain why I have changed certain things of
the original contribution.
1.) I have rewritten the tasks from Groovy to Java. I know that
Groovy shines in particular when it comes to working with XML. Yet we
want to have the Gradle core stuff completely in Java for a number of
reasons:
- It is not possible to generate production ready API documentation
from groovy files via Groovydoc. The creator of Groovydoc, Jeremy
Rayner has done a very good job but simply has no time to continue
working on this tool. It is compl;etely unclear when the remaining
major issues with Groovydoc will be resolved. But we need Gradle API
doc now.
- Gradle wants to scale up. For large multi-project builds working
with Groovy objects have a significant impact on performance.
- Gradle wants to be modular soon, providing also a Java build
engine. We want to make Gradle usable with as few dependencies as
possible and as fast as possible, if this is wished. The Gradle core
should therefore for example not pay the Groovy startup time penalty
of about two of seconds. We also want to provide an embeddable Groovy
core.
- A minor aspect is that a Java build tool should be as transparent
as possible for Java developers. Now and then you need to look into
the code to understand what is going on.
I love Groovy and we pay a price for not using Groovy in our core, in
terms of not making use of a sharp tool. But the most important thing
is that our users are able to enjoy Groovy and write there plugins
and tasks in Groovy, which is often the best choice. For the reasons
described above the situation is different for the Gradle core.
2.) I have removed the Eclipse plugin. The tasks are now added by the
Java and War plugin. This is because of our very basic plugin system.
I though it is more convenient for our users if the tasks are
automatically added by the plugins they use anyway. Once we have our
new plugin system we will change this again. We will reintroduce the
Eclipse plugin. With the new plugin system it will be possible to
execute tasks of a plugin even if the plugin is not added to the
build script via usePlugin. Also plugins will be able to communicate.
A new IDE plugin will pass its domain model objects to all the other
plugins which have declared themselves as 'IdeAware'. Those plugins
can add to the IDE domain model. The Eclipse, IDEA, NetBeans plugin
can then generate there files with the IDE domain model classes.
3.) I have decoupled the Eclipse tasks from the domain model of the
Java plugin. This is a general approach we do in Gradle to keep the
tasks flexible. For example the EclipseClasspath task has a srcDirs
property. You can assign anything to it. The Java plugin then
configures the EclipseClasspath task from its perspective. In other
words: the Eclipse tasks have there own little domain model tailored
for there needs. it is the job of the plugin that adds a task to a
project to translate its domain model to the domain model of the
task. This happens when the plugin is configuring the task.
I have filed some issues for the Eclipse plugin: http://
jira.codehaus.org/secure/IssueNavigator.jspa?
reset=true&&fixfor=14403&pid=11712&resolution=-1&component=13460&sorter/
field=priority&sorter/order=DESC
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
