You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Krzysztof Sobkowiak <kr...@gmail.com> on 2014/03/04 20:27:06 UTC
[DISCUSS] ServiceMix archetypes
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: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
Twitter: @KSobkowiak
Re: [DISCUSS] ServiceMix archetypes
Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
One clarification for point 2: Using the versioning scheme 5.2014.x 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.
On 04.03.2014 20:27, 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: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
> 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: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
Twitter: @KSobkowiak
Re: [DISCUSS] ServiceMix archetypes
Posted by Corrado Campisano <co...@gmail.com>.
+1
2014-03-06 20:37 GMT+01:00 Krzysztof Sobkowiak <kr...@gmail.com>:
> 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: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
>>> 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: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
> Twitter: @KSobkowiak
>
Re: [DISCUSS] ServiceMix archetypes
Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
Which groupId should be used?
1. org.apache.servicemix.tooling
2. org.apache.servicemix.archetypes
On 06.03.2014 20:37, Krzysztof Sobkowiak 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: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
Twitter: @KSobkowiak
Re: [DISCUSS] ServiceMix archetypes
Posted by Raul Kripalani <ra...@evosent.com>.
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 <
krzys.sobkowiak@gmail.com> 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: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
>>> 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: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
> Twitter: @KSobkowiak
>
Re: [DISCUSS] ServiceMix archetypes
Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
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: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
>> 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: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
Twitter: @KSobkowiak
Re: [DISCUSS] ServiceMix archetypes
Posted by Raul Kripalani <ra...@evosent.com>.
+1 for option 1.
Archetypes may be rendered broken or outdated as a result of version
upgrades of the individual components of SMX: Camel, CXF, etc.
Placing them within the SMX lifecycle itself creates the relationship that
"this archetype is valid for the version of components assembled in this
release of SMX".
*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 Tue, Mar 4, 2014 at 7:30 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>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: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
>> Twitter: @KSobkowiak
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: [DISCUSS] ServiceMix archetypes
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
> Twitter: @KSobkowiak
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [DISCUSS] ServiceMix archetypes
Posted by Gert Vanthienen <ge...@gmail.com>.
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
<kr...@gmail.com> 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: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
> Twitter: @KSobkowiak