Quantcast

Accessing GroovyCompilationUnit from DSLD

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Accessing GroovyCompilationUnit from DSLD

Kohsuke Kawaguchi
I'm trying to write a DSL descriptor that needs to access the
GroovyCompilationUnit that represents the source file in which the
completion is provided.
(my completion is context sensitive to the relative path of the script
from within the source root --- I want to figure out the equivalent of
the package name, even though the Groovy script files need not have
the package declaration.)

Can anyone tell me how I can obtain a reference to it from within the
contribution closure?

On a related note, I'm looking at
DSLContributionGroup.getContributions(), and I noticed that it doesn't
expose GroovyDSLDContext itself to the contribution closure. Is there
a reason it doens't do this? GroovyDSLDContext object exposes a lot of
useful information that I think would benefit the contribution
closures.

--
Kohsuke Kawaguchi                          http://kohsuke.org/

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Accessing GroovyCompilationUnit from DSLD

Andrew Eisenberg
Hi,

This is a pointcut that I have not implemented yet, mostly because I
just haven't seen an example that requires it until now.  There are
many of these kinds of pointcuts and I am waiting for requests from
users before implementing.  So, let me put this together and I will
let you know when it is in a dev build.

Just to be sure that I understand...you require matching on the
package folder of the current file.  You can't match on the package
name since the package statement may not be around.  I'll make a
pointcut called 'packageFolder' or something like that.

To answer your second question...I am reluctant to expose an
Eclipse-specific API inside of contribution blocks since I do not want
the DSLDs to be tied to Eclipse.  That being said, there are some
places where the abstraction is a bit leaky (eg- the nature pointcut)
and these are things that may be changed in future versions.



On Tue, May 17, 2011 at 8:36 AM, Kohsuke Kawaguchi <[hidden email]> wrote:

> I'm trying to write a DSL descriptor that needs to access the
> GroovyCompilationUnit that represents the source file in which the
> completion is provided.
> (my completion is context sensitive to the relative path of the script
> from within the source root --- I want to figure out the equivalent of
> the package name, even though the Groovy script files need not have
> the package declaration.)
>
> Can anyone tell me how I can obtain a reference to it from within the
> contribution closure?
>
> On a related note, I'm looking at
> DSLContributionGroup.getContributions(), and I noticed that it doesn't
> expose GroovyDSLDContext itself to the contribution closure. Is there
> a reason it doens't do this? GroovyDSLDContext object exposes a lot of
> useful information that I think would benefit the contribution
> closures.
>
> --
> Kohsuke Kawaguchi                          http://kohsuke.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
|  
Report Content as Inappropriate

Re: Accessing GroovyCompilationUnit from DSLD

Andrew Eisenberg
the packageFolder pointcut should be available in the next hour or so
(assuming the dev build passes).  You need to install from the dev
update site to install the version.

pacakgeFolder("p")  will match when the current file is in the src/p
folder (if 'src' is the source folder), or src/main/groovy/p (if
src/main/groovy is the source folder), etc.

One more thing about GroovyCompilationUnit.  If there are any fields
or information that you need from that object, let me know and I will
figure out a way to expose it.

On Tue, May 17, 2011 at 10:08 AM, Andrew Eisenberg <[hidden email]> wrote:

> Hi,
>
> This is a pointcut that I have not implemented yet, mostly because I
> just haven't seen an example that requires it until now.  There are
> many of these kinds of pointcuts and I am waiting for requests from
> users before implementing.  So, let me put this together and I will
> let you know when it is in a dev build.
>
> Just to be sure that I understand...you require matching on the
> package folder of the current file.  You can't match on the package
> name since the package statement may not be around.  I'll make a
> pointcut called 'packageFolder' or something like that.
>
> To answer your second question...I am reluctant to expose an
> Eclipse-specific API inside of contribution blocks since I do not want
> the DSLDs to be tied to Eclipse.  That being said, there are some
> places where the abstraction is a bit leaky (eg- the nature pointcut)
> and these are things that may be changed in future versions.
>
>
>
> On Tue, May 17, 2011 at 8:36 AM, Kohsuke Kawaguchi <[hidden email]> wrote:
>> I'm trying to write a DSL descriptor that needs to access the
>> GroovyCompilationUnit that represents the source file in which the
>> completion is provided.
>> (my completion is context sensitive to the relative path of the script
>> from within the source root --- I want to figure out the equivalent of
>> the package name, even though the Groovy script files need not have
>> the package declaration.)
>>
>> Can anyone tell me how I can obtain a reference to it from within the
>> contribution closure?
>>
>> On a related note, I'm looking at
>> DSLContributionGroup.getContributions(), and I noticed that it doesn't
>> expose GroovyDSLDContext itself to the contribution closure. Is there
>> a reason it doens't do this? GroovyDSLDContext object exposes a lot of
>> useful information that I think would benefit the contribution
>> closures.
>>
>> --
>> Kohsuke Kawaguchi                          http://kohsuke.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
|  
Report Content as Inappropriate

Re: Accessing GroovyCompilationUnit from DSLD

Andrew Eisenberg
Hi,

The dev update site is here:
http://dist.codehaus.org/groovy/distributions/greclipse/snapshot/e3.6/

I forgot to attache it when I wrote the earlier email.

Yes, the packageFolder pointcut will return the folder name.  You'll
need to use it something like this:

bind( folders : packageFolder("com.foo.Bar"))

And in the contribution block, you can reference the 'folders'
variable.  It will always be a Collection.  I haven't implemented
matching on a regex, so I'm not sure how useful binding the pointcut
result to 'folders'.  It's something that I'll probably have todo
eventually, however.

As for accessing internal Eclipse APIs, perhaps I could expose it, but
the script would have to explicitly opt-in to the extra API.  If it
becomes necessary, its something that I will do.

--a

On Tue, May 17, 2011 at 10:12 PM, Kohsuke Kawaguchi
<[hidden email]> wrote:

>
> Thanks. Sorry for a stupid question, but where is the dev update site?
>
> And yes, that packageFolder() pointcut is perfect. I assume that the
> return value is the actual package folder of the current file where
> the completion is provided?
>
> The reason I was going to access GroovyCompilationUnit is so that I
> can compute the package folder by myself. Since now it's provided by the new
> point cut, it does eliminate my immediate need for it, but I still think
> it's good for DSLD to provide access to Eclipse internals. It just opens up
> a lot of possibilities without bugging you each time :-)
>
> I think you can strive for IDE neutrality without prohibiting the user
> from accessing IDE specific pieces. You'd make API such that when I'm
> accessing Eclipse specific stuff, it makes me aware of that. There's a lot
> of JCP API that does this kind of stuff.
>
>
> On 05/17/2011 04:55 AM, Andrew Eisenberg wrote:
>>
>> the packageFolder pointcut should be available in the next hour or so
>> (assuming the dev build passes).  You need to install from the dev
>> update site to install the version.
>>
>> pacakgeFolder("p")  will match when the current file is in the src/p
>> folder (if 'src' is the source folder), or src/main/groovy/p (if
>> src/main/groovy is the source folder), etc.
>>
>> One more thing about GroovyCompilationUnit.  If there are any fields
>> or information that you need from that object, let me know and I will
>> figure out a way to expose it.
>>
>> On Tue, May 17, 2011 at 10:08 AM, Andrew Eisenberg<[hidden email]>
>>  wrote:
>>>
>>>  Hi,
>>>
>>>  This is a pointcut that I have not implemented yet, mostly because I
>>>  just haven't seen an example that requires it until now.  There are
>>>  many of these kinds of pointcuts and I am waiting for requests from
>>>  users before implementing.  So, let me put this together and I will
>>>  let you know when it is in a dev build.
>>>
>>>  Just to be sure that I understand...you require matching on the
>>>  package folder of the current file.  You can't match on the package
>>>  name since the package statement may not be around.  I'll make a
>>>  pointcut called 'packageFolder' or something like that.
>>>
>>>  To answer your second question...I am reluctant to expose an
>>>  Eclipse-specific API inside of contribution blocks since I do not want
>>>  the DSLDs to be tied to Eclipse.  That being said, there are some
>>>  places where the abstraction is a bit leaky (eg- the nature pointcut)
>>>  and these are things that may be changed in future versions.
>>>
>>>
>>>
>>>  On Tue, May 17, 2011 at 8:36 AM, Kohsuke Kawaguchi<[hidden email]>
>>>  wrote:
>>>>
>>>>  I'm trying to write a DSL descriptor that needs to access the
>>>>  GroovyCompilationUnit that represents the source file in which the
>>>>  completion is provided.
>>>>  (my completion is context sensitive to the relative path of the script
>>>>  from within the source root --- I want to figure out the equivalent of
>>>>  the package name, even though the Groovy script files need not have
>>>>  the package declaration.)
>>>>
>>>>  Can anyone tell me how I can obtain a reference to it from within the
>>>>  contribution closure?
>>>>
>>>>  On a related note, I'm looking at
>>>>  DSLContributionGroup.getContributions(), and I noticed that it doesn't
>>>>  expose GroovyDSLDContext itself to the contribution closure. Is there
>>>>  a reason it doens't do this? GroovyDSLDContext object exposes a lot of
>>>>  useful information that I think would benefit the contribution
>>>>  closures.
>>>>
>>>>  --
>>>>  Kohsuke Kawaguchi                          http://kohsuke.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
>>
>>
>>
>
>
> --
> Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
>

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

    http://xircles.codehaus.org/manage_email


Loading...