karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: [DISCUSS] Subprojects (was [VOTE] Add Cellar into Karaf trunk)
Date Wed, 04 May 2011 11:52:38 GMT
I think you misundertand me.
When camel 2.8.1 would be released, we'd just add the url to the global file at
  http://karaf.apache.org/features/repository.xml

Users could then install the updated feature as it would be
automatically available.

On Wed, May 4, 2011 at 13:42, Christian Schneider
<chris@die-schneider.net> wrote:
> The problem with listing all versions is that you can not work with newer
> version of e.g. camel. Imagine you have karaf working with camel 2.8.0. Then
> you have a bug which is fixed in camel 2.8.1. Then you will want to easily
> use camel 2.8.1 without waiting for a new karaf release.
>
> I think it would be better to scan for available versions on the maven repo
> and warn if the user tries to install a version that was not tested. And
> honestly we will not be able to test all those combinations anyway.
>
> Christian
>
>
> Am 04.05.2011 13:34, schrieb Guillaume Nodet:
>>
>> In that central xml, we can refer to multiple versions of the same
>> feature descriptor:
>>
>> <features>
>>
>> <repository>mvn:org.apache.camel/camel-karaf/xml/features/2.7.0</repository>
>>
>> <repository>mvn:org.apache.camel/camel-karaf/xml/features/2.8.0</repository>
>>  ...
>> </features>
>>
>> I think we'd need a descriptor for each minor version of Karaf so that
>> we can make sure only features that have been tested on a given karaf
>> version are available.
>>
>> On Wed, May 4, 2011 at 13:28, Christian Schneider
>> <chris@die-schneider.net>  wrote:
>>>
>>> I also think a small karaf with the easy possibility to create custom
>>> distros is the way to go.
>>> A central list of pointers to repository files makes sense. But we have
>>> to
>>> do this a bit different than the current feature files. Currently a url
>>> to a
>>> feature file always points to a certain version of that file. For a
>>> central
>>> list this does not make sense.
>>>
>>> So I think we rather need a list of the base urls without version and
>>> then
>>> an easy way for users to install a feature file with a certain version.
>>> So
>>> for example to install the feature url for camel the user should be able
>>> to
>>> write something like:
>>> features:addurl camel 2.7.0
>>>
>>> Do we already have support for this or something similar? Or do we have
>>> an
>>> issue for it? If not I can create one.
>>>
>>> Christian
>>>
>>>
>>> Am 04.05.2011 13:21, schrieb Guillaume Nodet:
>>>>
>>>> I think we need a way to enable user to install other features easily
>>>> without having to release karaf for that.
>>>> It just does not scale if we have to release Karaf because Camel as
>>>> released a new version for example.
>>>> We've already discussed that some time ago and I think we need to find
>>>> a good technical solution for that.
>>>> Maybe having a xml feature descriptor referenced at
>>>> http://karaf.apache.org/features/repository.xml which would point to
>>>> various other repositories (such as camel, cxf, servicemix, web,
>>>> aries, etc...) is more scalable as we would not have to release a new
>>>> karaf container each time one of those things change.  People may want
>>>> Apache Direction, OpenEJB, ActiveMQ, etc..., we can't host all those
>>>> things in Karaf trunk as this would create unnecessary ties between
>>>> the projects and Karaf.
>>>>
>>>> Once we have that, we should keep Karaf main distribution clean and
>>>> lean and provide all the optional bits using this way.   Combined with
>>>> an easy way to create custom distribution, I do think that's the way
>>>> to go.
>>>>
>>>> On Wed, May 4, 2011 at 13:12, Ioannis Canellos<iocanel@gmail.com>
>>>>  wrote:
>>>>>>
>>>>>> I think that's what we are working on already as part of 3.0, so
not
>>>>>> sure if I really understand what you mean here.
>>>>>>
>>>>> I see clustering to be part of the core karaf distribution. By that I
>>>>> mean
>>>>> that the clustering solution should be provided as a feature inside the
>>>>> standard feature repository.
>>>>>
>>>>> --
>>>>> *Ioannis Canellos*
>>>>> *
>>>>>  http://iocanel.blogspot.com
>>>>>
>>>>> Apache Karaf<http://karaf.apache.org/>    Committer&    PMC
>>>>> Apache ServiceMix<http://servicemix.apache.org/>      Committer
>>>>> *
>>>>>
>>>>
>>> --
>>> ----
>>> http://www.liquid-reality.de
>>>
>>>
>>
>>
>
> --
> ----
> http://www.liquid-reality.de
>
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Connect at CamelOne May 24-26
The Open Source Integration Conference
http://camelone.com/

Mime
View raw message