IntelliJ plugin

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

IntelliJ plugin

Jayson Minard
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
- be able to launch specific tasks
- finally hear the dependencies that are resolved and where we can  
access them
- configure where we would want the cache to exist locally in case the  
user wants them to be cached within the module tree
- possibly silently make the Gradle jar available to the project for  
gradlefile development

What is easily available vs. hard to get at within Gradle?  Any big  
barriers in the way?

Thanks for any kick-start help you can provide.
-- Jayson @ MindHeap

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: IntelliJ plugin

hans_d
Administrator
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.

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.

> - be able to launch specific tasks

As soon as we have a task view this is easy.

> - 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.

> - configure where we would want the cache to exist locally in case  
> the user wants them to be cached within the module tree

Easy,

> - 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.

>
> 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.

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.

What do you think?

- 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


Reply | Threaded
Open this post in threaded view
|

Re: IntelliJ plugin

Jayson Minard
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


Reply | Threaded
Open this post in threaded view
|

Re: IntelliJ plugin

Jayson Minard
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)
- 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)

or some other way to move around between classpaths that can be determined from a Gradle task.

--j

On Mon, Jun 2, 2008 at 9:59 PM, Jayson Minard <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: IntelliJ plugin

hans_d
Administrator
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.

> - 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?

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.

- Hans

>
> --j
>
> On Mon, Jun 2, 2008 at 9:59 PM, Jayson Minard  
> <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: IntelliJ plugin

Jayson Minard
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 <[hidden email]
>> > 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


Reply | Threaded
Open this post in threaded view
|

Re: IntelliJ plugin

hans_d
Administrator
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  
>>> <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: IntelliJ plugin

Jayson Minard
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.

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 with
- match the current IntelliJ Run/Debug configuration that is selected

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)

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.

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.

--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


Reply | Threaded
Open this post in threaded view
|

Re: IntelliJ plugin

hans_d
Administrator
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


Reply | Threaded
Open this post in threaded view
|

Re: IntelliJ plugin

Jayson Minard
Hey simple question...

What is the best way to direct IVY within Gradle as to where you want  
it to download dependencies (instead of to $home/.ivy dirs)?

--j

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 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
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: IntelliJ plugin

Jayson Minard
In reply to this post by hans_d
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


Reply | Threaded
Open this post in threaded view
|

Re: IntelliJ plugin

hans_d
Administrator
In reply to this post by Jayson Minard

On Jun 3, 2008, at 10:54 PM, Jayson Minard wrote:

> Hey simple question...
>
> What is the best way to direct IVY within Gradle as to where you  
> want it to download dependencies (instead of to $home/.ivy dirs)?

In 0.1.4 there is a bug that Gradle downloads dependencies and  
descriptor files into .ivy2/cache instead of .gradle/cache. This is  
fixed in svn.

The default location is the Gradle user home dir. You can change the  
gradle user home dir but not the fact that gradle user home is used  
for the cache right now. We could improve this easily.

What is your use case for having a different location?

- Hans

>
> --j
>
> 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 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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


Reply | Threaded
Open this post in threaded view
|

Re: IntelliJ plugin

Jayson Minard
Hans,

On 3-Jun-08, at 11:39 PM, Hans Dockter wrote:

>
> On Jun 3, 2008, at 10:54 PM, Jayson Minard wrote:
>
>> Hey simple question...
>>
>> What is the best way to direct IVY within Gradle as to where you  
>> want it to download dependencies (instead of to $home/.ivy dirs)?
>
> In 0.1.4 there is a bug that Gradle downloads dependencies and  
> descriptor files into .ivy2/cache instead of .gradle/cache. This is  
> fixed in svn.
>
> The default location is the Gradle user home dir. You can change the  
> gradle user home dir but not the fact that gradle user home is used  
> for the cache right now. We could improve this easily.
>
> What is your use case for having a different location?

First it allows projects to be isolated from each other in a  
guaranteed way (rather than we hope that two repositories don't return  
two different versions of the same JAR and mess up the cache).  
Second, I would like the build to be able to leave behind dependency  
artifacts (like you might with Ivy) within your tree so that you can  
freeze them locally if you want.  I.e. have a local resolver ahead of  
a remote resolver and have the remote resolver pull to the same dir as  
the local resolver.  Allows you to cache and survive internet  
disconnects, etc.   It is also nicer to wire the project up to have  
its dependencies in a known place for the IDE's, makes the projects  
portable so you can zip them up and send them off if you wanted.  By  
convention it can default to the home dir, but that should be able to  
be overridden to directories such as ./lib

I could submit a patch for this, but I'm trying to get in deeper on  
the plugin side first which has plenty of tricky areas to tie into  
IntelliJ as it is :)

--j


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: IntelliJ plugin

hans_d
Administrator
Hi Jayson,

On Jun 4, 2008, at 9:06 AM, Jayson Minard wrote:

> Hans,
>
> On 3-Jun-08, at 11:39 PM, Hans Dockter wrote:
>
>>
>> On Jun 3, 2008, at 10:54 PM, Jayson Minard wrote:
>>
>>> Hey simple question...
>>>
>>> What is the best way to direct IVY within Gradle as to where you  
>>> want it to download dependencies (instead of to $home/.ivy dirs)?
>>
>> In 0.1.4 there is a bug that Gradle downloads dependencies and  
>> descriptor files into .ivy2/cache instead of .gradle/cache. This  
>> is fixed in svn.
>>
>> The default location is the Gradle user home dir. You can change  
>> the gradle user home dir but not the fact that gradle user home is  
>> used for the cache right now. We could improve this easily.
>>
>> What is your use case for having a different location?
>
> First it allows projects to be isolated from each other in a  
> guaranteed way (rather than we hope that two repositories don't  
> return two different versions of the same JAR and mess up the  
> cache).  Second, I would like the build to be able to leave behind  
> dependency artifacts (like you might with Ivy) within your tree so  
> that you can freeze them locally if you want.  I.e. have a local  
> resolver ahead of a remote resolver and have the remote resolver  
> pull to the same dir as the local resolver.  Allows you to cache  
> and survive internet disconnects, etc.   It is also nicer to wire  
> the project up to have its dependencies in a known place for the  
> IDE's, makes the projects portable so you can zip them up and send  
> them off if you wanted.  By convention it can default to the home  
> dir, but that should be able to be overridden to directories such  
> as ./lib

I like this very much.

>
> I could submit a patch for this, but I'm trying to get in deeper on  
> the plugin side first which has plenty of tricky areas to tie into  
> IntelliJ as it is :)

I'm happy to work on this very soon. Just always let me know what new  
Gradle feature you need most urgent.

- Hans

>
> --j
>
>
> ---------------------------------------------------------------------
> 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


Reply | Threaded
Open this post in threaded view
|

IntelliJ Plugin - restructure Gradle main(), and other topics

Jayson Minard
Hey Hans,

I really could use some restructuring of the main() startup point for  
Gradle.  As it stands, going through the ToolsMain or Main classes  
isolates me from being able to see the internals of the build as it  
happens, or when it is between stages, or even done.

I also may want to have events that allow me to post progress other  
than just log output.

Do you have any issues with me taking a stab at the refactoring?  Or  
would you rather have a list of requirements (they'll be coming  
incrementally as I discover them) for you to make changes towards?

Lastly, are you aware of any static variables (i.e. static cache) that  
I may run into when running multiple instances of Gradle at the same  
time across different projects?

Thanks!
-- Jayson

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: IntelliJ Plugin - restructure Gradle main(), and other topics

hans_d
Administrator
Hi Jayson,

On Jun 5, 2008, at 8:04 AM, Jayson Minard wrote:

> Hey Hans,
>
> I really could use some restructuring of the main() startup point  
> for Gradle.  As it stands, going through the ToolsMain or Main  
> classes isolates me from being able to see the internals of the  
> build as it happens, or when it is between stages, or even done.

I have expected this issue :)

>
> I also may want to have events that allow me to post progress other  
> than just log output.

http://jira.codehaus.org/browse/GRADLE-3

>
> Do you have any issues with me taking a stab at the refactoring?  
> Or would you rather have a list of requirements (they'll be coming  
> incrementally as I discover them) for you to make changes towards?

No issues at all. That would be awesome.  I'm really looking forward  
that people like you getting into the internals of Gradle, give  
feedback and make it more and more a collaborative effort.

If you have an issue you want me to solve just ping me and I will do  
it with high priority.

>
> Lastly, are you aware of any static variables (i.e. static cache)  
> that I may run into when running multiple instances of Gradle at  
> the same time across different projects?

Gradle itself has no static state except the loggers. For the two-
phase logging I need to refactor logging anyway and could have a look  
into this. Right now nothing will break because of logging, the logs  
would be just not separated. As there is console logging only right  
now this is no problem. There could be also issues with Ivy if  
multiple Gradle instances use the same cache. Ivy offers some  
isolation functionality for this, but I haven't had a look at this yet.

- Hans

>
> Thanks!
> -- Jayson
>
> ---------------------------------------------------------------------
> 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


Reply | Threaded
Open this post in threaded view
|

Re: IntelliJ Plugin - restructure Gradle main(), and other topics

Jayson Minard
Ok, thanks!  I almost have enough of a shell to start tying Gradle in.

I created a separation between the IDE and the main plugin logic so  
that I can test the plugin with a headless IDE.  I'm working on  
learning Groovy unit testing for Java code real quick and starting my  
first tests for the basic startup/shutdown of the plugin and settings  
storage.  Then I'll continue into the body and revamp the main  
methods.  I'll be sure to update before I do the refactoring so the  
patch is close to the head of SVN.

--j

On 4-Jun-08, at 11:51 PM, Hans Dockter wrote:

> Hi Jayson,
>
> On Jun 5, 2008, at 8:04 AM, Jayson Minard wrote:
>
>> Hey Hans,
>>
>> I really could use some restructuring of the main() startup point  
>> for Gradle.  As it stands, going through the ToolsMain or Main  
>> classes isolates me from being able to see the internals of the  
>> build as it happens, or when it is between stages, or even done.
>
> I have expected this issue :)
>
>>
>> I also may want to have events that allow me to post progress other  
>> than just log output.
>
> http://jira.codehaus.org/browse/GRADLE-3
>
>>
>> Do you have any issues with me taking a stab at the refactoring?  
>> Or would you rather have a list of requirements (they'll be coming  
>> incrementally as I discover them) for you to make changes towards?
>
> No issues at all. That would be awesome.  I'm really looking forward  
> that people like you getting into the internals of Gradle, give  
> feedback and make it more and more a collaborative effort.
>
> If you have an issue you want me to solve just ping me and I will do  
> it with high priority.
>
>>
>> Lastly, are you aware of any static variables (i.e. static cache)  
>> that I may run into when running multiple instances of Gradle at  
>> the same time across different projects?
>
> Gradle itself has no static state except the loggers. For the two-
> phase logging I need to refactor logging anyway and could have a  
> look into this. Right now nothing will break because of logging, the  
> logs would be just not separated. As there is console logging only  
> right now this is no problem. There could be also issues with Ivy if  
> multiple Gradle instances use the same cache. Ivy offers some  
> isolation functionality for this, but I haven't had a look at this  
> yet.
>
> - Hans
>
>>
>> Thanks!
>> -- Jayson
>>
>> ---------------------------------------------------------------------
>> 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