Re: [DISCUSS] ServiceMix features

[Krzysztof Sobkowiak <kr...@gmail.com>]

I would suggest 'internal' instead of 'overrides'. The features 
repository should contain not only the overrides but also servicemix 
features which are not intended to be installed in other distributions, 
e.g. any servicemix specific commands or configurations

On 24.02.2014 22:10, Gert Vanthienen wrote:
> Hi Krzysztof,
>
>
> Yeah, if we have to add those kinds of overrides again, it would
> definitely make sense to move those into a separate file as well.
> Looks like we still have one such feature around with the jax-rs
> feature in that file (not sure that one is still required though).
> Perhaps we should call that feature 'overrides' or something like that
> to clarify what it does?
>
>
> Regards,
>
> Gert Vanthienen
>
>
> On Mon, Feb 24, 2014 at 9:53 PM, Krzysztof Sobkowiak
> <kr...@gmail.com> wrote:
>> Hi Gert
>>
>> Yes, my proposal is to split the features. Probably now we have nothing what
>> could be placed in core features, but I give you an example. Some weeks ago
>> we had some activemq features overwritten in servicemix features. If I want
>> to include servicemix features in my distribution or include them in vanilla
>> Karaf, I want to have such features like Activiti or Akka, not overwritten
>> ActiveMQ features. I'll probably use another version of ActiveMQ. The
>> overwritten ActiveMQ features were very servicemix specific. The purpose of
>> core features is a place for such features which are necessary tobuild the
>> servicemix distribution and could make problems if they were included in the
>> "public" features. We can live with one features file (+ separate file for
>> examples). But when we need to define in the future some features like these
>> for ActiveMQ, they must be placed in separate file.
>>
>> Best regards
>> Krzysztof
>>
>>
>>
>> On 24.02.2014 21:01, Gert Vanthienen wrote:
>>> Hi Krzysztof,
>>>
>>>
>>> So, just to be clear, the proposal is to split up what we have in
>>> assemblies/src/main/filtered-resources/features.xml into multiple
>>> features descriptor (cfr.
>>>
>>> http://svn.apache.org/viewvc/servicemix/smx5/trunk/assemblies/src/main/filtered-resources/features.xml?view=markup),
>>> right?
>>>
>>> Not sure how you would discriminate between the first two things
>>> you're proposing - shouldn't any feature we build be installable on
>>> another Karaf distribution anyway?  Perhaps we can just keep those two
>>> together for now: if I look at the current features.xml file, it could
>>> contain everything that doesn't start with example-*.  How about just
>>> keeping the name for that one the same as it is right now?
>>> apache-servicemix-<version>-features.xml seems to match the pattern
>>> that other projects use for their descriptor pretty well already.
>>>
>>> If we want, we can definitely move the examples into a separate
>>> features files.  It would make it easier for people to add the Apache
>>> ServiceMix features to their distribution without introducing the
>>> examples (which they're probably not interested in in that scenario
>>> anyways).  So I'm +1 for moving those features apart, perhaps we can
>>> just attach it with another classifier,
>>> apache-servicemix-<version>-examples.xml perhaps?
>>>
>>> In my mind, we can best do that right now in the ServiceMix 5 codebase
>>> as well.  I assume we want to branch that off into a Karaf 3.x based
>>> ServiceMix 6 line pretty soon anyway, so the more of these changes we
>>> do now, the more these two lines of code are alike and the easier we
>>> will make it for ourselves to merge changes back and forth afterwards.
>>>
>>>
>>> Regards,
>>>
>>> Gert Vanthienen
>>>
>>>
>>> On Fri, Feb 21, 2014 at 8:33 PM, Krzysztof Sobkowiak
>>> <kr...@gmail.com> wrote:
>>>> Hi
>>>>
>>>> In the discussions about the ServiceMix future and the future of
>>>> ServiceMix
>>>> features it was mentioned about moving some non-core features into the
>>>> Karaf
>>>> Enterprise Features subproject. Another people think, the Karaf
>>>> subproject
>>>> is not too good place for such features like Activiti. Such features
>>>> could
>>>> be also extracted into a separate subproject in ServiceMix which could
>>>> have
>>>> a separate lifecycle, but we don't have too many such features to create
>>>> a
>>>> subproject for them.
>>>>
>>>> In the code base for ServiceMix 6 (working version for the Karaf 3.x line
>>>> as
>>>> not decided yet which version will have the SMX based on Karaf 3.x) I'd
>>>> like
>>>> to prepare 3 feature repositories
>>>>
>>>>    * servicemix-core - core features which will be integral part of
>>>>      servicemix, not installable on other Karaf distributions
>>>>    * servicemix-esb - non-core features like current Activiti integration
>>>>      or missing connection factory for ActiveMQ. This repository should
>>>>      provide features which will be used to build the ServiceMix
>>>>      distribution and which can be also used outside the ServiceMix
>>>>      distribution, e.g. in Karaf. It should have no dependency to core
>>>>      ServiceMix. Currently we have not too many such features and some of
>>>>      them could be moved into the original project or into the Karaf
>>>>      Enterprise Features subproject (but id doesn't exist yet and many
>>>>      people doesn't like the idea for moving the esb specific features
>>>>      into Karaf). In the future we can have more esb features and we can
>>>>      extract a separate subproject having own lifecycle,
>>>>    * servicemix-examples - I think, the examples should be separated from
>>>>      other features
>>>>
>>>> What do you think about this idea?
>>>>
>>>> Best regards and have a nice weekend
>>>> 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 features

[Gert Vanthienen <ge...@gmail.com>]

L.S.,


Yeah, that sounds better (less hacky ;)) - I raised
https://issues.apache.org/jira/browse/SM-2262 to keep track of that
change.


Regards,

Gert


On Tue, Mar 4, 2014 at 10:08 PM, Krzysztof Sobkowiak
<kr...@gmail.com> wrote:
> I would suggest 'internal' instead of 'overrides'. The features repository
> should contain not only the overrides but also servicemix features which are
> not intended to be installed in other distributions, e.g. any servicemix
> specific commands or configurations
>
>
> On 24.02.2014 22:10, Gert Vanthienen wrote:
>>
>> Hi Krzysztof,
>>
>>
>> Yeah, if we have to add those kinds of overrides again, it would
>> definitely make sense to move those into a separate file as well.
>> Looks like we still have one such feature around with the jax-rs
>> feature in that file (not sure that one is still required though).
>> Perhaps we should call that feature 'overrides' or something like that
>> to clarify what it does?
>>
>>
>> Regards,
>>
>> Gert Vanthienen
>>
>>
>> On Mon, Feb 24, 2014 at 9:53 PM, Krzysztof Sobkowiak
>> <kr...@gmail.com> wrote:
>>>
>>> Hi Gert
>>>
>>> Yes, my proposal is to split the features. Probably now we have nothing
>>> what
>>> could be placed in core features, but I give you an example. Some weeks
>>> ago
>>> we had some activemq features overwritten in servicemix features. If I
>>> want
>>> to include servicemix features in my distribution or include them in
>>> vanilla
>>> Karaf, I want to have such features like Activiti or Akka, not
>>> overwritten
>>> ActiveMQ features. I'll probably use another version of ActiveMQ. The
>>> overwritten ActiveMQ features were very servicemix specific. The purpose
>>> of
>>> core features is a place for such features which are necessary tobuild
>>> the
>>> servicemix distribution and could make problems if they were included in
>>> the
>>> "public" features. We can live with one features file (+ separate file
>>> for
>>> examples). But when we need to define in the future some features like
>>> these
>>> for ActiveMQ, they must be placed in separate file.
>>>
>>> Best regards
>>> Krzysztof
>>>
>>>
>>>
>>> On 24.02.2014 21:01, Gert Vanthienen wrote:
>>>>
>>>> Hi Krzysztof,
>>>>
>>>>
>>>> So, just to be clear, the proposal is to split up what we have in
>>>> assemblies/src/main/filtered-resources/features.xml into multiple
>>>> features descriptor (cfr.
>>>>
>>>>
>>>> http://svn.apache.org/viewvc/servicemix/smx5/trunk/assemblies/src/main/filtered-resources/features.xml?view=markup),
>>>> right?
>>>>
>>>> Not sure how you would discriminate between the first two things
>>>> you're proposing - shouldn't any feature we build be installable on
>>>> another Karaf distribution anyway?  Perhaps we can just keep those two
>>>> together for now: if I look at the current features.xml file, it could
>>>> contain everything that doesn't start with example-*.  How about just
>>>> keeping the name for that one the same as it is right now?
>>>> apache-servicemix-<version>-features.xml seems to match the pattern
>>>> that other projects use for their descriptor pretty well already.
>>>>
>>>> If we want, we can definitely move the examples into a separate
>>>> features files.  It would make it easier for people to add the Apache
>>>> ServiceMix features to their distribution without introducing the
>>>> examples (which they're probably not interested in in that scenario
>>>> anyways).  So I'm +1 for moving those features apart, perhaps we can
>>>> just attach it with another classifier,
>>>> apache-servicemix-<version>-examples.xml perhaps?
>>>>
>>>> In my mind, we can best do that right now in the ServiceMix 5 codebase
>>>> as well.  I assume we want to branch that off into a Karaf 3.x based
>>>> ServiceMix 6 line pretty soon anyway, so the more of these changes we
>>>> do now, the more these two lines of code are alike and the easier we
>>>> will make it for ourselves to merge changes back and forth afterwards.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Gert Vanthienen
>>>>
>>>>
>>>> On Fri, Feb 21, 2014 at 8:33 PM, Krzysztof Sobkowiak
>>>> <kr...@gmail.com> wrote:
>>>>>
>>>>> Hi
>>>>>
>>>>> In the discussions about the ServiceMix future and the future of
>>>>> ServiceMix
>>>>> features it was mentioned about moving some non-core features into the
>>>>> Karaf
>>>>> Enterprise Features subproject. Another people think, the Karaf
>>>>> subproject
>>>>> is not too good place for such features like Activiti. Such features
>>>>> could
>>>>> be also extracted into a separate subproject in ServiceMix which could
>>>>> have
>>>>> a separate lifecycle, but we don't have too many such features to
>>>>> create
>>>>> a
>>>>> subproject for them.
>>>>>
>>>>> In the code base for ServiceMix 6 (working version for the Karaf 3.x
>>>>> line
>>>>> as
>>>>> not decided yet which version will have the SMX based on Karaf 3.x) I'd
>>>>> like
>>>>> to prepare 3 feature repositories
>>>>>
>>>>>    * servicemix-core - core features which will be integral part of
>>>>>      servicemix, not installable on other Karaf distributions
>>>>>    * servicemix-esb - non-core features like current Activiti
>>>>> integration
>>>>>      or missing connection factory for ActiveMQ. This repository should
>>>>>      provide features which will be used to build the ServiceMix
>>>>>      distribution and which can be also used outside the ServiceMix
>>>>>      distribution, e.g. in Karaf. It should have no dependency to core
>>>>>      ServiceMix. Currently we have not too many such features and some
>>>>> of
>>>>>      them could be moved into the original project or into the Karaf
>>>>>      Enterprise Features subproject (but id doesn't exist yet and many
>>>>>      people doesn't like the idea for moving the esb specific features
>>>>>      into Karaf). In the future we can have more esb features and we
>>>>> can
>>>>>      extract a separate subproject having own lifecycle,
>>>>>    * servicemix-examples - I think, the examples should be separated
>>>>> from
>>>>>      other features
>>>>>
>>>>> What do you think about this idea?
>>>>>
>>>>> Best regards and have a nice weekend
>>>>> 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