When running on windows, the backslash is used to escape characters instead of being used as is.

After processing the command line, replace any backslash by a double backslash.

It seems it is solvable using a groovy script that create a new variable with the expected value, and use it as the target path base :

            <!-- === Groovy hack to support windows pathes === -->
            <plugin>
                <groupId>org.codehaus.groovy.maven</groupId>
                <artifactId>gmaven-plugin</artifactId>
                <executions>
                    <execution>
                        <id>set-unixy_build_directory!</id>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>execute</goal>
                        </goals>
                        <configuration>
                            <classpath>
                                <element>
                                    <groupId>commons-lang</groupId>
                                    <artifactId>commons-lang</artifactId>
                                    <version>2.4</version>
                                </element>
                            </classpath>
                            <source>
                                project.properties['mybuilddir'] =
                                project.build.directory.replace('\\','/');
                            </source>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

            <!-- === code generation using the doclets === -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-javadoc-plugin</artifactId>
                <executions>
                    <!-- === Javabeans generation === -->
                    <execution>
                        <!-- ... -->
                        <configuration>
                            <doclet>com.sporniket.libre.javabeans.doclet.ExpanderDoclet</doclet>
                            <!-- ... -->
                            <additionalOptions>
                                <additionalOption>-d</additionalOption>
                                <additionalOption>"${mybuilddir}/generated-classes/javabeans"</additionalOption>
                                <!-- ... -->
                            </additionalOptions>
                            <!-- ... -->
                        </configuration>
                    </execution>
                </executions>
            </plugin>

User Story

As sporniket-javabeans-doclet, I want to generate parametrized annotation
So that a developper is able to use jackson-annotations (@JsonProperty, @JsonTypeInfo and @JsonSubTypes)

Detailed Technical Specifications

Parameter name rules

• The "value" parameter name is omitted, only the parameter value is generated
• Otherwise the parameter name is generated followed by '=' and the parameter value

Parameter value rules

• Literral values that are not class names are generated as is.
• Enum values, constants, are imported to minimize value length.
• Class names are processed to target generated classes if appliable

When a field has a native type, e.g. boolean, the generated classes will import the native type and trigger a compilation error.

Native types must be removed from the import list.

The current fluent setter generation has some flaws :

• it can only generate fluent setters for the attribute directly declared in the class description
• herited fluent setters breaks the chaining of calls (cannot access to the derived class fluent setters without casting...)
• add bloat to an already bloated javabean.

Thus It may be more appropriate to remove the fluent api in the generated bean, and to generate a fluent Builder from an existing class, scanned using reflexion :

• the generator process each class of a designated package (more on that latter)
• If a class is abstract or is an interface, skip to the next one
• If the class has no setter ("setXxx(...)"), skip to the next one
• Generate a builder following the given pattern

public class MaStructureBuilder {
    private MaStructure maStructure = new MaStructure() ;

    public static final MaStructureBuilder builder() {
        return new MaStructureBuilder() ;
    }

    public build() {
        MaStructure result = maStructure ;
        maStructure = new MaStructure() ;
        return result ;
    }

    public void withXxx(XxxType value) {
        maStructure.setXxx(value);
        return this ;
    }

    //etc...
}

The generator will be instructed to scan some class using :

• a list of specifically targeted classes
• a list of packages
• a list of specifically excluded classes
• a list of regexp to exclude classes matched on their simple name
• a list of regexp to exclude classse matched on their full name

Do not generate PROPERTY_NAME__... fields for basic properties.

when generating a fluent accessor in a class, and generating a subclass, using the herited fluent accessor cannot be chained to another fluent accessor of the subclass.

allow something like :

<fluent name="xxx" type="yyy">

The name and type MUST obviously match the original definition for the code to be ok.

Redefining the suffixes (Foo.__EVENT_SUFFIX__ADD, Foo.__EVENT_SUFFIX__ADD_ALL,...) for use in each generated class is ugly.
Generate the names without using literral instead of storing the prefix in a separate static final field for use when initializing a property name for a managed collection/map event.

User story

As a developper

I want to have a separated javabean and builder generation code

In order to generate javabeans from other descriptions than POJO, e.g. from a database schema.

Technical details

• The exchance format would be the json representation of a collection of ClassSpecs
• Each generator (pojo, javabean, builder) would be adressable, and would be wrapped in a maven plugin

When the generated javabean is abstract, like :

public abstract class SampleAbstractBean {
    private String mySampleProperty ;
    public String getSampleProperty() { return mySampleProperty ; }
    public void setSampleProperty(String sampleProperty) { mySampleProperty = sampleProperty ; }
}

Instead of prevent generating a Builder, generate a generic builder, like :

public class SampleAbstractBean_Builder<T extends SampleAbstractBean> {
    private T myInstance = new T() ;
    public SampleAbstractBean_Builder<T> withSampleProperty() { 
        T.setSampleProperty(sampleProperty) ; 
        this return; 
    }
    public T done() {
        T result = myInstance ;
        myInstance = new T() ;
        return myInstance ;
    }
}

Most of the usage directions will be put in the README instead

Sometimes a class should provide a default valid state, allow the field description to declare the initial value. If missing, the field is declared without default value.

Class annotations are imported and generated using the simplename. This is not the case for member fields annotations, that use the fully qualified names, thus the generated code is less nice too read.

For now the code generation mixes code generation using "printf" with computing the values given to those printfs.

In order to use a templating system like velocity, the data computation should result into a data structure containing any values to give to those printfs or the templating system

These "code specifications" will be gathered in a "codespecs" package, and named :

• ImportSpecs : class name, directly required by javabean (not directly = required by inherited field)
• AnnotationSpecs
• JavadocSpecs (extends AnnotationSpecs)
• ClassSpecs : ImportSpecs, FieldSpecs, AnnotationSpecs
• FieldSpecs : AnnotationSpecs

Thus each ClassDoc object will result into a ClassSpecs object, that will feeds the code generation.

remove the "final" keywords so that the fields may be changed

When there is the following declaration :

String[] refFields;

Then there is the following generated code :

    private String[] myRefFields ;

    public String[] getRefFields() {return myRefFields ;}
    public void setRefFields(String[] value) {myRefFields = value;}

Instead of the following generated code :

    private String myRefFields ;

    public String getRefFields() {return myRefFields ;}
    public void setRefFields(String value) {myRefFields = value;}

For a query method named findByIdProduct(...), the private field in the entity must have the name idProduct, instead of myIdProduct

in the sample project, the generated code looks like :

package com.sporniket.sample.pojos;

import java.util.Date;
import java.util.List;

public abstract class SampleBasic
{

    private Date date ;
    private List<String> names ;

    public Date getdate() {return this.date ;}
    public void setdate(Date value) {this.date = value;}

    public List<String> getnames() {return this.names ;}
    public void setnames(List<String> value) {this.names = value;}

}

e.g. getdate() should be getDate().

The builder class does not compile, because it expects camel cases accessors.

When a field is annoted with @Pattern("\\d{5}")

Then the generated javabean field must be annoted with @Pattern("\\d{5}") instead of @Pattern("\d{5}")

Workaround

The POJO field is annoted with @Pattern("\\\\d{5}")

Steps to reproduce

1. Write a FooRaw with the following field : Map<String, List<String>> headers;
2. The generated code (field, accessors, fluent builders) defines headers as Map<String,List> instead of Map<String, List<String>> headers

See https://vladmihalcea.com/the-best-way-to-map-an-enum-type-with-jpa-and-hibernate/

• a plugin parameter allows to set the type of the custom types (either fully qualified or in the same package)
• Each entity class has an annotation @TypeDef(name = "pgsql_enum", typeClass = [custom type implementation].class)
• Each column using an enumeration must have the following annotations : @Enumerated(EnumType.STRING) @Type( type = "pgsql_enum" )

When a table has a multi-column primary key, there is an id class.

• Define a conversion method

//...
@IdClass(/*...*/)
class EntityThing {
  //...  
  public IdOfThing toIdClass() { return new IdOfThing(e.myKeyField1/*, ...*/) ; }
}

In a pojo to expand, the field myFoo MUST expand to the field myFoo and accessors getFoo() and setFoo(...).

When a primary key of an entity is made of several columns,

• create an id class (IdOf[EntityName])
• referenced by the entity class with the @javax.persistence.IdClass

An instance of id class will be immutable, and redefine the hashcode and equals using its components.

when creating a full class hierarchy, the base class cannot be abstract.

• Add a boolean 'abstract' property to the 'Bean' tag

When a field is annoted like this : @JsonProperty("a_different_name") String altName

Then the generated javabean must have the annotation on the field AND the accessors

In order to get a correct JSON representation. (otherwise we get a field "a_different_name" and "altName")

Technical details

• A registry of annotations that MUST be copied to the setter
• A registry of annotations that MUST be copied to the getter
• A registry of annotations that MUST NOT be copied to the field

Update 2019-09-19

• While generating javabeans : convert pojo class names into javabeans class names.
• While extracting pojo : copy as is.
• field javadoc : copy to field, accessors and the fluent method in the builder class.

Update : in fact, javadoc annotations are not annotations in ClassDoc, look at comments and tags. see https://docs.oracle.com/javase/7/docs/jdk/api/javadoc/doclet/com/sun/javadoc/Doc.html

The javadoc class description is a special case of annotation for two reasons :

• as a javadoc annotation, special case of annotation
• as the annotation does not use a '@description' tag

The javadoc class description should be copied "as is" into the generated javabean code.

A kind of front controller and session data are required to implement #11 .

Such controller would :

• be initialized with a set of xml description files (depending the workflow, i.e. a maven plugin could specify all the xml files of the project), that would constitute the processing session. Especially, one would have an index of any generated classes, to infer inheritance, and required code part to generate.
• create and initialize any required processor/generator, passing appropriate session data. The lifecycle of processors and generators MUST be formalized.
• call the processing for each beanset.
• done

The value of additionalOptions is not supported in some maven installation (I got a problem with Jenkins)

The value must be a collection of additionnalOption.

E.g. :

<additionalOptions>-d
  ${project.build.directory}/generated-classes/javabeans
-beanFieldPrefix ''</additionalOptions>

Should be rewritten as :

<additionalOptions>
    <additionalOption>-d</additionalOption>
    <additionalOption>"${project.build.directory}/generated-classes/javabeans"</additionalOption>
    <additionalOption>-beanFieldPrefix</additionalOption>
    <additionalOption>""</additionalOption>
</additionalOptions>

As a side effect, the pom will be more legible.

When the xml description has no annotation, the plugin fails with a NPE

User Story

As a developper, I want to subclass a generated bean to add behaviors/method, and I want to be able to instanciate such enhanced javabeans using the builder, in order to avoid writing manually a duplicate of the generated builder for the base class.

Technical specification

Given the generated javabean A and its builder class A_Builder.

Then a regular javabean would be instancied like that : A myA = new A_Builder().with...()....done();.

Then a subclass B of the javabean would be instancied like that : B myB = (B) new A_Builder(new B()).with...().....done() ;

after pom model version : parents, artefactId and packaging, properties, description and url, etc...

For reference, see poms in the core repository

When the column metadata has 'IS_AUTOINCREMENT' to 'YES' and no default value

Then the generated value use 'IDENTITY'

When the column metada has a default value like 'nextval('lca."Foo_id_seq"'::regclass)'

Then the generated value use 'SEQUENCE' and MUST define a @SequenceGenerator annotation

The generated javabean import too much classes. It should import classes required by its declared fields only.

Simple annotations are annotations that have no parameters (e.g. @Deprecated)

When generating javabean or extracting pojo, copy those simple annotations, using the simple name instead of the fully qualified name when possible.

Special case : @Deprecated annotations should be copied on the field, on the getter and on the setter.

Use this request to get Postgresql enum values : 

SELECT 
 pg_namespace.nspname as schema,
 pg_type.typname AS enum_type, 
 pg_enum.enumlabel AS enum_value 
FROM pg_type 
JOIN pg_enum ON pg_enum.enumtypid = pg_type.oid 
JOIN pg_namespace ON pg_namespace.oid = pg_type.typnamespace
order by pg_enum.enumtypid, pg_enum.enumsortorder

and filter using the target schema.

if one of the value forming the key is null, hashcode and equality should revert to the default implementation.

maven must not fail when generating the javadoc, and no warning either.

While mvn install the next version of the project (see acfd4de), the doclet tried :

Generating javabean null from com.sporniket.libre.javabeans.doclet.codespecs.ImportSpecs_Builder 

The build obviously failed.

The doclet MUST filter out the classes that does not have the pojoSuffix.

see what has be done in the core repository.

Castor seems dead, and Jaxb is the built-in equivalent-ish in the jdk.

e.g. the field Boolean directlyRequired will generate the accessor public Boolean getDirectlyRequired().

It should be public Boolean isDirectlyRequired() to follow the javabean convention.

For now, the generated classes contains code for managing bounded and vetoed properties, even if there is none.

• do not add support for listener/fire event for bounded/vetoed properties if there is none
• do not add property name if it is not boundable/vetoable