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