Quantcast

Re: 3rd Party Feature Definitions

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3rd Party Feature Definitions

Andreas Pieber
ah, and last but not least: we might want this discussion to be held
on the dev list.

Kind regards,
Andreas

On Thu, Oct 11, 2012 at 7:13 PM, Andreas Pieber <[hidden email]> wrote:

> OK, now that I finally found my way through the original thread
> causing this discussion I'm even stronger +1 for this topic than
> before.
>
> Get out everything out of the core release which is not started by
> default in the default apache-karaf distribution.
>
> To make things easy for us we might pack all those other features and
> commands and so on into a single release structure to make it easy for
> us which is quite roughly compatible to karaf core 2.x.y(.z) for Karaf
> 2 compatible plugins and 3.x.y(.z) for Karaf 3 compatible extensions.
> This should make the vote & the release process easy enough for us AND
> since we can version the features independently of the full release
> versions the user can still mix them as he sees fit.
>
> Just something else to get the discussion about this going :-)
>
> Kind regards,
> Andreas
>
> On Thu, Oct 11, 2012 at 6:54 PM, Andreas Pieber <[hidden email]> wrote:
>> Well, IIRC we've discussed this already on IRC some time ago about
>> that. One the main problems by this was that we need to release all of
>> those separately; which adds quite some work.
>>
>> But basically I'm with you. It's a PITA with those spring & aries
>> enterprise feature upgrades and that we have to wait for them. IMHO we
>> should really re-discuss this issue again; to move anything not
>> required into different features. Thanks to Christians searchurl
>> feature we could still make it pretty easy for ppl to add them
>> afterwards if they like. This wouldn't make too much difference to how
>> we're handling it right now anyhow...
>>
>> WDYT?
>>
>> Kind regards,
>> Andreas
>>
>> On Tue, Oct 9, 2012 at 11:19 PM, Scott England-Sullivan
>> <[hidden email]> wrote:
>>> Hi all,
>>>
>>> In a recent thread on the development list there was a discussion
>>> regarding the release of Karaf 2.3.0 and the possibility of holding it
>>> up to accommodate an update to Spring 3.1.  It struck me; why is Karaf
>>> tied to a 3rd party release at all?  Why isn't the modular container
>>> itself modular?  Why aren't 3rd party support modules such as Spring
>>> deployers externalized and allowed to progress at their own pace?
>>> Third party dependent modules should be developed against a given
>>> release of Karaf, they shouldn't drive it.  There is a new
>>> karaf-webconsole project so the precedence is there.
>>>
>>> Karaf is a great, light-weight container which put a nice manageable
>>> wrapper on OSGi with a great CLI, ConfigAdmin, provisioning, etc., and
>>> IMHO should stay focused on just that at its core.  The capabilities
>>> that are tied to simplifying 3rd party support are goodness but not
>>> required and as such, shouldn't drive the cores development.
>>>
>>> Now maybe you really can't separate one from the other though I don't
>>> see where it is tightly coupled at.  I also understand it is a greater
>>> challenge to manage because the project become fractured but maybe
>>> Karaf is at that point.
>>>
>>> In reality I am good either way but thought it was worth discussing.
>>>
>>> Best Regards,
>>> Scott ES
>>>
>>> --
>>> --
>>> Scott England-Sullivan
>>> Apache Camel Committer
>>> Principal Consultant / Sr. Architect | Red Hat, Inc.
>>> FuseSource is now part of Red Hat
>>> Web:     fusesource.com | redhat.com
>>> Blog:     sully6768.blogspot.com
>>> Twitter: sully6768
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3rd Party Feature Definitions

sully6768
Moving to Dev.

On Oct 11, 2012, at 12:14 PM, Andreas Pieber <[hidden email]> wrote:

> ah, and last but not least: we might want this discussion to be held
> on the dev list.
>
> Kind regards,
> Andreas
>
> On Thu, Oct 11, 2012 at 7:13 PM, Andreas Pieber <[hidden email]> wrote:
>> OK, now that I finally found my way through the original thread
>> causing this discussion I'm even stronger +1 for this topic than
>> before.
>>
>> Get out everything out of the core release which is not started by
>> default in the default apache-karaf distribution.
>>
>> To make things easy for us we might pack all those other features and
>> commands and so on into a single release structure to make it easy for
>> us which is quite roughly compatible to karaf core 2.x.y(.z) for Karaf
>> 2 compatible plugins and 3.x.y(.z) for Karaf 3 compatible extensions.
>> This should make the vote & the release process easy enough for us AND
>> since we can version the features independently of the full release
>> versions the user can still mix them as he sees fit.
>>
>> Just something else to get the discussion about this going :-)
>>
>> Kind regards,
>> Andreas
>>
>> On Thu, Oct 11, 2012 at 6:54 PM, Andreas Pieber <[hidden email]> wrote:
>>> Well, IIRC we've discussed this already on IRC some time ago about
>>> that. One the main problems by this was that we need to release all of
>>> those separately; which adds quite some work.
>>>
>>> But basically I'm with you. It's a PITA with those spring & aries
>>> enterprise feature upgrades and that we have to wait for them. IMHO we
>>> should really re-discuss this issue again; to move anything not
>>> required into different features. Thanks to Christians searchurl
>>> feature we could still make it pretty easy for ppl to add them
>>> afterwards if they like. This wouldn't make too much difference to how
>>> we're handling it right now anyhow...
>>>
>>> WDYT?
>>>
>>> Kind regards,
>>> Andreas
>>>
>>> On Tue, Oct 9, 2012 at 11:19 PM, Scott England-Sullivan
>>> <[hidden email]> wrote:
>>>> Hi all,
>>>>
>>>> In a recent thread on the development list there was a discussion
>>>> regarding the release of Karaf 2.3.0 and the possibility of holding it
>>>> up to accommodate an update to Spring 3.1.  It struck me; why is Karaf
>>>> tied to a 3rd party release at all?  Why isn't the modular container
>>>> itself modular?  Why aren't 3rd party support modules such as Spring
>>>> deployers externalized and allowed to progress at their own pace?
>>>> Third party dependent modules should be developed against a given
>>>> release of Karaf, they shouldn't drive it.  There is a new
>>>> karaf-webconsole project so the precedence is there.
>>>>
>>>> Karaf is a great, light-weight container which put a nice manageable
>>>> wrapper on OSGi with a great CLI, ConfigAdmin, provisioning, etc., and
>>>> IMHO should stay focused on just that at its core.  The capabilities
>>>> that are tied to simplifying 3rd party support are goodness but not
>>>> required and as such, shouldn't drive the cores development.
>>>>
>>>> Now maybe you really can't separate one from the other though I don't
>>>> see where it is tightly coupled at.  I also understand it is a greater
>>>> challenge to manage because the project become fractured but maybe
>>>> Karaf is at that point.
>>>>
>>>> In reality I am good either way but thought it was worth discussing.
>>>>
>>>> Best Regards,
>>>> Scott ES
>>>>
>>>> --
>>>> --
>>>> Scott England-Sullivan
>>>> Apache Camel Committer
>>>> Principal Consultant / Sr. Architect | Red Hat, Inc.
>>>> FuseSource is now part of Red Hat
>>>> Web:     fusesource.com | redhat.com
>>>> Blog:     sully6768.blogspot.com
>>>> Twitter: sully6768
--
Scott England-Sullivan
----------------------------------
FuseSource
Web:     http://www.fusesource.com
Blog:     http://sully6768.blogspot.com
Twitter: sully6768
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3rd Party Feature Definitions

sully6768
For those just joining us, the original thread was:
http://karaf.922171.n3.nabble.com/Apache-Karaf-2-3-0-very-close-td4026295.html

That sounds like a good solution.  One question though.  If you move
all the Karaf compatible "extensions" to a sub-group, wouldn't you
still encounter the same type of hold up?  For example, holding up an
Aries enterprise release with a critical bug fix due to ongoing
integration of a new Spring release.

> On Oct 11, 2012, at 12:14 PM, Andreas Pieber <[hidden email]> wrote:
>
>> ah, and last but not least: we might want this discussion to be held
>> on the dev list.
>>
>> Kind regards,
>> Andreas
>>
>> On Thu, Oct 11, 2012 at 7:13 PM, Andreas Pieber <[hidden email]> wrote:
>>> OK, now that I finally found my way through the original thread
>>> causing this discussion I'm even stronger +1 for this topic than
>>> before.
>>>
>>> Get out everything out of the core release which is not started by
>>> default in the default apache-karaf distribution.
>>>
>>> To make things easy for us we might pack all those other features and
>>> commands and so on into a single release structure to make it easy for
>>> us which is quite roughly compatible to karaf core 2.x.y(.z) for Karaf
>>> 2 compatible plugins and 3.x.y(.z) for Karaf 3 compatible extensions.
>>> This should make the vote & the release process easy enough for us AND
>>> since we can version the features independently of the full release
>>> versions the user can still mix them as he sees fit.
>>>
>>> Just something else to get the discussion about this going :-)
>>>
>>> Kind regards,
>>> Andreas
>>>
>>> On Thu, Oct 11, 2012 at 6:54 PM, Andreas Pieber <[hidden email]> wrote:
>>>> Well, IIRC we've discussed this already on IRC some time ago about
>>>> that. One the main problems by this was that we need to release all of
>>>> those separately; which adds quite some work.
>>>>
>>>> But basically I'm with you. It's a PITA with those spring & aries
>>>> enterprise feature upgrades and that we have to wait for them. IMHO we
>>>> should really re-discuss this issue again; to move anything not
>>>> required into different features. Thanks to Christians searchurl
>>>> feature we could still make it pretty easy for ppl to add them
>>>> afterwards if they like. This wouldn't make too much difference to how
>>>> we're handling it right now anyhow...
>>>>
>>>> WDYT?
>>>>
>>>> Kind regards,
>>>> Andreas
>>>>
>>>> On Tue, Oct 9, 2012 at 11:19 PM, Scott England-Sullivan
>>>> <[hidden email]> wrote:
>>>>> Hi all,
>>>>>
>>>>> In a recent thread on the development list there was a discussion
>>>>> regarding the release of Karaf 2.3.0 and the possibility of holding it
>>>>> up to accommodate an update to Spring 3.1.  It struck me; why is Karaf
>>>>> tied to a 3rd party release at all?  Why isn't the modular container
>>>>> itself modular?  Why aren't 3rd party support modules such as Spring
>>>>> deployers externalized and allowed to progress at their own pace?
>>>>> Third party dependent modules should be developed against a given
>>>>> release of Karaf, they shouldn't drive it.  There is a new
>>>>> karaf-webconsole project so the precedence is there.
>>>>>
>>>>> Karaf is a great, light-weight container which put a nice manageable
>>>>> wrapper on OSGi with a great CLI, ConfigAdmin, provisioning, etc., and
>>>>> IMHO should stay focused on just that at its core.  The capabilities
>>>>> that are tied to simplifying 3rd party support are goodness but not
>>>>> required and as such, shouldn't drive the cores development.
>>>>>
>>>>> Now maybe you really can't separate one from the other though I don't
>>>>> see where it is tightly coupled at.  I also understand it is a greater
>>>>> challenge to manage because the project become fractured but maybe
>>>>> Karaf is at that point.
>>>>>
>>>>> In reality I am good either way but thought it was worth discussing.
>>>>>
>>>>> Best Regards,
>>>>> Scott ES
>>>>>
>>>>> --
>>>>> --
>>>>> Scott England-Sullivan
>>>>> Apache Camel Committer
>>>>> Principal Consultant / Sr. Architect | Red Hat, Inc.
>>>>> FuseSource is now part of Red Hat
>>>>> Web:     fusesource.com | redhat.com
>>>>> Blog:     sully6768.blogspot.com
>>>>> Twitter: sully6768

-
Scott England-Sullivan
Apache Camel Committer
http://sully6768.blogspot.com
--
Scott England-Sullivan
----------------------------------
FuseSource
Web:     http://www.fusesource.com
Blog:     http://sully6768.blogspot.com
Twitter: sully6768
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3rd Party Feature Definitions

Achim Nierbeck
Yeah, I remember all those discussions about this topic also ...

... (dreaming of a perfect world)
Aries and all the other depending projects produce features.xml artifacts ...
(dream is over)

unfortunately almost all non karaf-related projects produce feature files,
therefore we have to take care of it then.
I'm not sure about the proposed artifacts beeing coupled to tight to
karaf release
schedule (Andreas' idea of 3.x.y for Karaf 3.x version)
I'd rather not do this, cause it just wouldn't help much on the issue.

We should try to get those needed features either into the Projects
where we do have some influence, like aries, pax-web (I'm actually working on
this to decouple this stuff ;) ) and for all the others like spring
we might just need something similar to what servicemix got for the
osgi-fied bundles.

So lets take the spring features.xml as the reference sample (since it
did get this stuff started).

<features name="spring-2.5.6">
    <feature name="spring-core" version="2.5.6">
    ....
</features>

and the maven artifact could be something like the following:

    <groupId>org.apache.karaf.features</groupId>
    <artifactId>spring-2.5.6</artifactId>
    <version>1.0.1</version>


for the other spring versions basically the same.

regards, Achim


2012/10/11 Scott England-Sullivan <[hidden email]>:

> For those just joining us, the original thread was:
> http://karaf.922171.n3.nabble.com/Apache-Karaf-2-3-0-very-close-td4026295.html
>
> That sounds like a good solution.  One question though.  If you move
> all the Karaf compatible "extensions" to a sub-group, wouldn't you
> still encounter the same type of hold up?  For example, holding up an
> Aries enterprise release with a critical bug fix due to ongoing
> integration of a new Spring release.
>
>> On Oct 11, 2012, at 12:14 PM, Andreas Pieber <[hidden email]> wrote:
>>
>>> ah, and last but not least: we might want this discussion to be held
>>> on the dev list.
>>>
>>> Kind regards,
>>> Andreas
>>>
>>> On Thu, Oct 11, 2012 at 7:13 PM, Andreas Pieber <[hidden email]> wrote:
>>>> OK, now that I finally found my way through the original thread
>>>> causing this discussion I'm even stronger +1 for this topic than
>>>> before.
>>>>
>>>> Get out everything out of the core release which is not started by
>>>> default in the default apache-karaf distribution.
>>>>
>>>> To make things easy for us we might pack all those other features and
>>>> commands and so on into a single release structure to make it easy for
>>>> us which is quite roughly compatible to karaf core 2.x.y(.z) for Karaf
>>>> 2 compatible plugins and 3.x.y(.z) for Karaf 3 compatible extensions.
>>>> This should make the vote & the release process easy enough for us AND
>>>> since we can version the features independently of the full release
>>>> versions the user can still mix them as he sees fit.
>>>>
>>>> Just something else to get the discussion about this going :-)
>>>>
>>>> Kind regards,
>>>> Andreas
>>>>
>>>> On Thu, Oct 11, 2012 at 6:54 PM, Andreas Pieber <[hidden email]> wrote:
>>>>> Well, IIRC we've discussed this already on IRC some time ago about
>>>>> that. One the main problems by this was that we need to release all of
>>>>> those separately; which adds quite some work.
>>>>>
>>>>> But basically I'm with you. It's a PITA with those spring & aries
>>>>> enterprise feature upgrades and that we have to wait for them. IMHO we
>>>>> should really re-discuss this issue again; to move anything not
>>>>> required into different features. Thanks to Christians searchurl
>>>>> feature we could still make it pretty easy for ppl to add them
>>>>> afterwards if they like. This wouldn't make too much difference to how
>>>>> we're handling it right now anyhow...
>>>>>
>>>>> WDYT?
>>>>>
>>>>> Kind regards,
>>>>> Andreas
>>>>>
>>>>> On Tue, Oct 9, 2012 at 11:19 PM, Scott England-Sullivan
>>>>> <[hidden email]> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> In a recent thread on the development list there was a discussion
>>>>>> regarding the release of Karaf 2.3.0 and the possibility of holding it
>>>>>> up to accommodate an update to Spring 3.1.  It struck me; why is Karaf
>>>>>> tied to a 3rd party release at all?  Why isn't the modular container
>>>>>> itself modular?  Why aren't 3rd party support modules such as Spring
>>>>>> deployers externalized and allowed to progress at their own pace?
>>>>>> Third party dependent modules should be developed against a given
>>>>>> release of Karaf, they shouldn't drive it.  There is a new
>>>>>> karaf-webconsole project so the precedence is there.
>>>>>>
>>>>>> Karaf is a great, light-weight container which put a nice manageable
>>>>>> wrapper on OSGi with a great CLI, ConfigAdmin, provisioning, etc., and
>>>>>> IMHO should stay focused on just that at its core.  The capabilities
>>>>>> that are tied to simplifying 3rd party support are goodness but not
>>>>>> required and as such, shouldn't drive the cores development.
>>>>>>
>>>>>> Now maybe you really can't separate one from the other though I don't
>>>>>> see where it is tightly coupled at.  I also understand it is a greater
>>>>>> challenge to manage because the project become fractured but maybe
>>>>>> Karaf is at that point.
>>>>>>
>>>>>> In reality I am good either way but thought it was worth discussing.
>>>>>>
>>>>>> Best Regards,
>>>>>> Scott ES
>>>>>>
>>>>>> --
>>>>>> --
>>>>>> Scott England-Sullivan
>>>>>> Apache Camel Committer
>>>>>> Principal Consultant / Sr. Architect | Red Hat, Inc.
>>>>>> FuseSource is now part of Red Hat
>>>>>> Web:     fusesource.com | redhat.com
>>>>>> Blog:     sully6768.blogspot.com
>>>>>> Twitter: sully6768
>
> -
> Scott England-Sullivan
> Apache Camel Committer
> http://sully6768.blogspot.com



--

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
OPS4J Pax for Vaadin
<http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
Lead
blog <http://notizblog.nierbeck.de/>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3rd Party Feature Definitions

David Jencks

On Oct 11, 2012, at 1:22 PM, Achim Nierbeck wrote:

> Yeah, I remember all those discussions about this topic also ...
>
> ... (dreaming of a perfect world)
> Aries and all the other depending projects produce features.xml artifacts ...
> (dream is over)

Since the subsystem spec is out that is not going to happen.  Karaf could use subsystems and drop its proprietary feature concept however.

david jencks

>
> unfortunately almost all non karaf-related projects produce feature files,
> therefore we have to take care of it then.
> I'm not sure about the proposed artifacts beeing coupled to tight to
> karaf release
> schedule (Andreas' idea of 3.x.y for Karaf 3.x version)
> I'd rather not do this, cause it just wouldn't help much on the issue.
>
> We should try to get those needed features either into the Projects
> where we do have some influence, like aries, pax-web (I'm actually working on
> this to decouple this stuff ;) ) and for all the others like spring
> we might just need something similar to what servicemix got for the
> osgi-fied bundles.
>
> So lets take the spring features.xml as the reference sample (since it
> did get this stuff started).
>
> <features name="spring-2.5.6">
>    <feature name="spring-core" version="2.5.6">
>    ....
> </features>
>
> and the maven artifact could be something like the following:
>
>    <groupId>org.apache.karaf.features</groupId>
>    <artifactId>spring-2.5.6</artifactId>
>    <version>1.0.1</version>
>
>
> for the other spring versions basically the same.
>
> regards, Achim
>
>
> 2012/10/11 Scott England-Sullivan <[hidden email]>:
>> For those just joining us, the original thread was:
>> http://karaf.922171.n3.nabble.com/Apache-Karaf-2-3-0-very-close-td4026295.html
>>
>> That sounds like a good solution.  One question though.  If you move
>> all the Karaf compatible "extensions" to a sub-group, wouldn't you
>> still encounter the same type of hold up?  For example, holding up an
>> Aries enterprise release with a critical bug fix due to ongoing
>> integration of a new Spring release.
>>
>>> On Oct 11, 2012, at 12:14 PM, Andreas Pieber <[hidden email]> wrote:
>>>
>>>> ah, and last but not least: we might want this discussion to be held
>>>> on the dev list.
>>>>
>>>> Kind regards,
>>>> Andreas
>>>>
>>>> On Thu, Oct 11, 2012 at 7:13 PM, Andreas Pieber <[hidden email]> wrote:
>>>>> OK, now that I finally found my way through the original thread
>>>>> causing this discussion I'm even stronger +1 for this topic than
>>>>> before.
>>>>>
>>>>> Get out everything out of the core release which is not started by
>>>>> default in the default apache-karaf distribution.
>>>>>
>>>>> To make things easy for us we might pack all those other features and
>>>>> commands and so on into a single release structure to make it easy for
>>>>> us which is quite roughly compatible to karaf core 2.x.y(.z) for Karaf
>>>>> 2 compatible plugins and 3.x.y(.z) for Karaf 3 compatible extensions.
>>>>> This should make the vote & the release process easy enough for us AND
>>>>> since we can version the features independently of the full release
>>>>> versions the user can still mix them as he sees fit.
>>>>>
>>>>> Just something else to get the discussion about this going :-)
>>>>>
>>>>> Kind regards,
>>>>> Andreas
>>>>>
>>>>> On Thu, Oct 11, 2012 at 6:54 PM, Andreas Pieber <[hidden email]> wrote:
>>>>>> Well, IIRC we've discussed this already on IRC some time ago about
>>>>>> that. One the main problems by this was that we need to release all of
>>>>>> those separately; which adds quite some work.
>>>>>>
>>>>>> But basically I'm with you. It's a PITA with those spring & aries
>>>>>> enterprise feature upgrades and that we have to wait for them. IMHO we
>>>>>> should really re-discuss this issue again; to move anything not
>>>>>> required into different features. Thanks to Christians searchurl
>>>>>> feature we could still make it pretty easy for ppl to add them
>>>>>> afterwards if they like. This wouldn't make too much difference to how
>>>>>> we're handling it right now anyhow...
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>> Kind regards,
>>>>>> Andreas
>>>>>>
>>>>>> On Tue, Oct 9, 2012 at 11:19 PM, Scott England-Sullivan
>>>>>> <[hidden email]> wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> In a recent thread on the development list there was a discussion
>>>>>>> regarding the release of Karaf 2.3.0 and the possibility of holding it
>>>>>>> up to accommodate an update to Spring 3.1.  It struck me; why is Karaf
>>>>>>> tied to a 3rd party release at all?  Why isn't the modular container
>>>>>>> itself modular?  Why aren't 3rd party support modules such as Spring
>>>>>>> deployers externalized and allowed to progress at their own pace?
>>>>>>> Third party dependent modules should be developed against a given
>>>>>>> release of Karaf, they shouldn't drive it.  There is a new
>>>>>>> karaf-webconsole project so the precedence is there.
>>>>>>>
>>>>>>> Karaf is a great, light-weight container which put a nice manageable
>>>>>>> wrapper on OSGi with a great CLI, ConfigAdmin, provisioning, etc., and
>>>>>>> IMHO should stay focused on just that at its core.  The capabilities
>>>>>>> that are tied to simplifying 3rd party support are goodness but not
>>>>>>> required and as such, shouldn't drive the cores development.
>>>>>>>
>>>>>>> Now maybe you really can't separate one from the other though I don't
>>>>>>> see where it is tightly coupled at.  I also understand it is a greater
>>>>>>> challenge to manage because the project become fractured but maybe
>>>>>>> Karaf is at that point.
>>>>>>>
>>>>>>> In reality I am good either way but thought it was worth discussing.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Scott ES
>>>>>>>
>>>>>>> --
>>>>>>> --
>>>>>>> Scott England-Sullivan
>>>>>>> Apache Camel Committer
>>>>>>> Principal Consultant / Sr. Architect | Red Hat, Inc.
>>>>>>> FuseSource is now part of Red Hat
>>>>>>> Web:     fusesource.com | redhat.com
>>>>>>> Blog:     sully6768.blogspot.com
>>>>>>> Twitter: sully6768
>>
>> -
>> Scott England-Sullivan
>> Apache Camel Committer
>> http://sully6768.blogspot.com
>
>
>
> --
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
> Committer & Project Lead
> OPS4J Pax for Vaadin
> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
> Lead
> blog <http://notizblog.nierbeck.de/>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3rd Party Feature Definitions

Andreas Pieber
well, subsystems sounds like a reasonable goal for Karaf 4.0. In the
meantime Achim's proposal sounds quite valid. Independently I'm still
a bit afraid of the hassle to release and vote on all those
separately...

Kind regards,
Andreas

On Fri, Oct 12, 2012 at 2:11 AM, David Jencks <[hidden email]> wrote:

>
> On Oct 11, 2012, at 1:22 PM, Achim Nierbeck wrote:
>
>> Yeah, I remember all those discussions about this topic also ...
>>
>> ... (dreaming of a perfect world)
>> Aries and all the other depending projects produce features.xml artifacts ...
>> (dream is over)
>
> Since the subsystem spec is out that is not going to happen.  Karaf could use subsystems and drop its proprietary feature concept however.
>
> david jencks
>
>>
>> unfortunately almost all non karaf-related projects produce feature files,
>> therefore we have to take care of it then.
>> I'm not sure about the proposed artifacts beeing coupled to tight to
>> karaf release
>> schedule (Andreas' idea of 3.x.y for Karaf 3.x version)
>> I'd rather not do this, cause it just wouldn't help much on the issue.
>>
>> We should try to get those needed features either into the Projects
>> where we do have some influence, like aries, pax-web (I'm actually working on
>> this to decouple this stuff ;) ) and for all the others like spring
>> we might just need something similar to what servicemix got for the
>> osgi-fied bundles.
>>
>> So lets take the spring features.xml as the reference sample (since it
>> did get this stuff started).
>>
>> <features name="spring-2.5.6">
>>    <feature name="spring-core" version="2.5.6">
>>    ....
>> </features>
>>
>> and the maven artifact could be something like the following:
>>
>>    <groupId>org.apache.karaf.features</groupId>
>>    <artifactId>spring-2.5.6</artifactId>
>>    <version>1.0.1</version>
>>
>>
>> for the other spring versions basically the same.
>>
>> regards, Achim
>>
>>
>> 2012/10/11 Scott England-Sullivan <[hidden email]>:
>>> For those just joining us, the original thread was:
>>> http://karaf.922171.n3.nabble.com/Apache-Karaf-2-3-0-very-close-td4026295.html
>>>
>>> That sounds like a good solution.  One question though.  If you move
>>> all the Karaf compatible "extensions" to a sub-group, wouldn't you
>>> still encounter the same type of hold up?  For example, holding up an
>>> Aries enterprise release with a critical bug fix due to ongoing
>>> integration of a new Spring release.
>>>
>>>> On Oct 11, 2012, at 12:14 PM, Andreas Pieber <[hidden email]> wrote:
>>>>
>>>>> ah, and last but not least: we might want this discussion to be held
>>>>> on the dev list.
>>>>>
>>>>> Kind regards,
>>>>> Andreas
>>>>>
>>>>> On Thu, Oct 11, 2012 at 7:13 PM, Andreas Pieber <[hidden email]> wrote:
>>>>>> OK, now that I finally found my way through the original thread
>>>>>> causing this discussion I'm even stronger +1 for this topic than
>>>>>> before.
>>>>>>
>>>>>> Get out everything out of the core release which is not started by
>>>>>> default in the default apache-karaf distribution.
>>>>>>
>>>>>> To make things easy for us we might pack all those other features and
>>>>>> commands and so on into a single release structure to make it easy for
>>>>>> us which is quite roughly compatible to karaf core 2.x.y(.z) for Karaf
>>>>>> 2 compatible plugins and 3.x.y(.z) for Karaf 3 compatible extensions.
>>>>>> This should make the vote & the release process easy enough for us AND
>>>>>> since we can version the features independently of the full release
>>>>>> versions the user can still mix them as he sees fit.
>>>>>>
>>>>>> Just something else to get the discussion about this going :-)
>>>>>>
>>>>>> Kind regards,
>>>>>> Andreas
>>>>>>
>>>>>> On Thu, Oct 11, 2012 at 6:54 PM, Andreas Pieber <[hidden email]> wrote:
>>>>>>> Well, IIRC we've discussed this already on IRC some time ago about
>>>>>>> that. One the main problems by this was that we need to release all of
>>>>>>> those separately; which adds quite some work.
>>>>>>>
>>>>>>> But basically I'm with you. It's a PITA with those spring & aries
>>>>>>> enterprise feature upgrades and that we have to wait for them. IMHO we
>>>>>>> should really re-discuss this issue again; to move anything not
>>>>>>> required into different features. Thanks to Christians searchurl
>>>>>>> feature we could still make it pretty easy for ppl to add them
>>>>>>> afterwards if they like. This wouldn't make too much difference to how
>>>>>>> we're handling it right now anyhow...
>>>>>>>
>>>>>>> WDYT?
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> Andreas
>>>>>>>
>>>>>>> On Tue, Oct 9, 2012 at 11:19 PM, Scott England-Sullivan
>>>>>>> <[hidden email]> wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> In a recent thread on the development list there was a discussion
>>>>>>>> regarding the release of Karaf 2.3.0 and the possibility of holding it
>>>>>>>> up to accommodate an update to Spring 3.1.  It struck me; why is Karaf
>>>>>>>> tied to a 3rd party release at all?  Why isn't the modular container
>>>>>>>> itself modular?  Why aren't 3rd party support modules such as Spring
>>>>>>>> deployers externalized and allowed to progress at their own pace?
>>>>>>>> Third party dependent modules should be developed against a given
>>>>>>>> release of Karaf, they shouldn't drive it.  There is a new
>>>>>>>> karaf-webconsole project so the precedence is there.
>>>>>>>>
>>>>>>>> Karaf is a great, light-weight container which put a nice manageable
>>>>>>>> wrapper on OSGi with a great CLI, ConfigAdmin, provisioning, etc., and
>>>>>>>> IMHO should stay focused on just that at its core.  The capabilities
>>>>>>>> that are tied to simplifying 3rd party support are goodness but not
>>>>>>>> required and as such, shouldn't drive the cores development.
>>>>>>>>
>>>>>>>> Now maybe you really can't separate one from the other though I don't
>>>>>>>> see where it is tightly coupled at.  I also understand it is a greater
>>>>>>>> challenge to manage because the project become fractured but maybe
>>>>>>>> Karaf is at that point.
>>>>>>>>
>>>>>>>> In reality I am good either way but thought it was worth discussing.
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Scott ES
>>>>>>>>
>>>>>>>> --
>>>>>>>> --
>>>>>>>> Scott England-Sullivan
>>>>>>>> Apache Camel Committer
>>>>>>>> Principal Consultant / Sr. Architect | Red Hat, Inc.
>>>>>>>> FuseSource is now part of Red Hat
>>>>>>>> Web:     fusesource.com | redhat.com
>>>>>>>> Blog:     sully6768.blogspot.com
>>>>>>>> Twitter: sully6768
>>>
>>> -
>>> Scott England-Sullivan
>>> Apache Camel Committer
>>> http://sully6768.blogspot.com
>>
>>
>>
>> --
>>
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>> Committer & Project Lead
>> OPS4J Pax for Vaadin
>> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
>> Lead
>> blog <http://notizblog.nierbeck.de/>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3rd Party Feature Definitions

Achim Nierbeck
to get a real good impression on what can be done with the subsystem
spec I'd have to take a deeper look at it first, so I can't tell right
now :)
but it could be promising.

about @Andreas' fears "of the hassle to release and vote on all those"
I'd say this probably is just once for a big load of features and
after
that ever now and then maybe one will increase / upgrade. Taking
Spring into account this won't be that often I think, and pax-web will
surely be hosted at pax-web, that's for sure :)

regards, Achim

2012/10/12 Andreas Pieber <[hidden email]>:

> well, subsystems sounds like a reasonable goal for Karaf 4.0. In the
> meantime Achim's proposal sounds quite valid. Independently I'm still
> a bit afraid of the hassle to release and vote on all those
> separately...
>
> Kind regards,
> Andreas
>
> On Fri, Oct 12, 2012 at 2:11 AM, David Jencks <[hidden email]> wrote:
>>
>> On Oct 11, 2012, at 1:22 PM, Achim Nierbeck wrote:
>>
>>> Yeah, I remember all those discussions about this topic also ...
>>>
>>> ... (dreaming of a perfect world)
>>> Aries and all the other depending projects produce features.xml artifacts ...
>>> (dream is over)
>>
>> Since the subsystem spec is out that is not going to happen.  Karaf could use subsystems and drop its proprietary feature concept however.
>>
>> david jencks
>>
>>>
>>> unfortunately almost all non karaf-related projects produce feature files,
>>> therefore we have to take care of it then.
>>> I'm not sure about the proposed artifacts beeing coupled to tight to
>>> karaf release
>>> schedule (Andreas' idea of 3.x.y for Karaf 3.x version)
>>> I'd rather not do this, cause it just wouldn't help much on the issue.
>>>
>>> We should try to get those needed features either into the Projects
>>> where we do have some influence, like aries, pax-web (I'm actually working on
>>> this to decouple this stuff ;) ) and for all the others like spring
>>> we might just need something similar to what servicemix got for the
>>> osgi-fied bundles.
>>>
>>> So lets take the spring features.xml as the reference sample (since it
>>> did get this stuff started).
>>>
>>> <features name="spring-2.5.6">
>>>    <feature name="spring-core" version="2.5.6">
>>>    ....
>>> </features>
>>>
>>> and the maven artifact could be something like the following:
>>>
>>>    <groupId>org.apache.karaf.features</groupId>
>>>    <artifactId>spring-2.5.6</artifactId>
>>>    <version>1.0.1</version>
>>>
>>>
>>> for the other spring versions basically the same.
>>>
>>> regards, Achim
>>>
>>>
>>> 2012/10/11 Scott England-Sullivan <[hidden email]>:
>>>> For those just joining us, the original thread was:
>>>> http://karaf.922171.n3.nabble.com/Apache-Karaf-2-3-0-very-close-td4026295.html
>>>>
>>>> That sounds like a good solution.  One question though.  If you move
>>>> all the Karaf compatible "extensions" to a sub-group, wouldn't you
>>>> still encounter the same type of hold up?  For example, holding up an
>>>> Aries enterprise release with a critical bug fix due to ongoing
>>>> integration of a new Spring release.
>>>>
>>>>> On Oct 11, 2012, at 12:14 PM, Andreas Pieber <[hidden email]> wrote:
>>>>>
>>>>>> ah, and last but not least: we might want this discussion to be held
>>>>>> on the dev list.
>>>>>>
>>>>>> Kind regards,
>>>>>> Andreas
>>>>>>
>>>>>> On Thu, Oct 11, 2012 at 7:13 PM, Andreas Pieber <[hidden email]> wrote:
>>>>>>> OK, now that I finally found my way through the original thread
>>>>>>> causing this discussion I'm even stronger +1 for this topic than
>>>>>>> before.
>>>>>>>
>>>>>>> Get out everything out of the core release which is not started by
>>>>>>> default in the default apache-karaf distribution.
>>>>>>>
>>>>>>> To make things easy for us we might pack all those other features and
>>>>>>> commands and so on into a single release structure to make it easy for
>>>>>>> us which is quite roughly compatible to karaf core 2.x.y(.z) for Karaf
>>>>>>> 2 compatible plugins and 3.x.y(.z) for Karaf 3 compatible extensions.
>>>>>>> This should make the vote & the release process easy enough for us AND
>>>>>>> since we can version the features independently of the full release
>>>>>>> versions the user can still mix them as he sees fit.
>>>>>>>
>>>>>>> Just something else to get the discussion about this going :-)
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> Andreas
>>>>>>>
>>>>>>> On Thu, Oct 11, 2012 at 6:54 PM, Andreas Pieber <[hidden email]> wrote:
>>>>>>>> Well, IIRC we've discussed this already on IRC some time ago about
>>>>>>>> that. One the main problems by this was that we need to release all of
>>>>>>>> those separately; which adds quite some work.
>>>>>>>>
>>>>>>>> But basically I'm with you. It's a PITA with those spring & aries
>>>>>>>> enterprise feature upgrades and that we have to wait for them. IMHO we
>>>>>>>> should really re-discuss this issue again; to move anything not
>>>>>>>> required into different features. Thanks to Christians searchurl
>>>>>>>> feature we could still make it pretty easy for ppl to add them
>>>>>>>> afterwards if they like. This wouldn't make too much difference to how
>>>>>>>> we're handling it right now anyhow...
>>>>>>>>
>>>>>>>> WDYT?
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> Andreas
>>>>>>>>
>>>>>>>> On Tue, Oct 9, 2012 at 11:19 PM, Scott England-Sullivan
>>>>>>>> <[hidden email]> wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> In a recent thread on the development list there was a discussion
>>>>>>>>> regarding the release of Karaf 2.3.0 and the possibility of holding it
>>>>>>>>> up to accommodate an update to Spring 3.1.  It struck me; why is Karaf
>>>>>>>>> tied to a 3rd party release at all?  Why isn't the modular container
>>>>>>>>> itself modular?  Why aren't 3rd party support modules such as Spring
>>>>>>>>> deployers externalized and allowed to progress at their own pace?
>>>>>>>>> Third party dependent modules should be developed against a given
>>>>>>>>> release of Karaf, they shouldn't drive it.  There is a new
>>>>>>>>> karaf-webconsole project so the precedence is there.
>>>>>>>>>
>>>>>>>>> Karaf is a great, light-weight container which put a nice manageable
>>>>>>>>> wrapper on OSGi with a great CLI, ConfigAdmin, provisioning, etc., and
>>>>>>>>> IMHO should stay focused on just that at its core.  The capabilities
>>>>>>>>> that are tied to simplifying 3rd party support are goodness but not
>>>>>>>>> required and as such, shouldn't drive the cores development.
>>>>>>>>>
>>>>>>>>> Now maybe you really can't separate one from the other though I don't
>>>>>>>>> see where it is tightly coupled at.  I also understand it is a greater
>>>>>>>>> challenge to manage because the project become fractured but maybe
>>>>>>>>> Karaf is at that point.
>>>>>>>>>
>>>>>>>>> In reality I am good either way but thought it was worth discussing.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Scott ES
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> --
>>>>>>>>> Scott England-Sullivan
>>>>>>>>> Apache Camel Committer
>>>>>>>>> Principal Consultant / Sr. Architect | Red Hat, Inc.
>>>>>>>>> FuseSource is now part of Red Hat
>>>>>>>>> Web:     fusesource.com | redhat.com
>>>>>>>>> Blog:     sully6768.blogspot.com
>>>>>>>>> Twitter: sully6768
>>>>
>>>> -
>>>> Scott England-Sullivan
>>>> Apache Camel Committer
>>>> http://sully6768.blogspot.com
>>>
>>>
>>>
>>> --
>>>
>>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>>> Committer & Project Lead
>>> OPS4J Pax for Vaadin
>>> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
>>> Lead
>>> blog <http://notizblog.nierbeck.de/>
>>



--

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
OPS4J Pax for Vaadin
<http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
Lead
blog <http://notizblog.nierbeck.de/>
Loading...