verhas / fluflu Goto Github PK

Hi , I am very interested in this tool, but I don't know how to use it in my maven project for the code generation part.

I write a small class like:

@Fluentize(className = "CoreClass", startState = "new", startMethod = "create")
public class CriticalPathMethod implements Cloneable {

.....

}

And in the command line, I try:

apt -cp ./:./fluflu-2.0.0.jar monmouth/schedule/logic/CriticalPathMethod.java

But nothing happens.
Will you please give some use case samples? Really appreciate.

Ken

I can see that you created a couple of fluent helper classes in com.javax0.aptools to abstract the APT API, which is nice.

It might be useful as a proof of concept to generate those helper classes using fluflu. As a side-effect, you'd get some additional documentation effect

Assume I have these "end" methods:

@Transition(from = "X", end = true)
public String end1() throws Exception {
    return null;
}

@Transition(from = "Y", end = true)
public void end2() throws Throwable {
    return null;
}

I'd expect the generated method to look like this:

public String end1() throws Exception {
    return core.end();  
}
public void end2() throws Throwable {
    core.end(); 
}

It might be worth thinking about a license for your tool, early. This is not a hard requirement by Sonatype (managing Maven Central), but it's still recommended:
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide

There are two important reasons why you should do it:

1. You can communicate ownership and copyright (or absence thereof, if you prefer that)
2. You can communicate legal disclaimers

Currently, @Fluentize allows only a single start state and method. For a more sophisticated fluent API, it would be nice if @Fluentize had a signature like this:

@Retention(RetentionPolicy.SOURCE)
@Target(ElementType.TYPE)
public @interface Fluentize {
    String className() default "";
    String[] startStates() default ""; // Change here
    String[] startMethods() default ""; // Change here
}

The above is just a suggestion to show the idea. I don't think that two String[] arrays would be the ideal way to model this. Probably, more annotations should be introduced.

Instead of generating code that relies on the Java clone capability let the programmer create a method in the annotated class that makes the cloning class specific and annotate the method so that the generated methods call that method to get a new instance of the class instead of cloning.

The method annotated using the annotation

@Cloner

should return the base class.

I'm spamming you with ideas / features ;-)

Ideally, fluflu's APT tools shouldn't be a runtime / compile-time dependency. Instead they should be used as a Maven plugin, if that's possible. Once the generated code is compiled and packaged, the only thing left to stay might be the annotations.

As a matter of fact, I can see some use-cases where the annotations might be useful at runtime, if they were changed to RetentionPolicy.RUNTIME

Hi Peter,

So I'll just tell you my thoughts through issues, I guess that's the easiest and most trackable way to communicate. BTW, too bad you already released 1.0.0 to Maven Central. Maybe you could add a disclaimer that fluflu doesn't (yet?) follow semantic versioning: http://semver.org/

About Cloneable, your example contains a reference to:

protected List<byte[]> b = new LinkedList<>();

This list, when cloned, will not deep-clone all the byte arrays. Note, that it works for this Set:

Set<Integer> j = new HashSet<>(); 

... because Integer is immutable.

So I think that the promise of supporting Cloneable might be a false one. What do you think?

XJC removes sources from the target directory (typically target/generated-sources/xjc), if they are no longer needed / valid. I guess this should be done as well in fluflu, without requiring to call mvn clean

When I have intermediate states "X" and "Y" as such:

@Transition(from = "X", to = "Y")
abstract Impl fromXtoY();

I would like to be able to consume those states in API methods, e.g.

@Transition(from = "A", to = "B")
abstract Impl fromAtoB(X x, Y y);

A more real-life example from jOOQ:

// T is created through a fluent API:
Table T = T1.join(T2).on("...");

// T can be consumed in another, related fluent API:
select().from(T);

Unfortunately, with the current implementation, I cannot use the types X and Y in my annotated fromAtoB() method, as those types are not generated yet. I'm not sure how to solve this problem...

Currently, @Transition implicitly generates a new method with the annotated method's name, as can be seen here:

  private String replaceMethodParams(String s, TransitionEdge edge, String arglist, String paramlist, String javaDoc) {
    return InThe.string(s).replace(//
        "methodName", edge.method.getSimpleName().toString(),//
        "arglist", arglist,//
        "paramlist", paramlist,//
        "toState", edge.targetState,
        "javaDoc",javaDoc);
  }

From this revision:

It would be nice if @Transition was changed to this:

@Retention(RetentionPolicy.SOURCE)
@Target(ElementType.METHOD)
public @interface Transition {
    String[] from() default "";
    String to() default "";
    String method() default ""; // Add this
    boolean end() default false;
}

When left empty, then the behaviour would be as today.

Currently, @AddTo just assumes that the target member can accept an .add(...) method call. This is not very versatile yet. For instance, I would like to be able to write these things:

    List<String> list = new ArrayList<>();

    @Transition(from = "A", to = "B")
    public abstract XXX from(@AddTo("list") String... elements);

    @Transition(from = "A", to = "B")
    public abstract XXX from(@AddTo("list") Collection<String> elements);

This is what the resulting generated methods would have to execute:

// First method:
list.addAll(java.util.Arrays.asList(elements));

// Second method:
list.addAll(elements);

Of course, it becomes clear that @AddTo, @AssignTo and similar annotations would have to be well conceived, to foresee many more cases like the above

I've made great experiences with Xtend as a templating engine for generating code:
http://www.eclipse.org/xtend/

I'm using it to generate all the row value expression related stuff in jOOQ, where similar code has to be duplicated, such as Record1, Record2, Record3, etc...

Do you see any potential in using it for fluflu?