Investigate supporting additional template types or variations

[bfitzpat]

As we begin to productize the camel generator it has become clear that we also need to figure out the simplest way to support multiple flavors of the same template. For example, a Fuse-ified spring-boot template as well as a standalone one.

Need to investigate what that means as far as the changes between poms.

[bfitzpat]

Currently in each template you will find a pom.xml and a pom.xml.wsdl2rest variant. I am investigating what it would take to simply add a "fuse" variant for each to keep the bulk of the templates intact and only vary what artifacts we actually pull in for a particular template at runtime.

If I can achieve that, then the majority of the template remains the same and we just use the right pom for the various configuration combinations... i.e. Spring, Spring + wsdl2rest, Spring/Fuse, Spring/Fuse + wsdl2rest, etc.

[bfitzpat]

The obvious problem with this approach is that you end up with a multitude of pom.xml variants in each template. So I'm testing with this. The question becomes... if this works, is it better to have these various poms we will have to keep in sync? Or is there a better way for us to modularize these templated pom files? --

[bfitzpat]

Created a PR here (#46) that includes working versions of spring, blueprint, and java templates for both camel and fuse (on a very happy path) with and without wsdl2rest.

Happy path:

> yo camel-project --fuse

[follow prompts, but use 7.1.0.fuse-710019-redhat-00002 as the version for now]

This works for Spring, Blueprint, and Java templates at present. I need some help tweaking the spring-boot template for use with a fuse spring boot BOM, so hopefully I can pick @apupier 's brain and get that functional.

My goal was to use this PR as a discussion point and show the basic approach I wanted to implement. This is the most minimal approach I have come up with, modifying just the pom.xml for the various flavors of the template we want (camel, fuse, camel+wsdl2rest, fuse+wsdl2rest). It works on this minimal set of templates just fine, but will require manual adjustments when versions change.

[bfitzpat]

So now I need to determine what to do with prompting. I don't think the "--fuse" flag is really what we want to go with. :)

Right now we prompt for:

• Camel project name (defaulting to the directory in which the generator is run)
• Camel version
• DSL type (blueprint, spring, spring-boot, or java)
• package name (defaults to "com." + directory name)

I am wondering if we simply change the second prompt to a cascade that offers different defaults.

Something like:

$ yo camel-project --fuse
     _                             _
    / \     _ __     __ _    ___  | |__     ___
   / _ \   | '_ \   / _` |  / __| | '_ \   / _ \
  / ___ \  | |_) | | (_| | | (__  | | | | |  __/
 /_/   \_\ | .__/   \__,_|  \___| |_| |_|  \___|
           |_|
       ____                              _
     /  ___|   __ _   _ __ ___     ___  | |
    |  |      / _` | | '_ ` _ \   / _ \ | |
    |  |___  | (_| | | | | | | | |  __/ | |
     \____|   \__,_| |_| |_| |_|  \___| |_|
 -----------------------------------------------
            Camel Project Generator
                 Version: 0.2.0
 -----------------------------------------------

? Your Camel project name demo
? Use a Camel community version or a Red Hat Fuse version? Camel/Fuse
  ? Your Fuse version? 7.1.0.fuse-710019-redhat-00002
? Camel DSL type (blueprint, spring, spring-boot, or java) spring
? Package name:  com.demo
Creating folders
Copying files
   create pom.xml
   create README.md
   create src\main\resources\META-INF\spring\camel-context.xml

We should be able to still use command line arguments to pass appropriate values to do either, but it's good to give the user a simple choice. Like before, we can provide a default version (2.22.2 for Camel or a supported Fuse version like https://github.com/jbosstools/jbosstools-fuse/blob/master/configuration/camel2bom.fuse71.properties ) and update those defaults (including the Fuse/Camel choice and any versions specified) for later usage.

What do you think?

[apupier]

Or is there a better way for us to modularize these templated pom files?

The best is to not have any templates embedded and rely only on quickstarts and boosters provided by Fuse Runtime team.

[apupier]

We should be able to still use command line arguments to pass appropriate values to do either, but it's good to give the user a simple choice. Like before, we can provide a default version (2.22.2 for Camel or a supported Fuse version like https://github.com/jbosstools/jbosstools-fuse/blob/master/configuration/camel2bom.fuse71.properties ) and update those defaults (including the Fuse/Camel choice and any versions specified) for later usage.

What do you think?

when proposing a Camel productized version, you need to mention the Fuse version as it is done in Eclipse Fuse Tooling wizard. Otherwise, it is too boring for users to know which version of Camel they need to take.

I think a conditional flow is better when we want to provide the choice of versions between Camel Community and Fuse versions.
Is yeoman and vs code yeoman supporting conditional flows? (to have one Camel/Fuse to choose then the camel version or the Fuse version)

[apupier]

It works on this minimal set of templates just fine, but will require manual adjustments when versions change.

This manual adjustments when versions changes, even if currently restricted to pom.xml, will become a part of a lot of maintenance burden. We will also have to introduce the mechanism to select templates based on the version.