Resolving ClassNode during incremental compilation

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

Resolving ClassNode during incremental compilation

Krzysztof Białek
Hello,

I am implementing AST transformation which is adding a subset of properties of class A to class B.
Technically class B is annotated with @CopyPropertiesFrom(A)
The transformation works well in complete project compilation where AST of class A is present when transforming class B
Unfortunately it does now work with greclipse incremental compiler (GGTS in my case).
Once class B is touched the incremental compiler starts and the transformation is triggered for class B.
The ClassNode(A) is not initialized and I cannot iterate its properties.
I tried to use compilationUnit.resolveVisitor.visitClass but it did not manage to resolve the class

// get ResolveVisitor
ClassNode targetClass = // get ClassNode from @CopyPropertiesFrom.value member
Field rvField = CompilationUnit.class.getDeclaredField('resolveVisitor')
rvField.setAccessible(true)
ResolveVisitor rv = (ResolveVisitor) rvField.get(this.compilationUnit)
rv.visitClass(targetClass)

this throws:
org.codehaus.jdt.groovy.internal.compiler.ast.GroovyEclipseBug: commencingResolution failed: no declaration found for class A -> A
        at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.commencingResolution(JDTResolver.java:498)

I am aware of the limitations imposed by the incremental compiler. However in my opinion it should be possible to resolve classes on demand.

Can you please tell me if there is a working solution for my problem?

Cheers,
Krzysztof

---------------------------------------------------------------------
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: Resolving ClassNode during incremental compilation

Andrew Eisenberg
This is an odd case since you are trying to resolve a class that is
not otherwise in the compilation unit.  Try using the
org.codehaus.groovy.control.ResolveVisitor.resolve(ClassNode) method.
It is protected and so you will need to use reflection to get at it.

On Mon, Jun 24, 2013 at 1:15 PM, Krzysztof Białek
<[hidden email]> wrote:

> Hello,
>
> I am implementing AST transformation which is adding a subset of properties of class A to class B.
> Technically class B is annotated with @CopyPropertiesFrom(A)
> The transformation works well in complete project compilation where AST of class A is present when transforming class B
> Unfortunately it does now work with greclipse incremental compiler (GGTS in my case).
> Once class B is touched the incremental compiler starts and the transformation is triggered for class B.
> The ClassNode(A) is not initialized and I cannot iterate its properties.
> I tried to use compilationUnit.resolveVisitor.visitClass but it did not manage to resolve the class
>
> // get ResolveVisitor
> ClassNode targetClass = // get ClassNode from @CopyPropertiesFrom.value member
> Field rvField = CompilationUnit.class.getDeclaredField('resolveVisitor')
> rvField.setAccessible(true)
> ResolveVisitor rv = (ResolveVisitor) rvField.get(this.compilationUnit)
> rv.visitClass(targetClass)
>
> this throws:
> org.codehaus.jdt.groovy.internal.compiler.ast.GroovyEclipseBug: commencingResolution failed: no declaration found for class A -> A
>         at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.commencingResolution(JDTResolver.java:498)
>
> I am aware of the limitations imposed by the incremental compiler. However in my opinion it should be possible to resolve classes on demand.
>
> Can you please tell me if there is a working solution for my problem?
>
> Cheers,
> Krzysztof
>
> ---------------------------------------------------------------------
> 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: Re: [groovy-eclipse-plugin-dev] Resolving ClassNode during incremental compilation

Krzysztof Białek
After doing more experiments I can say that:
1. Class resolving actually works without using reflection
2. Class AST is not consistent between incremental and full compilation - that fact previously misled me and I thought that class resolving does not work at all

I have implemented simple logging AST transformation to show what is going on.
It logs resolved properties, fields, methods and class level annotations.

Code compiled with logging transformation:
@LogCompilation(B)
class A {
        String propA
}

@Deprecated // Runtime annotation
@SourceAnnotation // Source annotation
class B {
        String propB
}

So, I want to resolve class B during compilation of class A

Here are the results:
Full compilation:
#LogCompilation(com.example.groovy.classes.A): Start
#LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Properties: [propB]
#LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Fields: [propB]
#LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Methods: []
#LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Annotations: [java.lang.Deprecated -> java.lang.Deprecated, com.example.groovy.classes.SourceAnnotation -> com.example.groovy.classes.SourceAnnotation]
#LogCompilation(com.example.groovy.classes.A): Finish

Incremental compilation:
#LogCompilation(com.example.groovy.classes.A): Start
#LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Properties: []
#LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Fields: [$callSiteArray, $staticClassInfo, __$stMC, metaClass, propB]
#LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Methods: [getPropB, setPropB, this$dist$invoke$1, this$dist$set$1, this$dist$get$1, $getStaticMetaClass, getMetaClass, setMetaClass, invokeMethod, getProperty, setProperty, __$swapInit, super$1$wait, super$1$toString, super$1$wait, super$1$wait, super$1$notify, super$1$notifyAll, super$1$getClass, super$1$clone, super$1$equals, super$1$hashCode, super$1$finalize, $createCallSiteArray, $getCallSiteArray, class$]
#LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Annotations: [java.lang.Deprecated]
#LogCompilation(com.example.groovy.classes.A): Finish

Most probably incremental compiler is resolving class B from the bytecode (SourceAnnotation is lost)
Can JDTClassNode be made smart enough to hide this, eg. by reconstructing the properties?

Cheers,
Krzysztof

Dnia poniedziałek 24 czerwca 2013 14:19:29 piszesz:

> This is an odd case since you are trying to resolve a class that is
> not otherwise in the compilation unit.  Try using the
> org.codehaus.groovy.control.ResolveVisitor.resolve(ClassNode) method.
> It is protected and so you will need to use reflection to get at it.
>
> On Mon, Jun 24, 2013 at 1:15 PM, Krzysztof Białek
> <[hidden email]> wrote:
> > Hello,
> >
> > I am implementing AST transformation which is adding a subset of properties of class A to class B.
> > Technically class B is annotated with @CopyPropertiesFrom(A)
> > The transformation works well in complete project compilation where AST of class A is present when transforming class B
> > Unfortunately it does now work with greclipse incremental compiler (GGTS in my case).
> > Once class B is touched the incremental compiler starts and the transformation is triggered for class B.
> > The ClassNode(A) is not initialized and I cannot iterate its properties.
> > I tried to use compilationUnit.resolveVisitor.visitClass but it did not manage to resolve the class
> >
> > // get ResolveVisitor
> > ClassNode targetClass = // get ClassNode from @CopyPropertiesFrom.value member
> > Field rvField = CompilationUnit.class.getDeclaredField('resolveVisitor')
> > rvField.setAccessible(true)
> > ResolveVisitor rv = (ResolveVisitor) rvField.get(this.compilationUnit)
> > rv.visitClass(targetClass)
> >
> > this throws:
> > org.codehaus.jdt.groovy.internal.compiler.ast.GroovyEclipseBug: commencingResolution failed: no declaration found for class A -> A
> >         at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.commencingResolution(JDTResolver.java:498)
> >
> > I am aware of the limitations imposed by the incremental compiler. However in my opinion it should be possible to resolve classes on demand.
> >
> > Can you please tell me if there is a working solution for my problem?
> >
> > Cheers,
> > Krzysztof
> >
> > ---------------------------------------------------------------------
> > 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
|  
Report Content as Inappropriate

Re: Re: [groovy-eclipse-plugin-dev] Resolving ClassNode during incremental compilation

Andrew Eisenberg
Is it really that you need to resolve from source code, or is it that
the AST transform not being applied correctly during the incremental
build?

On Tue, Jun 25, 2013 at 12:59 PM, Krzysztof Białek
<[hidden email]> wrote:

> After doing more experiments I can say that:
> 1. Class resolving actually works without using reflection
> 2. Class AST is not consistent between incremental and full compilation - that fact previously misled me and I thought that class resolving does not work at all
>
> I have implemented simple logging AST transformation to show what is going on.
> It logs resolved properties, fields, methods and class level annotations.
>
> Code compiled with logging transformation:
> @LogCompilation(B)
> class A {
>         String propA
> }
>
> @Deprecated // Runtime annotation
> @SourceAnnotation // Source annotation
> class B {
>         String propB
> }
>
> So, I want to resolve class B during compilation of class A
>
> Here are the results:
> Full compilation:
> #LogCompilation(com.example.groovy.classes.A): Start
> #LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Properties: [propB]
> #LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Fields: [propB]
> #LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Methods: []
> #LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Annotations: [java.lang.Deprecated -> java.lang.Deprecated, com.example.groovy.classes.SourceAnnotation -> com.example.groovy.classes.SourceAnnotation]
> #LogCompilation(com.example.groovy.classes.A): Finish
>
> Incremental compilation:
> #LogCompilation(com.example.groovy.classes.A): Start
> #LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Properties: []
> #LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Fields: [$callSiteArray, $staticClassInfo, __$stMC, metaClass, propB]
> #LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Methods: [getPropB, setPropB, this$dist$invoke$1, this$dist$set$1, this$dist$get$1, $getStaticMetaClass, getMetaClass, setMetaClass, invokeMethod, getProperty, setProperty, __$swapInit, super$1$wait, super$1$toString, super$1$wait, super$1$wait, super$1$notify, super$1$notifyAll, super$1$getClass, super$1$clone, super$1$equals, super$1$hashCode, super$1$finalize, $createCallSiteArray, $getCallSiteArray, class$]
> #LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Annotations: [java.lang.Deprecated]
> #LogCompilation(com.example.groovy.classes.A): Finish
>
> Most probably incremental compiler is resolving class B from the bytecode (SourceAnnotation is lost)
> Can JDTClassNode be made smart enough to hide this, eg. by reconstructing the properties?
>
> Cheers,
> Krzysztof
>
> Dnia poniedziałek 24 czerwca 2013 14:19:29 piszesz:
>> This is an odd case since you are trying to resolve a class that is
>> not otherwise in the compilation unit.  Try using the
>> org.codehaus.groovy.control.ResolveVisitor.resolve(ClassNode) method.
>> It is protected and so you will need to use reflection to get at it.
>>
>> On Mon, Jun 24, 2013 at 1:15 PM, Krzysztof Białek
>> <[hidden email]> wrote:
>> > Hello,
>> >
>> > I am implementing AST transformation which is adding a subset of properties of class A to class B.
>> > Technically class B is annotated with @CopyPropertiesFrom(A)
>> > The transformation works well in complete project compilation where AST of class A is present when transforming class B
>> > Unfortunately it does now work with greclipse incremental compiler (GGTS in my case).
>> > Once class B is touched the incremental compiler starts and the transformation is triggered for class B.
>> > The ClassNode(A) is not initialized and I cannot iterate its properties.
>> > I tried to use compilationUnit.resolveVisitor.visitClass but it did not manage to resolve the class
>> >
>> > // get ResolveVisitor
>> > ClassNode targetClass = // get ClassNode from @CopyPropertiesFrom.value member
>> > Field rvField = CompilationUnit.class.getDeclaredField('resolveVisitor')
>> > rvField.setAccessible(true)
>> > ResolveVisitor rv = (ResolveVisitor) rvField.get(this.compilationUnit)
>> > rv.visitClass(targetClass)
>> >
>> > this throws:
>> > org.codehaus.jdt.groovy.internal.compiler.ast.GroovyEclipseBug: commencingResolution failed: no declaration found for class A -> A
>> >         at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.commencingResolution(JDTResolver.java:498)
>> >
>> > I am aware of the limitations imposed by the incremental compiler. However in my opinion it should be possible to resolve classes on demand.
>> >
>> > Can you please tell me if there is a working solution for my problem?
>> >
>> > Cheers,
>> > Krzysztof
>> >
>> > ---------------------------------------------------------------------
>> > 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
|  
Report Content as Inappropriate

Re: Re: Re: [groovy-eclipse-plugin-dev] Resolving ClassNode during incremental compilation

Krzysztof Białek
It does not matter for me if the AST is resolved from the source code or from the bytecode as long as the AST is consistent in both full and incremental compilation modes
I am forced to reconstruct the properties in my AST transform to achieve correct results during the incremental build
imo, the transform should not be aware of the compilation mode and rather the compiler is responsible for providing accurate AST

Cheers,
Krzysztof


Dnia wtorek 25 czerwca 2013 14:10:10 piszesz:

> Is it really that you need to resolve from source code, or is it that
> the AST transform not being applied correctly during the incremental
> build?
>
> On Tue, Jun 25, 2013 at 12:59 PM, Krzysztof Białek
> <[hidden email]> wrote:
> > After doing more experiments I can say that:
> > 1. Class resolving actually works without using reflection
> > 2. Class AST is not consistent between incremental and full compilation - that fact previously misled me and I thought that class resolving does not work at all
> >
> > I have implemented simple logging AST transformation to show what is going on.
> > It logs resolved properties, fields, methods and class level annotations.
> >
> > Code compiled with logging transformation:
> > @LogCompilation(B)
> > class A {
> >         String propA
> > }
> >
> > @Deprecated // Runtime annotation
> > @SourceAnnotation // Source annotation
> > class B {
> >         String propB
> > }
> >
> > So, I want to resolve class B during compilation of class A
> >
> > Here are the results:
> > Full compilation:
> > #LogCompilation(com.example.groovy.classes.A): Start
> > #LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Properties: [propB]
> > #LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Fields: [propB]
> > #LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Methods: []
> > #LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Annotations: [java.lang.Deprecated -> java.lang.Deprecated, com.example.groovy.classes.SourceAnnotation -> com.example.groovy.classes.SourceAnnotation]
> > #LogCompilation(com.example.groovy.classes.A): Finish
> >
> > Incremental compilation:
> > #LogCompilation(com.example.groovy.classes.A): Start
> > #LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Properties: []
> > #LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Fields: [$callSiteArray, $staticClassInfo, __$stMC, metaClass, propB]
> > #LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Methods: [getPropB, setPropB, this$dist$invoke$1, this$dist$set$1, this$dist$get$1, $getStaticMetaClass, getMetaClass, setMetaClass, invokeMethod, getProperty, setProperty, __$swapInit, super$1$wait, super$1$toString, super$1$wait, super$1$wait, super$1$notify, super$1$notifyAll, super$1$getClass, super$1$clone, super$1$equals, super$1$hashCode, super$1$finalize, $createCallSiteArray, $getCallSiteArray, class$]
> > #LogCompilation(com.example.groovy.classes.B -> com.example.groovy.classes.B): Annotations: [java.lang.Deprecated]
> > #LogCompilation(com.example.groovy.classes.A): Finish
> >
> > Most probably incremental compiler is resolving class B from the bytecode (SourceAnnotation is lost)
> > Can JDTClassNode be made smart enough to hide this, eg. by reconstructing the properties?
> >
> > Cheers,
> > Krzysztof
> >
> > Dnia poniedziałek 24 czerwca 2013 14:19:29 piszesz:
> >> This is an odd case since you are trying to resolve a class that is
> >> not otherwise in the compilation unit.  Try using the
> >> org.codehaus.groovy.control.ResolveVisitor.resolve(ClassNode) method.
> >> It is protected and so you will need to use reflection to get at it.
> >>
> >> On Mon, Jun 24, 2013 at 1:15 PM, Krzysztof Białek
> >> <[hidden email]> wrote:
> >> > Hello,
> >> >
> >> > I am implementing AST transformation which is adding a subset of properties of class A to class B.
> >> > Technically class B is annotated with @CopyPropertiesFrom(A)
> >> > The transformation works well in complete project compilation where AST of class A is present when transforming class B
> >> > Unfortunately it does now work with greclipse incremental compiler (GGTS in my case).
> >> > Once class B is touched the incremental compiler starts and the transformation is triggered for class B.
> >> > The ClassNode(A) is not initialized and I cannot iterate its properties.
> >> > I tried to use compilationUnit.resolveVisitor.visitClass but it did not manage to resolve the class
> >> >
> >> > // get ResolveVisitor
> >> > ClassNode targetClass = // get ClassNode from @CopyPropertiesFrom.value member
> >> > Field rvField = CompilationUnit.class.getDeclaredField('resolveVisitor')
> >> > rvField.setAccessible(true)
> >> > ResolveVisitor rv = (ResolveVisitor) rvField.get(this.compilationUnit)
> >> > rv.visitClass(targetClass)
> >> >
> >> > this throws:
> >> > org.codehaus.jdt.groovy.internal.compiler.ast.GroovyEclipseBug: commencingResolution failed: no declaration found for class A -> A
> >> >         at org.codehaus.jdt.groovy.internal.compiler.ast.JDTResolver.commencingResolution(JDTResolver.java:498)
> >> >
> >> > I am aware of the limitations imposed by the incremental compiler. However in my opinion it should be possible to resolve classes on demand.
> >> >
> >> > Can you please tell me if there is a working solution for my problem?
> >> >
> >> > Cheers,
> >> > Krzysztof
> >> >
> >> > ---------------------------------------------------------------------
> >> > 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
|  
Report Content as Inappropriate

Re: Resolving ClassNode during incremental compilation

Jochen Theodorou
Am 25.06.2013 23:23, schrieb Krzysztof Białek:
> It does not matter for me if the AST is resolved from the source code or from the bytecode as long as the AST is consistent in both full and incremental compilation modes
> I am forced to reconstruct the properties in my AST transform to achieve correct results during the incremental build
> imo, the transform should not be aware of the compilation mode and rather the compiler is responsible for providing accurate AST

The question was eclipse specific, so I don't want to butt on that...
but I have to leave one remark... If you intend to have this transform
working in general and outside eclipse, then you cannot depend on source
or bytecode only level annotations. That is, because outside eclipse
reflection might be the only available information source, and
reflection does not show those

bye blackdrag
--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.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: Resolving ClassNode during incremental compilation

Andy Clement
Can JDTClassNode be made smart enough to hide this, eg. by reconstructing the properties?

I think we had that for a while, but it broke something else so we reverted back to what we have now.

Andy


On 26 June 2013 02:34, Jochen Theodorou <[hidden email]> wrote:
Am <a href="tel:25.06.2013%2023" value="+12506201323" target="_blank">25.06.2013 23:23, schrieb Krzysztof Białek:

It does not matter for me if the AST is resolved from the source code or from the bytecode as long as the AST is consistent in both full and incremental compilation modes
I am forced to reconstruct the properties in my AST transform to achieve correct results during the incremental build
imo, the transform should not be aware of the compilation mode and rather the compiler is responsible for providing accurate AST

The question was eclipse specific, so I don't want to butt on that... but I have to leave one remark... If you intend to have this transform working in general and outside eclipse, then you cannot depend on source or bytecode only level annotations. That is, because outside eclipse reflection might be the only available information source, and reflection does not show those

bye blackdrag
--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.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: Resolving ClassNode during incremental compilation

Andrew Eisenberg
I think the best thing right now is to raise a bug for this.  I could
imagine that there might be a way to force computing of properties on
binary files if a proper flag is set somewhere.  But, as Andy said,
this would break things if we just enable properties on all class
files.

On Wed, Jun 26, 2013 at 10:14 AM, Andy Clement <[hidden email]> wrote:

>> Can JDTClassNode be made smart enough to hide this, eg. by reconstructing
>> the properties?
>
> I think we had that for a while, but it broke something else so we reverted
> back to what we have now.
>
> Andy
>
>
> On 26 June 2013 02:34, Jochen Theodorou <[hidden email]> wrote:
>>
>> Am 25.06.2013 23:23, schrieb Krzysztof Białek:
>>
>>> It does not matter for me if the AST is resolved from the source code or
>>> from the bytecode as long as the AST is consistent in both full and
>>> incremental compilation modes
>>> I am forced to reconstruct the properties in my AST transform to achieve
>>> correct results during the incremental build
>>> imo, the transform should not be aware of the compilation mode and rather
>>> the compiler is responsible for providing accurate AST
>>
>>
>> The question was eclipse specific, so I don't want to butt on that... but
>> I have to leave one remark... If you intend to have this transform working
>> in general and outside eclipse, then you cannot depend on source or bytecode
>> only level annotations. That is, because outside eclipse reflection might be
>> the only available information source, and reflection does not show those
>>
>> bye blackdrag
>> --
>> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
>> blog: http://blackdragsview.blogspot.com/
>> german groovy discussion newsgroup: de.comp.lang.misc
>> For Groovy programming sources visit http://groovy-lang.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


Loading...