Re: Groovy AST not taking?

Robert Fischer wrote:

Wait a sec -- what's the deal with "@foo.WithLog"?

I just used a different package when copying your code.

Robert Fischer wrote:

I was running under the documentation at http://groovy.codehaus.org/Local+AST+Transformations (which
looks copy-pasted from Hamlet's Behind the Times blog post), which says this:
==
   The public visit(ASTNode[], SourceUnit) method is invoked for each source unit that contains your
   target annotation. The AST you receive is not for the @WithLogging annotated method, it is for the
   entire file that contains @WithLogging.
==
Is that a lie?  Or is there something different going on?

The documentation is wrong. The ASTTransformation interface is used both for local and global transforms. For local transforms, ASTTranformation.visit() is called once per annotated node (class, method, or field; method parameters don't seem to be supported). The first element in the ASTNode array holds the annotation, the second one the annotated node. For global transforms, ASTTranformation.visit() is called once per file. The first element in the ASTNode array holds the ModuleNode representing the file.

Robert Fischer wrote:

I thought that AST Transforms mangled the class during compilation.

It does.

Robert Fischer wrote:

 I want my log property to not only be visible via Groovy, but to Java classes, too.  Do I really
need to do a global transform for this?

No. The reason why I suggested a global transform is that the compiler seems to do some checks for static properties during semantic analysis. Therefore you might need to add 'log' before semantic analysis if you want to support all ways that it could be accessed (qualified, unqualified, from the same class, from other classes, etc.). But only global transforms can be run before semantic analysis (i.e. in phase CONVERSION).

Robert Fischer wrote:

I really don't like the sound of that, because it creates hassle in compiling.

There isn't really much difference between local and global transforms. Global transforms don't create more hassles. It's only that the unit of work is more coarse-grained (ModuleNode instead of an annotated node), and that you need to include a properties file along with your transform in order to activate it. In return you gain more flexibility.

Robert Fischer wrote:

Is there a better Compile Phase I could be using?  The documentation on compile phases is
practically non-existent, so I'm just aping what I'm seeing in the example.
http://groovy.codehaus.org/api/org/codehaus/groovy/control/CompilePhase.html

In general CANONICALIZATION is recommended, although the current compiler does not perform any canonicalization so you could just as well choose SEMANTIC_ANALYSIS. What this gives you over CONVERSION is that types etc. have been resolved and that the AST more accurately reflects the program (a few ASTNodes are replaced during semantic analysis).
Some transforms need to do their stuff before semantic analysis. For example this is necessary when adding an import, or a parameter to a method declaration. In that case you need a global transform.

Robert Fischer wrote:

And with regard to build -- is there a particular stunt I need to pull to ensure a local transform
is used?  I thought it was sufficient to just have it in the class path.

Yes that should be sufficient. A transform and the code to be transformed must be compiled separately, and the transform must be on the compile classpath when the latter is compiled. What happens when you run my "test"? Are you using plain groovyc or a build tool/IDE?

Cheers,
Peter