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
- 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
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
