feature: add fluent API for Launcher

[MartinWitt]

Showcase some code for discussion #1563 . There are still a lot of calls to the environment missing. It's only to showcase the idea.

[monperrus]

ohoh, welcome FluentLauncher!

[ghost]

Can this be private?

[MartinWitt]

yes 100%.

[ghost]

Does this need to follow the fluent interface idiom?

[MartinWitt]

yes needs to be changed.

[ghost]

How does a SpoonModelBuilder differ from the FluentLauncher? Conceptually, to me, they seem like they are trying to accomplish the same task: using a builder pattern to configure Spoon. Exposing both may lead to some confusion.

[MartinWitt]

The SpoonModelBuilder interface doesn't expose a fluent api.

[MartinWitt]

thank you for the review, but the code here is just a draft and far from even worth reading. There are still settings missing, unneeded methods and maybe it's possible to wrap all 3 launcher in the same class. Finding a better name is open too.

[surli]

Thanks for starting this @MartinWitt!
Quite frankly, I would use KISS a lot for this: the main purpose of proposing to create a fluent API was to ease using Spoon.

So I'd just start with some easy well-defined use cases and iterate over them in the launcher. So basically remove everything with the "needed" question, and everything's out of the scope of the usecases expressed in #1563. It should drastically reduce the size of the class.

The idea is to have a first launcher to fit 90% of usecases, for other option users will still have the old non-fluent API and we can improve it later to add ways to access those options.

[MartinWitt]

as @surli suggested, i made the api slim.
Supported operations:

• setting input resources(String, Iterable)
• adding processors(processor, Iterable)
• setting output directory(String, File)
• enabling autoImports
• disableConsistencyChecks
• setting compilanceLevel
• setting sourceClassPath
• activating noClasspath mode
• setting encoding

Are there any imported options someone is missing?
Incremental build and maven launcher could be supported, with creating a second constructor having a launcher type object as parameter. public FluentLauncher(Launcher launcher) , but would make the class more complex.

[surli]

Incremental build and maven launcher could be supported, with creating a second constructor having a launcher type object as parameter. public FluentLauncher(Launcher launcher) , but would make the class more complex.

I'm +1 to add a support for MavenLauncher since it's already an easy usecase for Spoon and it would show how to extend the capabilities of the FluentLauncher with another existing launcher.

[MartinWitt]

There were 2 options for adding the mavenlauncher.
Either copy all constructors with arguments(pretty bad) or creating a new constructor public FluentLauncher(Launcher launcher). The second option allows using new Launchers in the future and using the IncrementalLauncher too.
The testcases are only for showing how to use the FluentLauncher and should be removed afterwards. Is there any need to write real testcases for a wrapper class?

[monperrus]

Looks great, we just need a test case, the examples you had are great, could you add them back?

[surli]

That's really cool! +1 for a small unit test, could be done with a mock for the wrapped launcher.

[MartinWitt]

Maybe #3259 is not compatible with the spoon-control-flow code? The CI failure

[ERROR] /home/travis/build/INRIA/spoon/spoon-control-flow/src/main/java/fr/inria/controlflow/ControlFlowBuilder.java:[122,8] fr.inria.controlflow.ControlFlowBuilder is not abstract and does not override abstract method <T,S>visitCtSwitchExpression(spoon.reflect.code.CtSwitchExpression<T,S>) in spoon.reflect.visitor.CtVisitor

seems unrelated to this feature. See #3271 for potential fix.

[surli]

(just for info in case you don't know: you shouldn't need a commit to re-run the CI: triggering Travis from the UI is enough since it performs the build by merging changes with master each time)

[monperrus]

Thanks a lot @MartinWitt