Make the quickstarts independent of which Camel version they are using

[davsclaus]

So end users are not stuck on what version that may be in the fabric8 bom.

IMHO really fabric8 bom should not have any AMQ/Camel/CXF dependency etc. But really let end user pick and chose what they want to use.

[jimmidyson]

👍

[davsclaus]

This requires the archetype-builder to allow to put in version placeholders in the generate archetypes

[davsclaus]

Almost though I got it covered then the generated mvn archetype may have a name clash, so the user entered version is not inserted into the generated pom.xml

[davsclaus]

Darn in some mvn archetype hell where it wont pickup my latest changes, but it looks like the placeholders are all in place. So just trying with a trashed local m2 repo.

[davsclaus]

Yay the maven archetype catalog is a bit of a mess to control. But with a trashed m2 I only have my local stuff now, and I was able to generate a project and specify Camel 2.16.0 instead of the default 2.16.1

 <!-- configure the versions you want to use here -->
    <camel.version>2.16.0</camel.version>
    <weld.version>2.3.1.Final</weld.version>

To generate local use

mvn archetype:generate -DarchetypeCatalog=local

[davsclaus]

Next release of fabric8 has the needed change in the archetype builder that these quickstarts uses, but then we can choose our Camel / ActiveMQ / spring-boot versions and so on.

[dhirajsb]

@davsclaus actually productization guideline was to put dependency versions in parent fabric8 BOM so that users don't have to specify versions explicitly. The redhat branch only needed versions for plugins, which don't inherit from imported poms, afaik.

[davsclaus]

yes but this is upstream, we want to be free and let people chose their bits