Hans,
On 3-Jun-08, at 1:14 AM, Hans Dockter wrote:
Hi Jason,
On Jun 3, 2008, at 8:42 AM, Jayson Minard wrote:
Hans,
Ok, I setup IntelliJ to debug through Gradle so that I can inspect
some of the internals a bit more. A thought came to mind...
Since IntelliJ does not natively support multiple build
configurations with differing classpaths.
So we need to think about options here, such as:
- allow the user to quickly select the build configuration and have
the classpath always reflect that current configuration
- map the build configuration in each run configuration and have
the current run configuration drive the current classpath (i.e. you
select a Gradle task to run before invoking a runtime configuration
just as you would Ant or Maven and we set the classpath to match
that task)
Such a mapping is already there. The DependecyManager has two methods:
dependencies {
resolve(configName) // returns the classpath for a configuration
resolveTask(taskName) // returns the classpath for a task (via
the conf2Tasks mapping)
println conf2Tasks // prints the conf2Tasks mapping
}
If you look in the DependencyManager interface at the method
comments you will get some more information.
But does the IntelliJ Runtime configurations line up to a same-named
Gradle configuration? If we do not always use testRuntime, we would
base it off the task they select to have run when starting a runtime
configuration.
- allow user to select a list of tasks to have classpaths pulled
from as a group so they can pick and chose from who knows what
they'll be adding to their Gradle file (i.e. a JDK 1.5 config vs. a
JDK 1.6)
Right
or some other way to move around between classpaths that can be
determined from a Gradle task.
Have you got use cases in mind where switching the configuration
classpath is relevant for the IDE integration?
An example is to ensure your support for JDK 1.5 vs. JDK 1.6 is valid
and you have different library sets that you work against for each. I
could therefore have a few compile configurations and a few test
configurations that have slightly different dependencies.
A very simple approach would be to use testRuntime as the classpath
configuration for Java/Groovy projects. This is basically the same
the Maven Eclipse plugin does for eclipse and I'd guess the Maven
IntelliJ plugin is doing the same.
That is the starting point for sure. I'm wondering it we shouldn't
allow for the user to choose as well, and then have a nice default.
I'm assuming that existing plugins aren't perfect and thinking it
through to see where we can avoid annoying the developers using the
plugin.
- Hans
--j
On Mon, Jun 2, 2008 at 9:59 PM, Jayson Minard <[EMAIL PROTECTED]
> wrote:
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
--
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
