>> 7. There is one last thing with the Tooling API. Instead of having
>> EclipseProject, IdeaProject or similar, it would be benefical to have a view
>> of the project which is more native to Gradle. In fact, I think maintaining
>> EclipseProject and IdeaProject is a waste of effort. If you could create
>> only one model, which more native to Gradle, one could transform it
>> different model as he/she wishes. Writing a method which converts the native
>> view could be measured in hours but if you do this in the Tooling API, it
>> takes a much larger effort because you need to consider backward (or worse,
>> forward) compatibilty. Here is an example model:
>> https://github.com/kelemen/gradle-model-example. Note that I only spent a
>> few hours creating this (including the apidoc), so it is likely in a need
>> for some adjustment. As a last word for this issue, I think you should mark
>> the current models deprecated and create a model which contains more
>> information and is more close to how Gradle sees the world.
I think there are at least 2 ideas here:
1. offer lower level api that is less constrained by the
backward/forward compatibility.
2. offer more generic IDE model. It's a little bit awkward that
NetBeans integration uses eclipse classes, we're missing an
abstraction (or alternatively, a discrete implementation, but I prefer
the generic model).
I think both of them have pros & cons and are good ideas in general
(if executed correctly).
Cheers!
--
Szczepan Faber
Principal engineer@gradleware
Lead@mockito
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
