GMaven (OLD... DO NOT USE)

Getters/Setters should be generated for properties.

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.0-beta-3
  • Fix Version/s: 1.0-rc-1
  • Component/s: stub generation
  • Labels:
    None
  • Number of attachments :
    0

Description

Consider the following ...

public interface ExampleInterface {
    public void setExampleProperty(Object exampleProperty);
}

And the following groovy class ...

class ExampleClass implements ExampleInterface {
    def exampleProperty
}

This should work and does if you aren't using the joint compile stuff.

Issue Links

Activity

Hide
Luke Daley added a comment -

This also begs the question of what to do with the groovy doc :S

// MyClass.groovy

class MyClass {

/**

  • Some documentation here
    */
    def var = null

}

// Generated stub ...

public class MyClass extends Object {

/**

  • Some documentation here
    */
    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?

Show
Luke Daley added a comment - This also begs the question of what to do with the groovy doc :S // MyClass.groovy class MyClass { /**
  • Some documentation here */ def var = null
} // Generated stub ... public class MyClass extends Object { /**
  • Some documentation here */ 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?
Hide
Jason Dillon added a comment -

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...

Show
Jason Dillon added a comment - 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...
Hide
Jason Dillon added a comment -

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.

Show
Jason Dillon added a comment - 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.
Hide
Jason Dillon added a comment - - edited

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
Show
Jason Dillon added a comment - - edited 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
Hide
Luke Daley added a comment -
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.

Show
Luke Daley added a comment -
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.
Hide
Jason Dillon added a comment -

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.

Show
Jason Dillon added a comment - 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.
Hide
Jason Dillon added a comment -

I believe this is fixed now, new snaps deploying shortly.

Show
Jason Dillon added a comment - I believe this is fixed now, new snaps deploying shortly.

People

Vote (1)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: