karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jamie G." <jamie.goody...@gmail.com>
Subject Re: Thoughts about Karaf profiles / releases / growing number of dependencies (Re: AW: AW: Problem when starting camel-cxf in karaf)
Date Fri, 04 Feb 2011 00:13:22 GMT
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 <david_jencks@yahoo.com> 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é<jb@nanthrax.net>  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:jb@nanthrax.net]
>>>>> Gesendet: Mittwoch, 2. Februar 2011 11:02
>>>>> An: users@camel.apache.org
>>>>> 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
>>>>>>
>>
>
>

Mime
View raw message