Using methods added via local AST transform in java classes

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

Using methods added via local AST transform in java classes

Bertrand Barroux
Hi, 

We have a fairly large java application which use some groovy POGO. I have written a simple local AST transformation  which adds a method to this POGO. It works fine, but the method doesn't show in code assist, and if it is used in a java class, the java editor show a "missing method" error. If I launch the application it works fine nevertheless. 

Is there a way to have those methods appear in code assis and to prevent the apparent compilation problem in the java editor?

thanks
Bertrand 
Reply | Threaded
Open this post in threaded view
|

Re: Using methods added via local AST transform in java classes

Andrew Eisenberg
There is a long discussion about this issue here:
http://jira.codehaus.org/browse/GRECLIPSE-331

There are really two things that you are talking about here: AST
transforms not being visible in Groovy files, and AST transforms not
being visible in Java files.

First, AST transforms are not usually run when reconciling (ie- a
mini-compile that is used for IDE operations).  The reason for this is
that many AST transforms are not well-behaved, and can break IDE
operations.  That is why you are not seeing the results of the
transform for content assist in Groovy files.

There is a fairly simple workaround for this.  You can create a DSL
Descriptor file (DSLD) that gives extra type inferencing hints for
your Groovy files.  See here:
http://blog.springsource.com/2011/05/08/better-dsl-support-in-groovy-eclipse/

You will want to place a file like this somewhere in your project
(named '*.dsld'):

currentType(annotatedBy("com.foo.MyAnnotation")).accept {
   method name:"foo", type:"java.lang.String"
   property name:"bar", type:"java.util.List<java.lang.String>"
}

The second part is a bit trickier to solve.  In theory, yes.  It is
possible to see your AST transforms from Java (both in Eclipse and on
the command line), but in practice, it is a bit tricky and the rules
are slightly different in each case.

The second problem is slightly different.  DSLDs will not work for
Java code, and reconciling does not execute the transforms, something
different has to happen.  What you are seeing are errors in your
editor, but your code is apparently compiling fine.

To compile joint java-groovy projects, both Groovy-Eclipse and Groovyc
create Java stubs of your groovy code (Groovyc does this explicitly as
files in a tmp directory, and Groovy-Ecliipse does this implicitly in
memory).  If your transform runs early enough, then the transformation
will appear in your stubs and the Java code will resolve and be happy.
 (During a *compile*, transforms are run, but not during a
*reconcile*).  So, it is likely that your transform is working in Java
by "luck" since it happens to run early enough to be picked up by the
stub generator.

There are some ways to get this working in Eclipse, but I'd like to
make sure that I completely understand what you are trying to do
before I suggest anything.



On Wed, Aug 17, 2011 at 3:57 AM, Bertrand Barroux <[hidden email]> wrote:

> Hi,
> We have a fairly large java application which use some groovy POGO. I have
> written a simple local AST transformation  which adds a method to this POGO.
> It works fine, but the method doesn't show in code assist, and if it is used
> in a java class, the java editor show a "missing method" error. If I launch
> the application it works fine nevertheless.
> Is there a way to have those methods appear in code assis and to prevent the
> apparent compilation problem in the java editor?
> thanks
> Bertrand
>

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Using methods added via local AST transform in java classes

Bertrand Barroux
Thank you for your extensive answer.

In fact, I'm trying to perform the same type of black magic which makes getters and setters available on POGO to java classes (and seen as available by the java editor).

I tried to put all my AST transformed POGOs in a project_1, this project being in the classpath of my other java projects. 

As I said the transformation seems to work fine, despite the errors being shown in java editors. 

I took a look at my transformed POGOs in the Groovy Ast Viewer view, but I do not see my AST added methods. I'm not sure how this viewer is supposed to be used. 

Finally, I managed to have the stuff working as I wanted by :

- Removing the dependency to Pogos project_1 from java projects buildpath
- Adding an archivebuilder to project_1 (I'm using Jboss Ide Archive Tools)
- Adding the jar produced by the archive builder to java projects classpath.

Using this method all AST added method to my pogos show up properly in the java editor. the issue with this solution, besides its slight awkwardness, is that I lose all possibility of refactoring, call hierarchies walking, etc... Those being quite limited anyway between groovy and java, I don't know if it is a no-go, but I'm not sure if I really want to go that route.

Any better solution would in any case be greatly appreciated.

Regards,

Bertrand 



On Wed, Aug 17, 2011 at 18:03, Andrew Eisenberg <[hidden email]> wrote:
There is a long discussion about this issue here:
http://jira.codehaus.org/browse/GRECLIPSE-331

There are really two things that you are talking about here: AST
transforms not being visible in Groovy files, and AST transforms not
being visible in Java files.

First, AST transforms are not usually run when reconciling (ie- a
mini-compile that is used for IDE operations).  The reason for this is
that many AST transforms are not well-behaved, and can break IDE
operations.  That is why you are not seeing the results of the
transform for content assist in Groovy files.

There is a fairly simple workaround for this.  You can create a DSL
Descriptor file (DSLD) that gives extra type inferencing hints for
your Groovy files.  See here:
http://blog.springsource.com/2011/05/08/better-dsl-support-in-groovy-eclipse/

You will want to place a file like this somewhere in your project
(named '*.dsld'):

currentType(annotatedBy("com.foo.MyAnnotation")).accept {
  method name:"foo", type:"java.lang.String"
  property name:"bar", type:"java.util.List<java.lang.String>"
}

The second part is a bit trickier to solve.  In theory, yes.  It is
possible to see your AST transforms from Java (both in Eclipse and on
the command line), but in practice, it is a bit tricky and the rules
are slightly different in each case.

The second problem is slightly different.  DSLDs will not work for
Java code, and reconciling does not execute the transforms, something
different has to happen.  What you are seeing are errors in your
editor, but your code is apparently compiling fine.

To compile joint java-groovy projects, both Groovy-Eclipse and Groovyc
create Java stubs of your groovy code (Groovyc does this explicitly as
files in a tmp directory, and Groovy-Ecliipse does this implicitly in
memory).  If your transform runs early enough, then the transformation
will appear in your stubs and the Java code will resolve and be happy.
 (During a *compile*, transforms are run, but not during a
*reconcile*).  So, it is likely that your transform is working in Java
by "luck" since it happens to run early enough to be picked up by the
stub generator.

There are some ways to get this working in Eclipse, but I'd like to
make sure that I completely understand what you are trying to do
before I suggest anything.



On Wed, Aug 17, 2011 at 3:57 AM, Bertrand Barroux <[hidden email]> wrote:
> Hi,
> We have a fairly large java application which use some groovy POGO. I have
> written a simple local AST transformation  which adds a method to this POGO.
> It works fine, but the method doesn't show in code assist, and if it is used
> in a java class, the java editor show a "missing method" error. If I launch
> the application it works fine nevertheless.
> Is there a way to have those methods appear in code assis and to prevent the
> apparent compilation problem in the java editor?
> thanks
> Bertrand
>

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

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Using methods added via local AST transform in java classes

Andrew Eisenberg
The solution you chose is close to the solution that I would have
suggested and as far as I know, there is no way currently to bypass
the problems you describe.

The solution is to selectively enable certain AST transforms to run in
the editor.  This is something that we have discussed before.  But, we
don't have a jira issue open for this.

Essentially, there would need to be a way for AST transform creators
to take responsibility for the transforms that they write.  I imagine
that we could create some kind of meta-annotation that essentially
states "This transform is safe to run in the Groovy editor".
Transforms that only use local state and are purely additive would
tend to fall in this category.

I'll raise a jira for this.

On Thu, Aug 18, 2011 at 1:56 AM, Bertrand Barroux <[hidden email]> wrote:

> Thank you for your extensive answer.
> In fact, I'm trying to perform the same type of black magic which makes
> getters and setters available on POGO to java classes (and seen as available
> by the java editor).
> I tried to put all my AST transformed POGOs in a project_1, this project
> being in the classpath of my other java projects.
> As I said the transformation seems to work fine, despite the errors being
> shown in java editors.
> I took a look at my transformed POGOs in the Groovy Ast Viewer view, but I
> do not see my AST added methods. I'm not sure how this viewer is supposed to
> be used.
> Finally, I managed to have the stuff working as I wanted by :
> - Removing the dependency to Pogos project_1 from java projects buildpath
> - Adding an archivebuilder to project_1 (I'm using Jboss Ide Archive Tools)
> - Adding the jar produced by the archive builder to java projects classpath.
> Using this method all AST added method to my pogos show up properly in the
> java editor. the issue with this solution, besides its slight awkwardness,
> is that I lose all possibility of refactoring, call hierarchies walking,
> etc... Those being quite limited anyway between groovy and java, I don't
> know if it is a no-go, but I'm not sure if I really want to go that route.
> Any better solution would in any case be greatly appreciated.
> Regards,
> Bertrand
>
>
> On Wed, Aug 17, 2011 at 18:03, Andrew Eisenberg <[hidden email]> wrote:
>>
>> There is a long discussion about this issue here:
>> http://jira.codehaus.org/browse/GRECLIPSE-331
>>
>> There are really two things that you are talking about here: AST
>> transforms not being visible in Groovy files, and AST transforms not
>> being visible in Java files.
>>
>> First, AST transforms are not usually run when reconciling (ie- a
>> mini-compile that is used for IDE operations).  The reason for this is
>> that many AST transforms are not well-behaved, and can break IDE
>> operations.  That is why you are not seeing the results of the
>> transform for content assist in Groovy files.
>>
>> There is a fairly simple workaround for this.  You can create a DSL
>> Descriptor file (DSLD) that gives extra type inferencing hints for
>> your Groovy files.  See here:
>>
>> http://blog.springsource.com/2011/05/08/better-dsl-support-in-groovy-eclipse/
>>
>> You will want to place a file like this somewhere in your project
>> (named '*.dsld'):
>>
>> currentType(annotatedBy("com.foo.MyAnnotation")).accept {
>>   method name:"foo", type:"java.lang.String"
>>   property name:"bar", type:"java.util.List<java.lang.String>"
>> }
>>
>> The second part is a bit trickier to solve.  In theory, yes.  It is
>> possible to see your AST transforms from Java (both in Eclipse and on
>> the command line), but in practice, it is a bit tricky and the rules
>> are slightly different in each case.
>>
>> The second problem is slightly different.  DSLDs will not work for
>> Java code, and reconciling does not execute the transforms, something
>> different has to happen.  What you are seeing are errors in your
>> editor, but your code is apparently compiling fine.
>>
>> To compile joint java-groovy projects, both Groovy-Eclipse and Groovyc
>> create Java stubs of your groovy code (Groovyc does this explicitly as
>> files in a tmp directory, and Groovy-Ecliipse does this implicitly in
>> memory).  If your transform runs early enough, then the transformation
>> will appear in your stubs and the Java code will resolve and be happy.
>>  (During a *compile*, transforms are run, but not during a
>> *reconcile*).  So, it is likely that your transform is working in Java
>> by "luck" since it happens to run early enough to be picked up by the
>> stub generator.
>>
>> There are some ways to get this working in Eclipse, but I'd like to
>> make sure that I completely understand what you are trying to do
>> before I suggest anything.
>>
>>
>>
>> On Wed, Aug 17, 2011 at 3:57 AM, Bertrand Barroux <[hidden email]> wrote:
>> > Hi,
>> > We have a fairly large java application which use some groovy POGO. I
>> > have
>> > written a simple local AST transformation  which adds a method to this
>> > POGO.
>> > It works fine, but the method doesn't show in code assist, and if it is
>> > used
>> > in a java class, the java editor show a "missing method" error. If I
>> > launch
>> > the application it works fine nevertheless.
>> > Is there a way to have those methods appear in code assis and to prevent
>> > the
>> > apparent compilation problem in the java editor?
>> > thanks
>> > Bertrand
>> >
>>
>> ---------------------------------------------------------------------
>> 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: Using methods added via local AST transform in java classes

Andrew Eisenberg
Let's move the discussion to here:
http://jira.codehaus.org/browse/GRECLIPSE-1179

On Thu, Aug 18, 2011 at 8:45 AM, Andrew Eisenberg <[hidden email]> wrote:

> The solution you chose is close to the solution that I would have
> suggested and as far as I know, there is no way currently to bypass
> the problems you describe.
>
> The solution is to selectively enable certain AST transforms to run in
> the editor.  This is something that we have discussed before.  But, we
> don't have a jira issue open for this.
>
> Essentially, there would need to be a way for AST transform creators
> to take responsibility for the transforms that they write.  I imagine
> that we could create some kind of meta-annotation that essentially
> states "This transform is safe to run in the Groovy editor".
> Transforms that only use local state and are purely additive would
> tend to fall in this category.
>
> I'll raise a jira for this.
>
> On Thu, Aug 18, 2011 at 1:56 AM, Bertrand Barroux <[hidden email]> wrote:
>> Thank you for your extensive answer.
>> In fact, I'm trying to perform the same type of black magic which makes
>> getters and setters available on POGO to java classes (and seen as available
>> by the java editor).
>> I tried to put all my AST transformed POGOs in a project_1, this project
>> being in the classpath of my other java projects.
>> As I said the transformation seems to work fine, despite the errors being
>> shown in java editors.
>> I took a look at my transformed POGOs in the Groovy Ast Viewer view, but I
>> do not see my AST added methods. I'm not sure how this viewer is supposed to
>> be used.
>> Finally, I managed to have the stuff working as I wanted by :
>> - Removing the dependency to Pogos project_1 from java projects buildpath
>> - Adding an archivebuilder to project_1 (I'm using Jboss Ide Archive Tools)
>> - Adding the jar produced by the archive builder to java projects classpath.
>> Using this method all AST added method to my pogos show up properly in the
>> java editor. the issue with this solution, besides its slight awkwardness,
>> is that I lose all possibility of refactoring, call hierarchies walking,
>> etc... Those being quite limited anyway between groovy and java, I don't
>> know if it is a no-go, but I'm not sure if I really want to go that route.
>> Any better solution would in any case be greatly appreciated.
>> Regards,
>> Bertrand
>>
>>
>> On Wed, Aug 17, 2011 at 18:03, Andrew Eisenberg <[hidden email]> wrote:
>>>
>>> There is a long discussion about this issue here:
>>> http://jira.codehaus.org/browse/GRECLIPSE-331
>>>
>>> There are really two things that you are talking about here: AST
>>> transforms not being visible in Groovy files, and AST transforms not
>>> being visible in Java files.
>>>
>>> First, AST transforms are not usually run when reconciling (ie- a
>>> mini-compile that is used for IDE operations).  The reason for this is
>>> that many AST transforms are not well-behaved, and can break IDE
>>> operations.  That is why you are not seeing the results of the
>>> transform for content assist in Groovy files.
>>>
>>> There is a fairly simple workaround for this.  You can create a DSL
>>> Descriptor file (DSLD) that gives extra type inferencing hints for
>>> your Groovy files.  See here:
>>>
>>> http://blog.springsource.com/2011/05/08/better-dsl-support-in-groovy-eclipse/
>>>
>>> You will want to place a file like this somewhere in your project
>>> (named '*.dsld'):
>>>
>>> currentType(annotatedBy("com.foo.MyAnnotation")).accept {
>>>   method name:"foo", type:"java.lang.String"
>>>   property name:"bar", type:"java.util.List<java.lang.String>"
>>> }
>>>
>>> The second part is a bit trickier to solve.  In theory, yes.  It is
>>> possible to see your AST transforms from Java (both in Eclipse and on
>>> the command line), but in practice, it is a bit tricky and the rules
>>> are slightly different in each case.
>>>
>>> The second problem is slightly different.  DSLDs will not work for
>>> Java code, and reconciling does not execute the transforms, something
>>> different has to happen.  What you are seeing are errors in your
>>> editor, but your code is apparently compiling fine.
>>>
>>> To compile joint java-groovy projects, both Groovy-Eclipse and Groovyc
>>> create Java stubs of your groovy code (Groovyc does this explicitly as
>>> files in a tmp directory, and Groovy-Ecliipse does this implicitly in
>>> memory).  If your transform runs early enough, then the transformation
>>> will appear in your stubs and the Java code will resolve and be happy.
>>>  (During a *compile*, transforms are run, but not during a
>>> *reconcile*).  So, it is likely that your transform is working in Java
>>> by "luck" since it happens to run early enough to be picked up by the
>>> stub generator.
>>>
>>> There are some ways to get this working in Eclipse, but I'd like to
>>> make sure that I completely understand what you are trying to do
>>> before I suggest anything.
>>>
>>>
>>>
>>> On Wed, Aug 17, 2011 at 3:57 AM, Bertrand Barroux <[hidden email]> wrote:
>>> > Hi,
>>> > We have a fairly large java application which use some groovy POGO. I
>>> > have
>>> > written a simple local AST transformation  which adds a method to this
>>> > POGO.
>>> > It works fine, but the method doesn't show in code assist, and if it is
>>> > used
>>> > in a java class, the java editor show a "missing method" error. If I
>>> > launch
>>> > the application it works fine nevertheless.
>>> > Is there a way to have those methods appear in code assis and to prevent
>>> > the
>>> > apparent compilation problem in the java editor?
>>> > thanks
>>> > Bertrand
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> 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: Using methods added via local AST transform in java classes

Bertrand Barroux
For future reference I have marginally improved the workaround solution by removing the unnecessary archive building step, and adding a the /bin "Class Folder" of the POGO project to the other java projects classpath. It is much better, because the first solution I mentionned happened to have a HUGE refresh problem. If you configure properly the "attached source" property of the imported class folder in the classpath, I end up having something which allow semi-seamless navigation between classes and Pogos.

Is there something useful I could add to jira to help future work?


Bertrand 


On Thu, Aug 18, 2011 at 17:52, Andrew Eisenberg <[hidden email]> wrote:
Let's move the discussion to here:
http://jira.codehaus.org/browse/GRECLIPSE-1179

On Thu, Aug 18, 2011 at 8:45 AM, Andrew Eisenberg <[hidden email]> wrote:
> The solution you chose is close to the solution that I would have
> suggested and as far as I know, there is no way currently to bypass
> the problems you describe.
>
> The solution is to selectively enable certain AST transforms to run in
> the editor.  This is something that we have discussed before.  But, we
> don't have a jira issue open for this.
>
> Essentially, there would need to be a way for AST transform creators
> to take responsibility for the transforms that they write.  I imagine
> that we could create some kind of meta-annotation that essentially
> states "This transform is safe to run in the Groovy editor".
> Transforms that only use local state and are purely additive would
> tend to fall in this category.
>
> I'll raise a jira for this.
>
> On Thu, Aug 18, 2011 at 1:56 AM, Bertrand Barroux <[hidden email]> wrote:
>> Thank you for your extensive answer.
>> In fact, I'm trying to perform the same type of black magic which makes
>> getters and setters available on POGO to java classes (and seen as available
>> by the java editor).
>> I tried to put all my AST transformed POGOs in a project_1, this project
>> being in the classpath of my other java projects.
>> As I said the transformation seems to work fine, despite the errors being
>> shown in java editors.
>> I took a look at my transformed POGOs in the Groovy Ast Viewer view, but I
>> do not see my AST added methods. I'm not sure how this viewer is supposed to
>> be used.
>> Finally, I managed to have the stuff working as I wanted by :
>> - Removing the dependency to Pogos project_1 from java projects buildpath
>> - Adding an archivebuilder to project_1 (I'm using Jboss Ide Archive Tools)
>> - Adding the jar produced by the archive builder to java projects classpath.
>> Using this method all AST added method to my pogos show up properly in the
>> java editor. the issue with this solution, besides its slight awkwardness,
>> is that I lose all possibility of refactoring, call hierarchies walking,
>> etc... Those being quite limited anyway between groovy and java, I don't
>> know if it is a no-go, but I'm not sure if I really want to go that route.
>> Any better solution would in any case be greatly appreciated.
>> Regards,
>> Bertrand
>>
>>
>> On Wed, Aug 17, 2011 at 18:03, Andrew Eisenberg <[hidden email]> wrote:
>>>
>>> There is a long discussion about this issue here:
>>> http://jira.codehaus.org/browse/GRECLIPSE-331
>>>
>>> There are really two things that you are talking about here: AST
>>> transforms not being visible in Groovy files, and AST transforms not
>>> being visible in Java files.
>>>
>>> First, AST transforms are not usually run when reconciling (ie- a
>>> mini-compile that is used for IDE operations).  The reason for this is
>>> that many AST transforms are not well-behaved, and can break IDE
>>> operations.  That is why you are not seeing the results of the
>>> transform for content assist in Groovy files.
>>>
>>> There is a fairly simple workaround for this.  You can create a DSL
>>> Descriptor file (DSLD) that gives extra type inferencing hints for
>>> your Groovy files.  See here:
>>>
>>> http://blog.springsource.com/2011/05/08/better-dsl-support-in-groovy-eclipse/
>>>
>>> You will want to place a file like this somewhere in your project
>>> (named '*.dsld'):
>>>
>>> currentType(annotatedBy("com.foo.MyAnnotation")).accept {
>>>   method name:"foo", type:"java.lang.String"
>>>   property name:"bar", type:"java.util.List<java.lang.String>"
>>> }
>>>
>>> The second part is a bit trickier to solve.  In theory, yes.  It is
>>> possible to see your AST transforms from Java (both in Eclipse and on
>>> the command line), but in practice, it is a bit tricky and the rules
>>> are slightly different in each case.
>>>
>>> The second problem is slightly different.  DSLDs will not work for
>>> Java code, and reconciling does not execute the transforms, something
>>> different has to happen.  What you are seeing are errors in your
>>> editor, but your code is apparently compiling fine.
>>>
>>> To compile joint java-groovy projects, both Groovy-Eclipse and Groovyc
>>> create Java stubs of your groovy code (Groovyc does this explicitly as
>>> files in a tmp directory, and Groovy-Ecliipse does this implicitly in
>>> memory).  If your transform runs early enough, then the transformation
>>> will appear in your stubs and the Java code will resolve and be happy.
>>>  (During a *compile*, transforms are run, but not during a
>>> *reconcile*).  So, it is likely that your transform is working in Java
>>> by "luck" since it happens to run early enough to be picked up by the
>>> stub generator.
>>>
>>> There are some ways to get this working in Eclipse, but I'd like to
>>> make sure that I completely understand what you are trying to do
>>> before I suggest anything.
>>>
>>>
>>>
>>> On Wed, Aug 17, 2011 at 3:57 AM, Bertrand Barroux <[hidden email]> wrote:
>>> > Hi,
>>> > We have a fairly large java application which use some groovy POGO. I
>>> > have
>>> > written a simple local AST transformation  which adds a method to this
>>> > POGO.
>>> > It works fine, but the method doesn't show in code assist, and if it is
>>> > used
>>> > in a java class, the java editor show a "missing method" error. If I
>>> > launch
>>> > the application it works fine nevertheless.
>>> > Is there a way to have those methods appear in code assis and to prevent
>>> > the
>>> > apparent compilation problem in the java editor?
>>> > thanks
>>> > Bertrand
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> 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: Using methods added via local AST transform in java classes

Andrew Eisenberg
Hi,

Apologies for taking so long to respond.  If you want to help out,
then you can describe your current solution on the jira.  Thanks.

--a

On Thu, Aug 18, 2011 at 10:03 AM, Bertrand Barroux <[hidden email]> wrote:

> For future reference I have marginally improved the workaround solution by
> removing the unnecessary archive building step, and adding a the /bin "Class
> Folder" of the POGO project to the other java projects classpath. It is much
> better, because the first solution I mentionned happened to have a HUGE
> refresh problem. If you configure properly the "attached source" property of
> the imported class folder in the classpath, I end up having something which
> allow semi-seamless navigation between classes and Pogos.
> Is there something useful I could add to jira to help future work?
>
> Bertrand
>
>
> On Thu, Aug 18, 2011 at 17:52, Andrew Eisenberg <[hidden email]> wrote:
>>
>> Let's move the discussion to here:
>> http://jira.codehaus.org/browse/GRECLIPSE-1179
>>
>> On Thu, Aug 18, 2011 at 8:45 AM, Andrew Eisenberg <[hidden email]>
>> wrote:
>> > The solution you chose is close to the solution that I would have
>> > suggested and as far as I know, there is no way currently to bypass
>> > the problems you describe.
>> >
>> > The solution is to selectively enable certain AST transforms to run in
>> > the editor.  This is something that we have discussed before.  But, we
>> > don't have a jira issue open for this.
>> >
>> > Essentially, there would need to be a way for AST transform creators
>> > to take responsibility for the transforms that they write.  I imagine
>> > that we could create some kind of meta-annotation that essentially
>> > states "This transform is safe to run in the Groovy editor".
>> > Transforms that only use local state and are purely additive would
>> > tend to fall in this category.
>> >
>> > I'll raise a jira for this.
>> >
>> > On Thu, Aug 18, 2011 at 1:56 AM, Bertrand Barroux <[hidden email]>
>> > wrote:
>> >> Thank you for your extensive answer.
>> >> In fact, I'm trying to perform the same type of black magic which makes
>> >> getters and setters available on POGO to java classes (and seen as
>> >> available
>> >> by the java editor).
>> >> I tried to put all my AST transformed POGOs in a project_1, this
>> >> project
>> >> being in the classpath of my other java projects.
>> >> As I said the transformation seems to work fine, despite the errors
>> >> being
>> >> shown in java editors.
>> >> I took a look at my transformed POGOs in the Groovy Ast Viewer view,
>> >> but I
>> >> do not see my AST added methods. I'm not sure how this viewer is
>> >> supposed to
>> >> be used.
>> >> Finally, I managed to have the stuff working as I wanted by :
>> >> - Removing the dependency to Pogos project_1 from java projects
>> >> buildpath
>> >> - Adding an archivebuilder to project_1 (I'm using Jboss Ide Archive
>> >> Tools)
>> >> - Adding the jar produced by the archive builder to java projects
>> >> classpath.
>> >> Using this method all AST added method to my pogos show up properly in
>> >> the
>> >> java editor. the issue with this solution, besides its slight
>> >> awkwardness,
>> >> is that I lose all possibility of refactoring, call hierarchies
>> >> walking,
>> >> etc... Those being quite limited anyway between groovy and java, I
>> >> don't
>> >> know if it is a no-go, but I'm not sure if I really want to go that
>> >> route.
>> >> Any better solution would in any case be greatly appreciated.
>> >> Regards,
>> >> Bertrand
>> >>
>> >>
>> >> On Wed, Aug 17, 2011 at 18:03, Andrew Eisenberg <[hidden email]>
>> >> wrote:
>> >>>
>> >>> There is a long discussion about this issue here:
>> >>> http://jira.codehaus.org/browse/GRECLIPSE-331
>> >>>
>> >>> There are really two things that you are talking about here: AST
>> >>> transforms not being visible in Groovy files, and AST transforms not
>> >>> being visible in Java files.
>> >>>
>> >>> First, AST transforms are not usually run when reconciling (ie- a
>> >>> mini-compile that is used for IDE operations).  The reason for this is
>> >>> that many AST transforms are not well-behaved, and can break IDE
>> >>> operations.  That is why you are not seeing the results of the
>> >>> transform for content assist in Groovy files.
>> >>>
>> >>> There is a fairly simple workaround for this.  You can create a DSL
>> >>> Descriptor file (DSLD) that gives extra type inferencing hints for
>> >>> your Groovy files.  See here:
>> >>>
>> >>>
>> >>> http://blog.springsource.com/2011/05/08/better-dsl-support-in-groovy-eclipse/
>> >>>
>> >>> You will want to place a file like this somewhere in your project
>> >>> (named '*.dsld'):
>> >>>
>> >>> currentType(annotatedBy("com.foo.MyAnnotation")).accept {
>> >>>   method name:"foo", type:"java.lang.String"
>> >>>   property name:"bar", type:"java.util.List<java.lang.String>"
>> >>> }
>> >>>
>> >>> The second part is a bit trickier to solve.  In theory, yes.  It is
>> >>> possible to see your AST transforms from Java (both in Eclipse and on
>> >>> the command line), but in practice, it is a bit tricky and the rules
>> >>> are slightly different in each case.
>> >>>
>> >>> The second problem is slightly different.  DSLDs will not work for
>> >>> Java code, and reconciling does not execute the transforms, something
>> >>> different has to happen.  What you are seeing are errors in your
>> >>> editor, but your code is apparently compiling fine.
>> >>>
>> >>> To compile joint java-groovy projects, both Groovy-Eclipse and Groovyc
>> >>> create Java stubs of your groovy code (Groovyc does this explicitly as
>> >>> files in a tmp directory, and Groovy-Ecliipse does this implicitly in
>> >>> memory).  If your transform runs early enough, then the transformation
>> >>> will appear in your stubs and the Java code will resolve and be happy.
>> >>>  (During a *compile*, transforms are run, but not during a
>> >>> *reconcile*).  So, it is likely that your transform is working in Java
>> >>> by "luck" since it happens to run early enough to be picked up by the
>> >>> stub generator.
>> >>>
>> >>> There are some ways to get this working in Eclipse, but I'd like to
>> >>> make sure that I completely understand what you are trying to do
>> >>> before I suggest anything.
>> >>>
>> >>>
>> >>>
>> >>> On Wed, Aug 17, 2011 at 3:57 AM, Bertrand Barroux <[hidden email]>
>> >>> wrote:
>> >>> > Hi,
>> >>> > We have a fairly large java application which use some groovy POGO.
>> >>> > I
>> >>> > have
>> >>> > written a simple local AST transformation  which adds a method to
>> >>> > this
>> >>> > POGO.
>> >>> > It works fine, but the method doesn't show in code assist, and if it
>> >>> > is
>> >>> > used
>> >>> > in a java class, the java editor show a "missing method" error. If I
>> >>> > launch
>> >>> > the application it works fine nevertheless.
>> >>> > Is there a way to have those methods appear in code assis and to
>> >>> > prevent
>> >>> > the
>> >>> > apparent compilation problem in the java editor?
>> >>> > thanks
>> >>> > Bertrand
>> >>> >
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> 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