Hans,
Thanks for the support. I'm sure we can figure something out, and
starting IDE support early will help shake out any issues before it
gets locked down in later releases. We'll start with IntelliJ and
layer so that we can make a follow-on Eclipse project easier, and also
think a bit about project generation for both at the same time.
Comments below...
On 2-Jun-08, at 2:25 AM, Hans Dockter wrote:
Hi Jayson,
IDE support has one of the highest priorities for Gradle. You will
get all the help you need from my side for implementing your plugin.
Great, thanks!
On May 31, 2008, at 1:45 AM, Jayson Minard wrote:
Hello Hans,
I'm looking at developing or having someone at my company develop
an IntelliJ plugin for Gradle for launching builds as well as
keeping the IntelliJ module library set up to date.
So consider the following set of items we most likely need to
accomplish:
- Instantiate and run Gradle directly and want to have it confer
the configured tasks to us
As Gradle builds the tasks graph before it starts the execution this
is basically easy. If you type gradle -t for a particular project
this graph is for example printed to the console. The only problem
is that it might takes a couple of seconds to generate this graph as
the build script has to be evaluated. A structured view of the
gradlefile in form of its task elements would be very cool. The
question is how to update it. Starting the graph generation for
every build script change might be too expensive.
There is always a good way to use pauses in developer actions, and
background work to catch up the graph. And there are always other
tricks to get as much as you can done OTHER than what is currently
being disrupted. We'll just have to see what plays out here to get as
tight of a feel as possible.
- be able to launch specific tasks
As soon as we have a task view this is easy.
Yep.
- finally hear the dependencies that are resolved and where we can
access them
Easy for normal dependencies. The problem are multi-project builds
as you want to have project dependencies between them. Gradle needs
to offer a method where you can ask explicitly for external
dependencies or project dependencies. This won't be too hard to
implement but is not available yet.
When we reach that point we'll see who can add it at the time. There
is a lot that can be done making sure normal dependency handling is
rock solid that buys some time here.
- configure where we would want the cache to exist locally in case
the user wants them to be cached within the module tree
Easy,
A magically self-maintaining lib dir is dandy!
- possibly silently make the Gradle jar available to the project
for gradlefile development
What I have in mind is a feature where you can specifically define a
classpath for the gradlefile. This classpath would be independent of
the classpath for the module. I don't know how difficult this is to
implement with IntelliJ. I have asked Eugene Vigdorchik, the
JetGroovy lead, about this a month ago. He wanted to think about it.
May be he has some good idea now ;). I'm sure he will give advise to
you for developing such a functionality.
I'll swing by and see where Eugene's thinking is... Also other
plugins that might do something similar out there.
What is easily available vs. hard to get at within Gradle? Any big
barriers in the way?
For 0.2 we want to implement a rich plugin system. One plan is to
let the plugins communicate directly with each other. One use case
are IDE plugins. We think about an Interface IdeAware which is
implemented for example by the Java plugin and the War plugin. The
IntelliJPlugin would be able to send request to all IdeAware plugins
(without knowing them) and those plugins would add information to
the IDE domain objects. With this information the IntelliJ plugin
can then build the IDE files. The development for 0.2 will start
next week.
Yes, an IdeAware core and IdeAware plugins. Possibly the IDE could
supplant some of the work of the build-script if it felt it needed to
(maybe IntelliJ wants to do some of the work on behalf of the build
script for some reason).
One thing we could start with is a test project with a gradlefile.
usePlugin('java')
dependencies {
// some declarations
}
createTask('intelliJ') {
// the logic for creating the intelliJ project files.
}
If this works we can refactor the intelliJ task into a plugin.
Sure, this would allow us to work out the dependency detection and
multi-project dependencies, then circle back to the right way to do it
internally in IntelliJ (which may not involve writing to module files
but doing the work using the API and letting IntelliJ handle the
module files; not sure yet).
What do you think?
Sounds good, will start pushing it in the next few days...
- Hans
Thanks for any kick-start help you can provide.
-- Jayson @ MindHeap
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
