karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Pieber <anpie...@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 07:50:41 GMT
+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é<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
> >>>>>>
> >
> 
> -- 
> ----
> http://www.liquid-reality.de
> 

Mime
View raw message