+1 on the idea of Ioannis, I really want to see the clustering being part of the enterprise features, and again I think it is a good way of keeping the standard Karaf lean to put the clustering solution in a subproject, with all given pros and cons. I personally think the pros still override the cons.
just my 2 cents, Achim :-) 2011/5/4 Ioannis Canellos <[email protected]>: > Guys, we are getting off topic. > > Even though I like Guillaume's ideas about central repository etc, it is > still hypothetical since the mechanism is not implemented yet and thus we > can't base our decisions on that. > > What we currently have is standard/enterprise features descriptor. What I am > saying is that clustering should be part of the enterprise features > descriptor *(and probably hosted as subproject)*. Once we implement the > central repository mechanism we can move it there. > > On Wed, May 4, 2011 at 2:52 PM, Guillaume Nodet <[email protected]> wrote: > >> 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 >> <[email protected]> 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 >> >> <[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 >> >>> >> >>> >> >> >> >> >> > >> > -- >> > ---- >> > 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/ >> > > > > -- > *Ioannis Canellos* > * > http://iocanel.blogspot.com > > Apache Karaf <http://karaf.apache.org/> Committer & PMC > Apache ServiceMix <http://servicemix.apache.org/> Committer > * > -- -- *Achim Nierbeck* Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead
