L.S.,
Yeah, I agree adding the archetypes into the ServiceMix 5 codebase would be the easiest to maintain - even if nothing has changed to the archetypes, it does ensure that all versions for dependencies are neatly aligned. For the group id, I think I prefer the simpler "org.apache.servicemix.archetypes" one. Regards, Gert Vanthienen On Tue, Mar 4, 2014 at 8:27 PM, Krzysztof Sobkowiak <[email protected]> wrote: > 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
