I would add another level. After all, not all 'tools' are 'archetypes'. Tooling also includes plugins, scripts, Karaf commands, etc.
Therefore I propose org.apache.servicemix.tooling.archetypes as the groupId, which leaves the door open for: * org.apache.servicemix.tooling.commands * org.apache.servicemix.tooling.plugins * etc. *Raúl Kripalani* Apache Camel PMC Member & Committer | Enterprise Architect, Open Source Integration specialist ¡http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani http://blog.raulkr.net | twitter: @raulvk On Thu, Mar 6, 2014 at 7:37 PM, Krzysztof Sobkowiak < [email protected]> wrote: > 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 >
