applying groovy editor support to custom file

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

applying groovy editor support to custom file

RenŽé Gröschke
Hi there,
I'm actually working(/trying) on an eclipse plugin for gradle
(http://www.gradle.org).
After beeing able to run gradle build scripts via eclipse,  I would like
to link the groovy editor to all files in my workspace ending on
*.gradle. As a first attempt I added a editor extension point and use
the GroovyEditor as class. But this seems to be good practice right?
What's the best common way to link the groovy editor to gradle build files?

regards,
René

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: applying groovy editor support to custom file

Andrew Eisenberg
That's great!

To make gradle files behave like groovy files and open in the groovy
editor by default, you can:

As a user:

Preferences -> General -> Content Types

Browse:

Text -> Java Source File -> Groovy Source File

add *.gradle

As a plugin developer, you should create a new content type extension
point and associate it with gradle files.  For an example of how this
works, see the extension point in the org.eclipse.jdt.groovy.core
plugin.

I'm not sure that you need to create a new editor for gradle files.
What extra functionality are you looking for that the groovy editor
does not provide (or allow you to plug in to)?

On Tue, May 18, 2010 at 1:25 PM, RenŽé Gröschke <[hidden email]> wrote:

> Hi there,
> I'm actually working(/trying) on an eclipse plugin for gradle
> (http://www.gradle.org).
> After beeing able to run gradle build scripts via eclipse,  I would like to
> link the groovy editor to all files in my workspace ending on *.gradle. As a
> first attempt I added a editor extension point and use the GroovyEditor as
> class. But this seems to be good practice right? What's the best common way
> to link the groovy editor to gradle build files?
>
> regards,
> René
>
> ---------------------------------------------------------------------
> 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: applying groovy editor support to custom file

Nicolas Lalevée

Le 19 mai 2010 à 01:54, Andrew Eisenberg a écrit :

> That's great!
>
> To make gradle files behave like groovy files and open in the groovy
> editor by default, you can:
>
> As a user:
>
> Preferences -> General -> Content Types
>
> Browse:
>
> Text -> Java Source File -> Groovy Source File
>
> add *.gradle
>
> As a plugin developer, you should create a new content type extension
> point and associate it with gradle files.  For an example of how this
> works, see the extension point in the org.eclipse.jdt.groovy.core
> plugin.
>
> I'm not sure that you need to create a new editor for gradle files.
> What extra functionality are you looking for that the groovy editor
> does not provide (or allow you to plug in to)?

I have a similar need as René's one: I would like to have an editor of a groovy based build script.
As far as I can dig into the groovy eclipse plugin, it seems to be tied to the JDT. I would have expect that. But then I have some issues because it seems to be so tied that it cannot run (having more than syntax coloring) outside a java classpath.
As a build script editor I would expect it to run in any kind of eclipse project. The classpath of the build script would be controlled by my plugin rather than by the project the script is included in. Just like the ant build.xml editor is relying on the classpath defined in the Eclipse Ant preferences.

In the org.eclipse.jdt.groovy.core plugin, there are the following lines in GroovyCompilationUnit#buildStructure :

if (!isOnBuildPath()) {
    return false;
}

For my testing/hacking I tried with:

JavaModelManager.PerWorkingCopyInfo perWorkingCopyInfo = getPerWorkingCopyInfo();
CompilationUnit source = cloneCachingContents();
if (!isOnBuildPath()) {
    ModuleNode module = compile(source);
    ModuleNodeMapper.getInstance().store(perWorkingCopyInfo, module);
    return true;
}

It seems to work but I am absolutely not sure of what I am doing. Do you thing we can have something like this working properly ?

Nicolas



>
> On Tue, May 18, 2010 at 1:25 PM, RenŽé Gröschke <[hidden email]> wrote:
>> Hi there,
>> I'm actually working(/trying) on an eclipse plugin for gradle
>> (http://www.gradle.org).
>> After beeing able to run gradle build scripts via eclipse,  I would like to
>> link the groovy editor to all files in my workspace ending on *.gradle. As a
>> first attempt I added a editor extension point and use the GroovyEditor as
>> class. But this seems to be good practice right? What's the best common way
>> to link the groovy editor to gradle build files?
>>
>> regards,
>> René
>>
>> ---------------------------------------------------------------------
>> 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
>
>


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: applying groovy editor support to custom file

Andrew Eisenberg
Hi,

You suggestion will work in simple cases where the script only
accesses the standard groovy and java libraries, but once it tries to
access something in the current project or elsewhere, all sorts of
horrendous errors will start happening.

In fact, I think that your suggestion will start to break down in some
simple cases as well (eg- right click on the file and trying run as
will probably raise an exception).

We originally tried to allow scripts that were not on the build path
to be reconciled like regular groovy/java files, but this just causesd
too many problems.

There is currently a bug open for this:
http://jira.codehaus.org/browse/GRECLIPSE-714
I'd appreciate if you could add a few comments to describe your situation.

I think the best solution will be to be able to designate a certain
folder to be a script folder.  In this folder, groovy files will not
be compiled, but rather copied to the output directory.  This means
that you will get all the nice highlighting and navigation in your
script files, but without having them compiled.  However, this means,
of course that you will only have this capability in Groovy projects.

> I have a similar need as René's one: I would like to have an editor of a groovy based build script.
> As far as I can dig into the groovy eclipse plugin, it seems to be tied to the JDT. I would have expect that. But then I have some issues because it seems to be so tied that it cannot run (having more than syntax coloring) outside a java classpath.
> As a build script editor I would expect it to run in any kind of eclipse project. The classpath of the build script would be controlled by my plugin rather than by the project the script is included in. Just like the ant build.xml editor is relying on the classpath defined in the Eclipse Ant preferences.
>
> In the org.eclipse.jdt.groovy.core plugin, there are the following lines in GroovyCompilationUnit#buildStructure :
>
> if (!isOnBuildPath()) {
>    return false;
> }
>
> For my testing/hacking I tried with:
>
> JavaModelManager.PerWorkingCopyInfo perWorkingCopyInfo = getPerWorkingCopyInfo();
> CompilationUnit source = cloneCachingContents();
> if (!isOnBuildPath()) {
>    ModuleNode module = compile(source);
>    ModuleNodeMapper.getInstance().store(perWorkingCopyInfo, module);
>    return true;
> }
>
> It seems to work but I am absolutely not sure of what I am doing. Do you thing we can have something like this working properly ?
>
> Nicolas
>
>
>
>>
>> On Tue, May 18, 2010 at 1:25 PM, RenŽé Gröschke <[hidden email]> wrote:
>>> Hi there,
>>> I'm actually working(/trying) on an eclipse plugin for gradle
>>> (http://www.gradle.org).
>>> After beeing able to run gradle build scripts via eclipse,  I would like to
>>> link the groovy editor to all files in my workspace ending on *.gradle. As a
>>> first attempt I added a editor extension point and use the GroovyEditor as
>>> class. But this seems to be good practice right? What's the best common way
>>> to link the groovy editor to gradle build files?
>>>
>>> regards,
>>> René
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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: applying groovy editor support to custom file

Nicolas Lalevée

Le 19 mai 2010 à 17:53, Andrew Eisenberg a écrit :

> Hi,
>
> You suggestion will work in simple cases where the script only
> accesses the standard groovy and java libraries, but once it tries to
> access something in the current project or elsewhere, all sorts of
> horrendous errors will start happening.
>
> In fact, I think that your suggestion will start to break down in some
> simple cases as well (eg- right click on the file and trying run as
> will probably raise an exception).

But those things won't be an issue in my use case. I would like to use the syntax highlighting and completion from the groovy plugin. The launch should be handled by mine.

But I know the piece of code I shown is quite a hack. I am not hoping much of it. It is just a proof of concept. The real question is, is there a way to do it properly ?

> We originally tried to allow scripts that were not on the build path
> to be reconciled like regular groovy/java files, but this just causesd
> too many problems.

I fear that the answer to my question lies there... the JDT is not flexible enough to allow such manipulation of the classpath...

> There is currently a bug open for this:
> http://jira.codehaus.org/browse/GRECLIPSE-714
> I'd appreciate if you could add a few comments to describe your situation.
>
> I think the best solution will be to be able to designate a certain
> folder to be a script folder.  In this folder, groovy files will not
> be compiled, but rather copied to the output directory.  This means
> that you will get all the nice highlighting and navigation in your
> script files, but without having them compiled.  However, this means,
> of course that you will only have this capability in Groovy projects.

I would really like to avoid that, I would like my plugin to behave like the Ant one.

Would it be technically possible for my plugin to plug into the GroovyCompilationUnit, via an extension or something else, to "force" the compilation of the script with a provided classpath ?
I would also have some "ant model" computation to do in buildStructure. I would basically need to plug an AntModelMapper, just like there is a ModuleNodeMapper.

Another idea I had is having a fake groovy project, hidden from the end user but existing in JDT's model. This project would be setup with my controlled classpath. And somehow make the groovy build scripts copied/moved/linked into that fake project to be compiled and build there. It seems a hack too though. Do you think it would be worth investigating ?

Nicolas



>
>> I have a similar need as René's one: I would like to have an editor of a groovy based build script.
>> As far as I can dig into the groovy eclipse plugin, it seems to be tied to the JDT. I would have expect that. But then I have some issues because it seems to be so tied that it cannot run (having more than syntax coloring) outside a java classpath.
>> As a build script editor I would expect it to run in any kind of eclipse project. The classpath of the build script would be controlled by my plugin rather than by the project the script is included in. Just like the ant build.xml editor is relying on the classpath defined in the Eclipse Ant preferences.
>>
>> In the org.eclipse.jdt.groovy.core plugin, there are the following lines in GroovyCompilationUnit#buildStructure :
>>
>> if (!isOnBuildPath()) {
>>    return false;
>> }
>>
>> For my testing/hacking I tried with:
>>
>> JavaModelManager.PerWorkingCopyInfo perWorkingCopyInfo = getPerWorkingCopyInfo();
>> CompilationUnit source = cloneCachingContents();
>> if (!isOnBuildPath()) {
>>    ModuleNode module = compile(source);
>>    ModuleNodeMapper.getInstance().store(perWorkingCopyInfo, module);
>>    return true;
>> }
>>
>> It seems to work but I am absolutely not sure of what I am doing. Do you thing we can have something like this working properly ?
>>
>> Nicolas
>>
>>
>>
>>>
>>> On Tue, May 18, 2010 at 1:25 PM, RenŽé Gröschke <[hidden email]> wrote:
>>>> Hi there,
>>>> I'm actually working(/trying) on an eclipse plugin for gradle
>>>> (http://www.gradle.org).
>>>> After beeing able to run gradle build scripts via eclipse,  I would like to
>>>> link the groovy editor to all files in my workspace ending on *.gradle. As a
>>>> first attempt I added a editor extension point and use the GroovyEditor as
>>>> class. But this seems to be good practice right? What's the best common way
>>>> to link the groovy editor to gradle build files?
>>>>
>>>> regards,
>>>> René
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: applying groovy editor support to custom file

Andrew Eisenberg
> But those things won't be an issue in my use case. I would like to use the syntax highlighting and completion from the groovy plugin. The launch should be handled by mine.

The way that Eclipse calculates which launchers are available at a
particular location will require the buildStructure method to be
called.  In all but the simplest cases, this will throw an exception
somewhere deep inside the call.  Fixing this would be extremely
complicated (and may require significant changes to how Groovy-Eclipse
looks for dependencies).  This has nothing to do with any launchers
that you add to the project.

Syntax highlighting will work no matter where your script is placed,
but content assist will also raise similar exceptions in all but the
simplest circumstances.

Essentially, what I am saying is that calling the build structure
method for scripts outside the build path will cause some
unpredictable behavior

>
> But I know the piece of code I shown is quite a hack. I am not hoping much of it. It is just a proof of concept. The real question is, is there a way to do it properly ?
>
>> We originally tried to allow scripts that were not on the build path
>> to be reconciled like regular groovy/java files, but this just causesd
>> too many problems.
>
> I fear that the answer to my question lies there... the JDT is not flexible enough to allow such manipulation of the classpath...

Unfortunately, that is correct.


>> I think the best solution will be to be able to designate a certain
>> folder to be a script folder.  In this folder, groovy files will not
>> be compiled, but rather copied to the output directory.  This means
>> that you will get all the nice highlighting and navigation in your
>> script files, but without having them compiled.  However, this means,
>> of course that you will only have this capability in Groovy projects.
>
> I would really like to avoid that, I would like my plugin to behave like the Ant one.

There is a major difference between how the ant editor calculates
content assist and how the groovy editor does.  The ant editor uses a
simple parse to gather context information (the results are fairly
sophisticated because ant is fundamentally simpler than groovy to
process).  The groovy editor uses a reconcile (which is like a
compile, but does not produce byte code) to perform content assist and
determine context information.  Again, this is not something that can
happen outside of the build path.

It could be feasible to have a second mode of content assist
calculation for the groovy script, one that does not do a reconcile,
but only uses local context information to determine proposals.
However, this would be a major piece of work.

> Would it be technically possible for my plugin to plug into the GroovyCompilationUnit, via an extension or something else, to "force" the compilation of the script with a provided classpath ?
> I would also have some "ant model" computation to do in buildStructure. I would basically need to plug an AntModelMapper, just like there is a ModuleNodeMapper.

To do this, you probably need to add a CompilationParticipant via the
org.eclipse.jdt.core.compilationParticipant extension point.  This
will get called after every reconcile.

>
> Another idea I had is having a fake groovy project, hidden from the end user but existing in JDT's model. This project would be setup with my controlled classpath. And somehow make the groovy build scripts copied/moved/linked into that fake project to be compiled and build there. It seems a hack too though. Do you think it would be worth investigating ?

Creating a mock project with no physical location on disk would be
tricky since so many Eclipse operations on Groovy/Java projects just
assume that they are backed by folders.

I still don't see why you do not like the idea of having a script
folder that is on the build path, but not compiled.  This does seem
like it would address most of your problems.

>
> Nicolas
>
>
>
>>
>>> I have a similar need as René's one: I would like to have an editor of a groovy based build script.
>>> As far as I can dig into the groovy eclipse plugin, it seems to be tied to the JDT. I would have expect that. But then I have some issues because it seems to be so tied that it cannot run (having more than syntax coloring) outside a java classpath.
>>> As a build script editor I would expect it to run in any kind of eclipse project. The classpath of the build script would be controlled by my plugin rather than by the project the script is included in. Just like the ant build.xml editor is relying on the classpath defined in the Eclipse Ant preferences.
>>>
>>> In the org.eclipse.jdt.groovy.core plugin, there are the following lines in GroovyCompilationUnit#buildStructure :
>>>
>>> if (!isOnBuildPath()) {
>>>    return false;
>>> }
>>>
>>> For my testing/hacking I tried with:
>>>
>>> JavaModelManager.PerWorkingCopyInfo perWorkingCopyInfo = getPerWorkingCopyInfo();
>>> CompilationUnit source = cloneCachingContents();
>>> if (!isOnBuildPath()) {
>>>    ModuleNode module = compile(source);
>>>    ModuleNodeMapper.getInstance().store(perWorkingCopyInfo, module);
>>>    return true;
>>> }
>>>
>>> It seems to work but I am absolutely not sure of what I am doing. Do you thing we can have something like this working properly ?
>>>
>>> Nicolas
>>>
>>>
>>>
>>>>
>>>> On Tue, May 18, 2010 at 1:25 PM, RenŽé Gröschke <[hidden email]> wrote:
>>>>> Hi there,
>>>>> I'm actually working(/trying) on an eclipse plugin for gradle
>>>>> (http://www.gradle.org).
>>>>> After beeing able to run gradle build scripts via eclipse,  I would like to
>>>>> link the groovy editor to all files in my workspace ending on *.gradle. As a
>>>>> first attempt I added a editor extension point and use the GroovyEditor as
>>>>> class. But this seems to be good practice right? What's the best common way
>>>>> to link the groovy editor to gradle build files?
>>>>>
>>>>> regards,
>>>>> René
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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: applying groovy editor support to custom file

Nicolas Lalevée

Le 20 mai 2010 à 18:39, Andrew Eisenberg a écrit :

>> But those things won't be an issue in my use case. I would like to use the syntax highlighting and completion from the groovy plugin. The launch should be handled by mine.
>
> The way that Eclipse calculates which launchers are available at a
> particular location will require the buildStructure method to be
> called.  In all but the simplest cases, this will throw an exception
> somewhere deep inside the call.  Fixing this would be extremely
> complicated (and may require significant changes to how Groovy-Eclipse
> looks for dependencies).  This has nothing to do with any launchers
> that you add to the project.
>
> Syntax highlighting will work no matter where your script is placed,
> but content assist will also raise similar exceptions in all but the
> simplest circumstances.
>
> Essentially, what I am saying is that calling the build structure
> method for scripts outside the build path will cause some
> unpredictable behavior
>
>>
>> But I know the piece of code I shown is quite a hack. I am not hoping much of it. It is just a proof of concept. The real question is, is there a way to do it properly ?
>>
>>> We originally tried to allow scripts that were not on the build path
>>> to be reconciled like regular groovy/java files, but this just causesd
>>> too many problems.
>>
>> I fear that the answer to my question lies there... the JDT is not flexible enough to allow such manipulation of the classpath...
>
> Unfortunately, that is correct.
>
>
>>> I think the best solution will be to be able to designate a certain
>>> folder to be a script folder.  In this folder, groovy files will not
>>> be compiled, but rather copied to the output directory.  This means
>>> that you will get all the nice highlighting and navigation in your
>>> script files, but without having them compiled.  However, this means,
>>> of course that you will only have this capability in Groovy projects.
>>
>> I would really like to avoid that, I would like my plugin to behave like the Ant one.
>
> There is a major difference between how the ant editor calculates
> content assist and how the groovy editor does.  The ant editor uses a
> simple parse to gather context information (the results are fairly
> sophisticated because ant is fundamentally simpler than groovy to
> process).  The groovy editor uses a reconcile (which is like a
> compile, but does not produce byte code) to perform content assist and
> determine context information.  Again, this is not something that can
> happen outside of the build path.
>
> It could be feasible to have a second mode of content assist
> calculation for the groovy script, one that does not do a reconcile,
> but only uses local context information to determine proposals.
> However, this would be a major piece of work.
>
>> Would it be technically possible for my plugin to plug into the GroovyCompilationUnit, via an extension or something else, to "force" the compilation of the script with a provided classpath ?
>> I would also have some "ant model" computation to do in buildStructure. I would basically need to plug an AntModelMapper, just like there is a ModuleNodeMapper.
>
> To do this, you probably need to add a CompilationParticipant via the
> org.eclipse.jdt.core.compilationParticipant extension point.  This
> will get called after every reconcile.
>
>>
>> Another idea I had is having a fake groovy project, hidden from the end user but existing in JDT's model. This project would be setup with my controlled classpath. And somehow make the groovy build scripts copied/moved/linked into that fake project to be compiled and build there. It seems a hack too though. Do you think it would be worth investigating ?
>
> Creating a mock project with no physical location on disk would be
> tricky since so many Eclipse operations on Groovy/Java projects just
> assume that they are backed by folders.
>
> I still don't see why you do not like the idea of having a script
> folder that is on the build path, but not compiled.  This does seem
> like it would address most of your problems.

Because the project in which will lie the groovy build script may not have the proper build path. I would like to have those groovy build script be able to build some flex project for instance. And even if the containing project appears to have the proper nature, I don't want to mix the classpath of the project with the classpath used for by build script.

Maybe I should I have started by explaining in detail my use case: I have developed a groovy "frontend" to ant which allows you to write standard ant script in groovy rather than XML: http://people.apache.org/~hibou/groovyfront-doc/doc.html . So my goal here is to implement a plugin which would somehow use both the ant and groovy plugin.

But as you wrote (thank you for taking time to answer me) and as I feared, it doesn't seem to be doable, as least with complete groovy completion.

Nicolas

>
>>
>> Nicolas
>>
>>
>>
>>>
>>>> I have a similar need as René's one: I would like to have an editor of a groovy based build script.
>>>> As far as I can dig into the groovy eclipse plugin, it seems to be tied to the JDT. I would have expect that. But then I have some issues because it seems to be so tied that it cannot run (having more than syntax coloring) outside a java classpath.
>>>> As a build script editor I would expect it to run in any kind of eclipse project. The classpath of the build script would be controlled by my plugin rather than by the project the script is included in. Just like the ant build.xml editor is relying on the classpath defined in the Eclipse Ant preferences.
>>>>
>>>> In the org.eclipse.jdt.groovy.core plugin, there are the following lines in GroovyCompilationUnit#buildStructure :
>>>>
>>>> if (!isOnBuildPath()) {
>>>>    return false;
>>>> }
>>>>
>>>> For my testing/hacking I tried with:
>>>>
>>>> JavaModelManager.PerWorkingCopyInfo perWorkingCopyInfo = getPerWorkingCopyInfo();
>>>> CompilationUnit source = cloneCachingContents();
>>>> if (!isOnBuildPath()) {
>>>>    ModuleNode module = compile(source);
>>>>    ModuleNodeMapper.getInstance().store(perWorkingCopyInfo, module);
>>>>    return true;
>>>> }
>>>>
>>>> It seems to work but I am absolutely not sure of what I am doing. Do you thing we can have something like this working properly ?
>>>>
>>>> Nicolas
>>>>
>>>>
>>>>
>>>>>
>>>>> On Tue, May 18, 2010 at 1:25 PM, RenŽé Gröschke <[hidden email]> wrote:
>>>>>> Hi there,
>>>>>> I'm actually working(/trying) on an eclipse plugin for gradle
>>>>>> (http://www.gradle.org).
>>>>>> After beeing able to run gradle build scripts via eclipse,  I would like to
>>>>>> link the groovy editor to all files in my workspace ending on *.gradle. As a
>>>>>> first attempt I added a editor extension point and use the GroovyEditor as
>>>>>> class. But this seems to be good practice right? What's the best common way
>>>>>> to link the groovy editor to gradle build files?
>>>>>>
>>>>>> regards,
>>>>>> René
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>


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

    http://xircles.codehaus.org/manage_email