Hi Jayson,
On Jun 3, 2008, at 8:34 PM, Jayson Minard wrote:
The thread is getting long on the quotes, I'll distill it here into
my current thoughts; and now I'm better at the names so will use
correct names for everything which helps:
A project and each module can detect its gradlefile or allow you to
specify an alternative file just as you can with ANT build files in
IntelliJ.
For a IntelliJ Run/Debug configuration you can choose the
gradlefile (defaults to the module one), a Gradle task to execute
before running, and the optional Gradle configuration (optional) to
operate under as well.
I see. The optional gradle configuration is for the classpath, right?
The gradle task is for some additional things to do? Another way we
enhance IntelliJ. Cool.
When coding, we will set the IntelliJ module dependencies to match
the Gradle testRuntime configuration + test task by default, but
allow the user to change that behavior to one of the following:
- choose an alternate Gradle configuration and/or task to sync the
dependencies wi
OK
- match the current IntelliJ Run/Debug configuration that is selected
Changing the current Run/Debug configuration would trigger a recompile?
and possibly if the use cases support it:
- merge a list of Gradle configuration and/or tasks to sync
dependencies with (i.e. create a mixture of random selections so
that they can edit and work nicely without errors in the editor)
I think don't understand this. Error in the editor means: faulty
content assist and red curly lines because of compile problems?
The last option will be allowed for internally, but not necessarily
exposed unless we find use cases that need it. I.e. have a list of
configurations+tasks to use rather than a single one internally.
What do you mean with internally?
That provides a lot of flexibility without going overboard early
and allows more complex projects that aren't just default looking
Java/Groovy projects.
IntelliJ will be more powerful when using Gradle as it will now
have the ability to tune its dependency list situationally just as
Gradle does which it cannot currently do.
I would like to make sure Gradle gets a one-up on the other guys
since it deserves the attention and a better plugin can help that.
Eclipse is next on the list and we'll see what can be done there as
it can be a rough environment for modules and dependencies and this
is another way it can be tuned up as well.
This sounds very good. I can't wait to use this plugin myself :)
- Hans
--j
On 3-Jun-08, at 8:52 AM, Hans Dockter wrote:
Hi Jayson,
On Jun 3, 2008, at 5:09 PM, Jayson Minard wrote:
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.
I guess I have misunderstood the original statement (map the build
configuration in each ...).
To understand:
A run configuration is a concept introduced by the Gradle IntelliJ
Plugin?
Invoking a runtime configuration means letting it change the
IntelliJ files of the project/module?
I still don't understand: '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'
Just to mention it. A Gradle dependency configuration is distinct
from a Gradle task, although sometimes they have the same name. A
Gradle task might be mapped to a dependency configuration (e.g.
compile task) but not necessarily (e.g. clean task).
- 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
Task or Dependency Configuration?
or some other way to move around between classpaths that can be
determined from a Gradle task.
Task or Dependency Configuration?
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.
I was asking because I was curios and I had overread the example
you have given in your original mail (JDK1.5/1.6). What we are
doing here is to use Gradle to extend IntelliJ. This would even
have a purpose if we never, ever execute a Gradle build for this
project. Cool.
- Hans
---------------------------------------------------------------------
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
