Hey Hans,
On 3-Jun-08, at 1:24 PM, Hans Dockter wrote:
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 optional is due to the fact that some people will not use
configurations at all in Gradle and will just invoke tasks that happen
to also have an implied configuration of the same name. So they must
at least specify the task, or at least a configuration, and at most
the task + configuration. We need one of those to determine the right
classpath for running the application, tests or whatever the run/debug
configuration in IntelliJ is trying to do.
The gradle task is for some additional things to do? Another way we
enhance IntelliJ. Cool.
The Gradle task is there to match the ANT and Maven plugins which
allow you to build when hitting the "Run" or "Debug" actions in the
IDE. You tell it what it needs to do to get things ready for
execution and in our case that is selecting the right Gradle task if
any (yes, "none" is valid if you are running from something that you
don't build or want to build).
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?
It won't recompile until you actual invoke Run or Debug and only if
you tell it to do so. It will instead set the classpaths to the new
values, IntelliJ will then respond by adjusting its background
intelligent parsing/compilation that it uses to display errors and
such. It is probably best to build as well, but not always neccessary
at that time. I'll see how it plays out and know more once we do it.
So more on this after I get that far :)
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?
Yes. That is what it means. IntelliJ has to understand the code to
work well (refactoring, error highlighting, and more) so you want the
right classpath when editing not just compiling/running.
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?
internally = the code would support a list of configurations or tasks
rather than just one even if we never expose that option to the user;
just in case. I'm not sure about that being a friendly user feature
and it being confusing or not, so preparing in case it is so that I
don't come back and say "Ohhhh, if I had known you wanted that I would
have done a lot differently, now you have to wait 2 months for me to
make that change." I'd rather have 2 days be the response window.
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 :)
Me either. I am committing a large project to use Gradle and we need
the plugins so the team doesn't kill me for that decision, so have
plenty of reasons here to get it moving!
--j
- 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
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
