+1
2014-03-06 20:37 GMT+01:00 Krzysztof Sobkowiak <[email protected]>: > Hi > > The archetypes form servicemix-archetypes have groupId > org.apache.servicemix.tooling. Should the archetypes in servicemix5 have > the same groupId or org.apache.servicemix.archetypes? > > Best regards > Krzysztof > > On 04.03.2014 20:30, Jean-Baptiste Onofré wrote: > >> Hi, >> >> +1 for point 1 (even if the archetypes are not really tight to a >> ServiceMix version). >> >> Regards >> JB >> >> On 03/04/2014 08:27 PM, Krzysztof Sobkowiak 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 >>> >>> >> > > -- > 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 >
