JavaStubGenerator doesn't generate annotations available in Groovy code

Potential patch

Jochen, let me know if there are any issues with patch otherwise I will apply in a few days.

the patch seems to be only allowing for numbers and constants that are ten interpreted as String. Missing are classes and enums (both clear name, the same as for numbers)

ah yes... another part would be to print the annotations only if the "java5" field is true.

Yes, both very good points. I might have to leave those changes and some kind of test to someone else unless I get a good Internet connection in San Fran and get time to look again.

revised patch addressing Jochen's raised points

So the one thing that I am still unsure of is whether we need to add back in the default imports which I commented out in genImports a few weeks back - everything else is fully qualified but I don't that is the case with Annotation constants.

If the fully qualified class name would be used, then there is no need for an annotaton. Since there seems to be a class resolving phase I think that it is not needed

For the Resolving Phase to occur before we print out the Java stub annotation info, I moved the stubGenerator visitor from CONVERSION to SEMANTIC_ANALYSIS phase. I still need to create a bunch of tests covering all of the cases.

A quick check for import aliasing was also added. Again tests pending but works locally for me for the testcase given in GMAVEN-75.

Paul made some changes in this area, please reopen the issue if it's still not working as expected.

Just tried it with Groovy 1.7.3.
Annotations put on properties are not generated.

"src/main/scripts/com/clearforest/plugins/springbatch/SpringBatchMojo.groovy":

package com.clearforest.plugins.springbatch

import org.jfrog.maven.annomojo.annotations.MojoPhase
import org.jfrog.maven.annomojo.annotations.MojoGoal
import org.codehaus.gmaven.mojo.GroovyMojo
import org.jfrog.maven.annomojo.annotations.MojoParameter

/**
 * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 * Spring Batch invoker
 * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 */
@MojoGoal( "run" )
@MojoPhase( "install" )
class SpringBatchMojo extends GroovyMojo
{

    @MojoParameter ( required = true )
    String sth

    void execute ()
    {
        System.out.println( "[[[[[[[[$sth]]]]]]]]]]]" );
    }
}

generates the following code at "target/generated-sources/groovy-stubs/main/com/clearforest/plugins/springbatch/SpringBatchMojo.java":

package com.clearforest.plugins.springbatch;

import org.jfrog.maven.annomojo.annotations.MojoGoal;
import org.codehaus.gmaven.mojo.GroovyMojo;
import org.jfrog.maven.annomojo.annotations.MojoParameter;
import org.jfrog.maven.annomojo.annotations.MojoPhase;

@MojoGoal(value="run") @MojoPhase(value="install") public class SpringBatchMojo
  extends org.codehaus.gmaven.mojo.GroovyMojo  implements
    groovy.lang.GroovyObject {
public SpringBatchMojo
() {}
public  groovy.lang.MetaClass getMetaClass() { return (groovy.lang.MetaClass)null;}
public  void setMetaClass(groovy.lang.MetaClass mc) { }
public  java.lang.Object invokeMethod(java.lang.String method, java.lang.Object arguments) { return null;}
public  java.lang.Object getProperty(java.lang.String property) { return null;}
public  void setProperty(java.lang.String property, java.lang.Object value) { }
public  String getSth() { return (String)null;}
public  void setSth(String value) { }
public  void execute() { }
protected  groovy.lang.MetaClass $getStaticMetaClass() { return (groovy.lang.MetaClass)null;}
}

@MojoParameter annotation isn't generated

By the way, note that sth is not a field, but a property.

Yeah, right, I mean properties, sorry

So, how do we handle properties here? Normally the stub generator doesn't print-out the private fields. A property becomes (a private field + getter/setter methods).

In properties case, do we start printing out the code for wrapped private fields also?

Not sure if it will make sense to print the annotation provided on the property on the getter/setter methods.

My use case are Groovy MOJOs and I try to use AnnoMojo (http://goo.gl/rbRw) for Java5 annotations.
That's the reason for annotation properties, they become plugin configurations later

Don't know about MOJOs. So, a question.

From your use case point of view, if "String sth" internally becomes "private String sth + public getSth()/setSth()" - will it help for the plugin configuration later if the annotation remained on the private field or moved on to accessor methods?

Not sure whether it's an option for you or not, but a change from

@MojoParameter ( required = true )
String sth

to

@MojoParameter ( required = true )
public String sth

will make sure that you get the following in the output

@org.jfrog.maven.annomojo.annotations.MojoParameter(required=true) public java.lang.String sth;

Yeap! It worked. Thanks a lot )

Is this requirement for "public" modifier is something that I'll always need to use or it may be relaxed in the following versions?

So, shall we close it back?

Instead of a direct answer, there are a few indirect things there to be told:

1) "String sth" is a property in groovy code that gets changed internally to "private String sth + getSth()/setSth()"

2) "public String sth" is a field in groovy code and it remains unchanged as a field.

3) Stub generators currently generates annotations only for non-private fields and not for properties.

Going forward:

4) The stub generator may start doing something for properties as well - not sure at this point what that will be - whether the annotation will go on to stick to private field or accessors.

5) It is highly unlikely that property "String sth" will later translate to "public String sth" field instead of (private field + accessors).

Ok, I see, thanks for the explanation. In this case the issue can be closed again, I suppose.
I've just updated 3 of our Maven plugins to use AnnoMojo annotations instead of Javadoc ones, we'll see in a couple of days if everything is Ok.
But from what I saw, the generation works Ok now ..

Many thanks again. We were waiting for a long time to make this switch.

You are welcome. Forwarding "many thanks" to Paul for the original implementation

It seems to me annotation properties of array type are still not handled correctly. For example, with Groovy 1.7.3 and 1.7.4 :

// ArrayAnnotation.java
public @interface ArrayAnnotation {
String[] value() default {};
}

// AnnotatedClass.groovy
@ArrayAnnotation(["foo", "bar"])
class AnnotatedClass { }

generates the stub :

@ArrayAnnotation(value=null)
public class AnnotatedClass extends java.lang.Object implements groovy.lang.GroovyObject {
// irrelevent stuff removed
}

Yes, there are a few known limitations of the current stub generator - one of them being that we can't easily resolve constant expressions for the general case (at least not without significant overheads) and we handle constant-looking things as best we can by hand-coded "sniffing" of such expressions - and arrays/lists are not in the list of what we currently look for - but could be.

Does the above cause you particular problems? Obviously the real constants will be in the Groovy byte code just not in the stubs which are only short-lived.

In any case, probably worth a new issue to handle arrays/lists as that may not be too hard.

You are right, it turns out I can successfully deactivate stub generation for the offending classes (they are unit tests). Thanks for your insight.

Shall I file a new issue anyway ?

With some delay, I opened issue GROOVY-4394