Eclipse tasks

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Eclipse tasks


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  

- 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  
- 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://

- Hans

Hans Dockter
Gradle Project lead

To unsubscribe from this list, please visit: