Hi all

Currently the archetypes are provided by a separate repository servicemix-archetypes. There are many archetypes for features no more supported in ServiceMix 5 (e.g. jbi). I don't know whether the other archetypes (e.g. jaxws wsdl first or code first) are compatible with the actual state in ServiceMix 5.

I think, we should provide a set of archetypes which are compatible with ServiceMix 5 (and later a set of archetypes compatible with ServiceMix 6). For this purpose we need a separate versioning of archetypes for ServiceMix 4, 5, ... I think the best way would be the same version like ServiceMix version - the user could use the archetype version 5.0.0 and could be sure the archetype generates a project compatible with ServiceMix 5.0.0 (similar to Karaf or Fabric8 archetypes).

I'd like to propose 2 solutions:

 * merge the archetypes (only the subset) into ServiceMix 5 code base -
   the archetypes would have the same life cycle like ServiceMix. Each
   ServiceMix would provide the set of archetypes for features
   available in the given version. This solution would generate a new
   archetypes for each ServiceMix release, even if nothing changes in
   the archetypes between the releases but this solution woul make the
   archetype usage easier - user would take the archetype version x for
   ServiceMix release x.
 * move the current archetypes in servicemix-archetypes repository into
   a separate branch and provide the ServiceMix 5 archetypes on trunk.
   We should also change the versioning on the trunk - I prefer the
   same version like the version of ServiceMix (in this case 5.0.0) pr
   something like 5.2014.x for SMX 5, 6.2014.x for SMX 6,.... to
   preserve the versioning scheme used currently and distinguish
   between the major ServiceMix releases. Using this solution we could
   release new archetypes only if something will be changed, but it
   will be difficult to find a version which is proper for the given
   ServiceMix version.

I prefer the first solution. What is your opinion?

Best regards
Krzysztof



--
Krzysztof Sobkowiak

JEE & OSS Architect | Technical Architect @ Capgemini
Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center <http://www.pl.capgemini-sdm.com/> | Wroclaw e-mail: [email protected] <mailto:[email protected]> | Twitter: @KSobkowiak

Reply via email to