|
History
| Log In
|
|
|
|
Is the expected behavior for public Groovy fields to generate the get/set methods and omit the field? Or include the field... I can't recall...
As for custom set/get bits, I think when generating the get/set methods we can check if there is already one defined and omit. And when we run across custom set/get methods we can replace the javadoc for the method.
Ugh, this has the unfortunate side-effect of causing mojo parameter injection to properties to fail
This fails: /**
* @parameter expression="${project}"
*/
def project
This works: /** * @parameter expression="${project}" */ private def project class MyGroovyClass {
def p
}
should become public class MyGroovyClass { private Object p public void setP(Object p) { throw new Error(); } public Object getP() { throw new Error(); } } The property is private. Kay... though I still have a problem with the javadoc... for the property. The field will get the javadoc which it comes with, then I can either omit them for the get/set or make stupid ones.
For now I'm gonna omit, leaving the javadoc only for the field, since that should be compatible with the Mojo muck. I believe this is fixed now, new snaps deploying shortly.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Closed
Major
Getters/Setters should be generated for properties.
// MyClass.groovy
class MyClass {
/**
*/
def var = null
}
// Generated stub ...
public class MyClass extends Object {
/**
*/
public Object getVar() { throw new Error(); }
public void setVar(Object var) { throw new Error(); }
}
I think attaching the documentation to the getter makes sense. But what if the groovy class defines it's own getter with groovydoc comments?