+1; I like the idea but I would propose the following modifications 1) rename featurelist to repository (or something like this) 2) downloadall, possibleurls, ... should be commands of repository I think 3) I think this with the versions could be handled if we have some repository entries only pointing to the root folder of a mvn repo; we can use the metadata file then to determine the real versions
kind regards, andreas On Fri, Feb 04, 2011 at 08:11:46AM +0100, Christian Schneider wrote: > > Am 04.02.2011 00:53, schrieb David Jencks: > > > >It seems to me that some of these ideas are not infinitely extensible. If > >everyone and their dog set up their projects to generate a karaf feature/kar > >we won't be able to track all of them. This may not be a problem for a long > >time though :-) > > > >SImilarly I'm not sure what you mean by "all installable features". A kar > >file gives you the option of installing any number of bundles and config > >info and features from a single file. These are now easy to create with the > >feature-maven-plugin. Does this seem sufficiently useful? > > > >thanks > >david jencks > > Hi David, > > What I meant with all installable feature lists. Is that we provide > a list of possible features.xml url. Ideally without the version > number. Something like: > karaf=>mvn:org.apache.karaf/apache-karaf > activemq=>mvn:org.apache.activemq/activemq-karaf > camel=>mvn:org.apache.camel.karaf/apache-camel > ... > > So this list could be that base for a command line extension that > allows to browse through the lists and versions. So with the list I > provided you could do: > > features:possibleurl > karaf > activemq > camel > > > featurelist:possibleurl camel > camel 2.5.0 > camel 2.6.0 > ... > > >features:addurl camel 2.5.0 > >features:addurl activemq 5.4.2 > >features:addurl karaf 2.1.3 > > >features:listurl > mvn:org.apache.karaf/apache-karaf/2.1.3/xml/features valid > mvn:org.apache.camel.karaf/apache-camel/2.6.0/xml/features valid > mvn:org.apache.activemq/activemq-karaf/5.4.2/xml/features valid > > >features:downloadall > This would download all features from all the features.xml files > above into either one repository e.g. contrib or into one repository > for each of the files. So after this command people could go offline > and > later install and uninstall all features they want without internet > connection. This part is very important as many companies do not > allow internet access inside their networks. Still the admins will > want to be flexible enough > to install and uninstall features. > > So the idea about this would be that people don´t have to remember > the mvn urls of all the features.xml files out there. Of course it > won´t be possible to track all of them but I think it would be > enough > to have the important ones. By not adding the version to the list > karaf could be flexible enough to find e.g. camel 2.7.0 as soon as > it is released. > > Best regards > > Christian > > > > > >>Best regards > >> > >>Christian > >> > >>-- > >>---- > >>http://www.liquid-reality.de > >> > >> > >> > >>Am 04.02.2011 00:07, schrieb Guillaume Nodet: > >>>Yeah, the problem is that Karaf itself isn't a container for Camel or > >>>CXF and we have some users that just want to plain JRE without any > >>>tweaks for running SAAJ because they don't care. > >>>ServiceMix on the other hand is dedicated to host such applications, > >>>so that's why the default config works better. > >>>I'm ok with the idea of profiles in karaf, but we need to make sure we > >>>don't end up with having to include and depend on all apache projects, > >>>as Karaf itself has imho no purpose of becoming a default distribution > >>>of CXF, Camel, ActiveMQ, Directory, etc... > >>>I think each project could easily provide a karaf features so that > >>>they would easily be deployed in a bare Karaf, but at some point, it > >>>does not really scale nor make sense to put everything back into > >>>Karaf. > >>> > >>>Tweaking the system properties is sometimes needed depending on what > >>>you need to deploy, because OSGi is lacking on certain areas (or > >>>because the JVM isn't really modular, depending on how you see > >>>things). Some people are happy with using the JAXB implementation > >>>from the JVM without being able to change it easily, some people may > >>>want to be able to deploy those as OSGi bundles. Karaf can't do both > >>>at the same time. > >>> > >>>Another point, is that the amount of third party dependencies is > >>>becoming increasingly important in Karaf, and that's really becoming a > >>>problem for simply releasing Karaf in an efficient manner. > >>>So I'm tempted to say that we should push back on those projects and > >>>have them provide karaf features, rather than having karaf providing > >>>features for those. I'm mostly thinking here about pax-web and the > >>>war support (which is really cool, no doubt on that) and aries and > >>>support for things we don't embed by default (jpa, etc..). > >>> > >>>I certainly don't have a good answer yet, but I just want to make sure > >>>everyone is aware of the potential problem. > >>> > >>>If we keep adding dependencies, our release cycles will necessarily be > >>>longer and longer .... For example camel has a release cycle of one > >>>minor version every few months, ServiceMix even less, while CXF has > >>>much less external dependencies and manage to keep a high frequency of > >>>releases. 2.2 could have been shipped early december, but we were > >>>waiting for aries. Now aries has been released, but we still have > >>>some snapshots dependencies on some felix or ops4j components. And > >>>we've added stuff that's not completely stabilized. > >>> > >>>Once again, I'm just trying to state facts so that everybody > >>>understand the situation. I'm personnaly not really happy that the > >>>2.2 release is planned since 2 months but still can't get out and I > >>>think it clearly means that we're going in a wrong direction somehow > >>>.... > >>> > >>>Sorry for the rant. There are a bunch of unrelated things here, ... > >>> > >>>On Wed, Feb 2, 2011 at 11:29, Jean-Baptiste Onofré<[email protected]> > >>>wrote: > >>>>Claus already raised a Jira about that. > >>>> > >>>>Guillaume wasn't very ok to set the jre.properties by default. > >>>> > >>>>On the other hand, I launched a discussion thread about Karaf profiles. > >>>>It's > >>>>typically the kind of tuning which is part of a profiles. > >>>> > >>>>Waiting for the profiles design, we can provide a Karaf Enterprise > >>>>distribution including this kind of tuning related to Camel/CXF/SMX. > >>>> > >>>>I add Karaf dev mailing list to see what the team says :) > >>>> > >>>>Regards > >>>>JB > >>>> > >>>>On 02/02/2011 11:21 AM, Christian Schneider wrote: > >>>>>Are these adapted jre.properties only usefull for Servicemix and the > >>>>>Talend Service Factory or do you think it would make sense to change > >>>>>them in > >>>>>the karaf distribution. > >>>>> > >>>>>Best regards > >>>>> > >>>>>Christian > >>>>> > >>>>> > >>>>>-----Ursprüngliche Nachricht----- > >>>>>Von: Jean-Baptiste Onofré [mailto:[email protected]] > >>>>>Gesendet: Mittwoch, 2. Februar 2011 11:02 > >>>>>An: [email protected] > >>>>>Betreff: Re: AW: Problem when starting camel-cxf in karaf > >>>>> > >>>>>Yeah, you can take a look on the ServiceMix one too :) > >>>>> > >>>>>Regards > >>>>>JB > >>>>> > >>>>>On 02/02/2011 10:26 AM, Christian Schneider wrote: > >>>>>>I think I was able to solve the problem. I had to change the > >>>>>>jre.properties to exclude some packages from the system bundle export. > >>>>>>The jre.properties from the Talend Service Factory seem to work: > >>>>>> > >>>>>>http://de.talend.com/products-application-integration/talend-service-factory-community-edition.php > >>>>>> > >>>>>>Christian > >>>>>> > > > > -- > ---- > http://www.liquid-reality.de >
pgp1hBwlVGdn8.pgp
Description: PGP signature
