One of the nice things about releasing Karaf has been that it's pretty straight forward - if we start to break it up into multiple releases then yes we'd gain flexibility at the cost of some complexity. Each Karaf release will then become a collection of parts that we deem to work well together, something akin to SMX releases. While this is manageable, is it preferable? As a monolith do we have more incentive to keep things small/compact, where as separate pieces things may collectively grow larger?
Jamie On Thu, Feb 3, 2011 at 8:23 PM, David Jencks <[email protected]> wrote: > > On Feb 3, 2011, at 3:27 PM, Christian Schneider wrote: > >> Hi Guillaume and the whole Karaf team, >> >> as I was involved in the discussion I would like to provide my point of view. >> >> I really like that karaf is as small as it is and it should stay this way. >> The only problem that I had was that the jre.properties deployed with karaf >> did not work with the >> camel-cxf feature. So how can this be solved? One way is simply better >> documentation on the karaf or camel wiki. Additionally the jre.properties >> from servicemix >> could be delivered in the karaf distro as e.g. jre.properties.servicemix or >> something. So it is easier for people to switch them. >> >> It would also be nice to have some feature urls already in karaf so people >> do not need to search them. They could be either directly included or should >> be easily activated. So for example karaf could know where the feature xmls >> of camel and activemq are in maven and then people could do something like: >> "features:addurl camel 2.6.0" perhaps even with content assist. On the other >> hand a wiki page with the list of the mvn: urls for all important feature >> xmls would already be good enough. >> >> I have not followed the profiles discussion but the current state of having >> feature urls and being able to install them with some commands sounds easy >> enough for me. >> >> The only thing that could be easier is installing features without an >> internet connection. It would be nice to have some command to download all >> installable features into a karaf directory so afterwards >> no internet connection is necessary. The camel feature plugin does this for >> distributions but it would be nice if users could do this simply from the >> command line. >> > > 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 > > >> 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 >>>>>> >> > >
