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 <[EMAIL PROTECTED]>
wrote:
> Hans,
>
> Thanks for the support. I'm sure we can figure something out, and starting
> IDE support early will help shake out any issues before it gets locked down
> in later releases. We'll start with IntelliJ and layer so that we can make
> a follow-on Eclipse project easier, and also think a bit about project
> generation for both at the same time.
>
> Comments below...
>
> On 2-Jun-08, at 2:25 AM, Hans Dockter wrote:
>
> Hi Jayson,
>>
>> IDE support has one of the highest priorities for Gradle. You will get all
>> the help you need from my side for implementing your plugin.
>>
>
> Great, thanks!
>
>
>>
>> On May 31, 2008, at 1:45 AM, Jayson Minard wrote:
>>
>> Hello Hans,
>>>
>>> I'm looking at developing or having someone at my company develop an
>>> IntelliJ plugin for Gradle for launching builds as well as keeping the
>>> IntelliJ module library set up to date.
>>>
>>> So consider the following set of items we most likely need to accomplish:
>>>
>>> - Instantiate and run Gradle directly and want to have it confer the
>>> configured tasks to us
>>>
>>
>> As Gradle builds the tasks graph before it starts the execution this is
>> basically easy. If you type gradle -t for a particular project this graph is
>> for example printed to the console. The only problem is that it might takes
>> a couple of seconds to generate this graph as the build script has to be
>> evaluated. A structured view of the gradlefile in form of its task elements
>> would be very cool. The question is how to update it. Starting the graph
>> generation for every build script change might be too expensive.
>>
>
> There is always a good way to use pauses in developer actions, and
> background work to catch up the graph. And there are always other tricks to
> get as much as you can done OTHER than what is currently being disrupted.
> We'll just have to see what plays out here to get as tight of a feel as
> possible.
>
>
>>
>> - be able to launch specific tasks
>>>
>>
>> As soon as we have a task view this is easy.
>>
>
> Yep.
>
>
>>
>> - finally hear the dependencies that are resolved and where we can access
>>> them
>>>
>>
>> Easy for normal dependencies. The problem are multi-project builds as you
>> want to have project dependencies between them. Gradle needs to offer a
>> method where you can ask explicitly for external dependencies or project
>> dependencies. This won't be too hard to implement but is not available yet.
>>
>
> When we reach that point we'll see who can add it at the time. There is a
> lot that can be done making sure normal dependency handling is rock solid
> that buys some time here.
>
>
> - configure where we would want the cache to exist locally in case the
>>> user wants them to be cached within the module tree
>>>
>>
>> Easy,
>>
>
> A magically self-maintaining lib dir is dandy!
>
>
>>
>> - possibly silently make the Gradle jar available to the project for
>>> gradlefile development
>>>
>>
>> What I have in mind is a feature where you can specifically define a
>> classpath for the gradlefile. This classpath would be independent of the
>> classpath for the module. I don't know how difficult this is to implement
>> with IntelliJ. I have asked Eugene Vigdorchik, the JetGroovy lead, about
>> this a month ago. He wanted to think about it. May be he has some good idea
>> now ;). I'm sure he will give advise to you for developing such a
>> functionality.
>>
>>
> I'll swing by and see where Eugene's thinking is... Also other plugins
> that might do something similar out there.
>
>
>
>>> What is easily available vs. hard to get at within Gradle? Any big
>>> barriers in the way?
>>>
>>
>> For 0.2 we want to implement a rich plugin system. One plan is to let the
>> plugins communicate directly with each other. One use case are IDE plugins.
>> We think about an Interface IdeAware which is implemented for example by the
>> Java plugin and the War plugin. The IntelliJPlugin would be able to send
>> request to all IdeAware plugins (without knowing them) and those plugins
>> would add information to the IDE domain objects. With this information the
>> IntelliJ plugin can then build the IDE files. The development for 0.2 will
>> start next week.
>>
>>
> Yes, an IdeAware core and IdeAware plugins. Possibly the IDE could
> supplant some of the work of the build-script if it felt it needed to (maybe
> IntelliJ wants to do some of the work on behalf of the build script for some
> reason).
>
>
> One thing we could start with is a test project with a gradlefile.
>>
>> usePlugin('java')
>> dependencies {
>> // some declarations
>> }
>>
>> createTask('intelliJ') {
>> // the logic for creating the intelliJ project files.
>> }
>>
>> If this works we can refactor the intelliJ task into a plugin.
>>
>>
> Sure, this would allow us to work out the dependency detection and
> multi-project dependencies, then circle back to the right way to do it
> internally in IntelliJ (which may not involve writing to module files but
> doing the work using the API and letting IntelliJ handle the module files;
> not sure yet).
>
>
> What do you think?
>>
>>
> Sounds good, will start pushing it in the next few days...
>
>
> - Hans
>>
>>
>>> Thanks for any kick-start help you can provide.
>>> -- Jayson @ MindHeap
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>> --
>> Hans Dockter
>> Gradle Project lead
>> http://www.gradle.org
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
