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
