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 <[email protected]>:
> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
>>>>> <[email protected]> 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/>
