You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Jean-Baptiste Onofré <jb...@nanthrax.net> on 2011/02/05 12:50:21 UTC
Re: Branching karaf-2.2.x now (Re: Thoughts about Karaf profiles /releases / growing number of dependencies (Re: AW: AW: Problem when startingcamel-cxf in karaf)
The most important is not the name (RC, M, snapshots or whatever), it's to keep the community aware of the availability of artifacts.
So agree with Andreas, we can still user snapshots and just keep the user informed. Maybe we can send mail of user mailing list when a build is done of Hudson ?
Regards
JB
-----Original Message-----
From: Andreas Pieber <an...@gmail.com>
Date: Sat, 5 Feb 2011 12:44:36
To: <de...@karaf.apache.org>
Reply-To: dev@karaf.apache.org
Subject: Re: Branching karaf-2.2.x now (Re: Thoughts about Karaf profiles /
releases / growing number of dependencies (Re: AW: AW: Problem when starting
camel-cxf in karaf)
One "aftermatch" message to this thread. You're right, the snapshots should be
sufficient. But one thing here, WDYT about informing a broader community (e.g.
via user list too) that we've started branching off a specific x.X version and
stabilizing it and that we would welcome testing and feedback on the branch
during the next 2-3 stabilization weeks?
kind regards,
andreas
On Fri, Feb 04, 2011 at 07:05:36AM +0100, Guillaume Nodet wrote:
> If there are no objections, I'll branch karaf-2.2.x now in order to
> get the release stabilized as suggested by Andreas.
> This means any new development will occur in trunk which will moved to
> 2.99.99-SNAPSHOT ?
>
> On Fri, Feb 4, 2011 at 04:34, Andreas Pieber <an...@gmail.com> wrote:
> > OK, there are many points in my head about this for some time now and I hope I
> > get them out straight here. If I'm not able to make any of my points clear don't
> > hesitate to ask :)
> >
> > First of all I'm completely with Guillaume. I don't like the way Karaf blows
> > up. We have a standard and an enterprise distribution and a minimal distribution
> > and in future one for android... STOP. I think this is not the way Karaf should go.
> >
> > In addition, tbh I also don't like the way client projects (such as smx) have to
> > tweak Karaf around to make it runnable. This makes everything complex and not
> > easy to use understand/start with.
> >
> > Next I think the root of all evil are our configuration files. The need that we
> > have to tweak system.properties, custom.properties, jre.properties,
> > org...features.cfg to get a running, custom distribution. This does not feel
> > right.
> >
> > Fourth: I don't like that we need to use our own maven plugins to build Karaf is
> > IMHO a sign that Karaf is becoming much too big...
> >
> > Last but not least, I hate that I have to google for all those feature urls
> > and collect them locally to not forgetting them :)
> >
> > OK, so far to the problems. According to the mails I've read by now I think I'm
> > not the only one aware of those problems :) --> I would propose some roadmap
> > to get this straight again:
> >
> > 1) branch off karaf-2.x branch now (independent of the missing versions) and
> > stay as it is now. Some ppl already depend on karaf-2.1.99-SNAPSHOT and I don't
> > think that we'll make friends if we make any drastically changes to this
> > version.
> >
> > 2) Start developing karaf-2.99.99-SNAPSHOT right now.
> >
> > 3) As a first step I think we should add something like an online registry to
> > Karaf where feature files could be found. E.g. something like
> > karaf.apache.org/registry.xml. This would allow us to make Karaf behave the same
> > without having to pack everything together during assembly phase. Here it may
> > also help to add a features:addregistryurl command allowing clients to host
> > their own registries.
> >
> > 4) Move enterprise.features.xml into aries project, split standard.features.xml
> > into the different projects: karaf-obr, karaf-ssh, ops4j-web (e.g. with jetty),
> > spring2, spring3, ... and create own projects for the additional components. I'm
> > with Jamie that this will complex the release process, but IMHO everything we
> > create features files for shouldn't be in the core. As said somehow I even don't
> > like that we have features.xml in the core at all. All those features.xml have
> > to be added to the registry. This way we could guarantee that Karaf still
> > behaves the same although we've reduced the core packages/repo/distribution.
> >
> > 5) We have to extend the kar/features.xml model drastically adding variation
> > points for the different configuration possibilities in Karaf. E.g. we need a
> > variation point for lib, jre.properties, etc/(to add additional property files),
> > system (where we drop additional .jre bundles, ...), brandings, ... With that some variation
> > points require Karaf to reboot (we couldn't change everything at runtime). Which
> > means we have to cache the changes and apply them on reboot. In addition I know
> > that there will be some pain in config file merging, but I think this will be
> > worth the effort.
> >
> > 6) Now that we've removed all the specific things from Karaf we can reduce the
> > build process completely to one minimal distribution of Karaf (at maximum one
> > additional for android?!) without using the features concepts directly in the
> > kernel. This will also allow us to develop the karaf-maven-plugin directly in
> > the kernel without the burden of forking the process anywhere.
> >
> > 7) I think by that we're almost finished now. We can start contributing
> > features/kar packages for cxf, apache ds, camel, ... and add them again to the
> > registry. For this process the karaf-maven-plugin could/should be used.
> >
> > 8) Now a user will first of all create its own kar/features which tweak the
> > kernel as required. Finally he can either provide the kar/features bundle only.
> > The assembly process will (and should) always look like (reduced):
> >
> > karaf-maven-plugin
> > execution: distribution
> > kar-list (branding, docs, ... everything is a kar file, nothing more here)
> >
> > IMHO with all of this we can finally provide only one very small distribution.
> > Someone only experimenting/developing can do a
> >
> > features:install war, cfx, ds
> > admin:reboot
> >
> > Everyone else can create distributions as he likes.
> >
> > OK, I know that not all of those points are new or exclusively by me, some go a
> > little bit a different direction than discussed by now and not all of them are
> > nailed down to the latest detail (by now). Please don't flame me because of this;
> > I know that this is not the only way to go but it somehow feels right to me :)
> >
> > so... wdyt?
> >
> > kind regards,
> > andreas
> >
> > On Fri, Feb 04, 2011 at 12:07:42AM +0100, Guillaume Nodet wrote:
> >> 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
> >> >>>
> >> >>>
> >> >>> -----Ursprüngliche Nachricht-----
> >> >>> Von: Christian Schneider [mailto:cschneider@talend.com]
> >> >>> Gesendet: Mittwoch, 2. Februar 2011 09:52
> >> >>> An: users@camel.apache.org
> >> >>> Betreff: Problem when starting camel-cxf in karaf
> >> >>>
> >> >>> Hi all,
> >> >>>
> >> >>> I am trying to run Apache Camel (feature camel-cxf) in Apache Karaf.
> >> >>>
> >> >>> I am using a fresh Karaf 2.1.3 download.
> >> >>> I start karaf and enter:
> >> >>>
> >> >>>> features:addurl
> >> >>>> mvn:org.apache.camel.karaf/apache-camel/2.6.0/xml/features
> >> >>>> features:install camel-cxf
> >> >>>
> >> >>> I get an exception while starting
> >> >>> org.apache.servicemix.bundles.saaj-impl:
> >> >>> Unable to resolve 97.0: missing requirement [97.0] package;
> >> >>> (package=com.sun.org.apache.xerces.internal.dom)
> >> >>>
> >> >>> Any idea what I am doing wrong?
> >> >>>
> >> >>> Christian
> >> >>>
> >> >>> ----------------------
> >> >>>
> >> >>> 02.02.2011 09:46:08 org.apache.karaf.main.SimpleFileLock lock
> >> >>> INFO: locking
> >> >>> 09:46:09,765 | INFO | FelixStartLevel | jmx
> >> >>> | ? ? | 20 - org.apache.aries.jmx -
> >> >>> 0.2.0.incubating | Starting JMX OSGi agent
> >> >>> 09:46:09,781 | INFO | FelixStartLevel | jmx
> >> >>> | ? ? | 20 - org.apache.aries.jmx -
> >> >>> 0.2.0.incubating | Registering MBean with ObjectName
> >> >>> [osgi.compendium:service=cm,version=1.3] for service with service.id [10]
> >> >>> 09:46:09,796 | WARN | rint Extender: 3 | BlueprintContainerImpl
> >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> >> >>> 0.2.0.incubating | Bundle org.apache.karaf.features.command is waiting for
> >> >>> namespace handlers
> >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> >> >>> 09:46:09,796 | WARN | rint Extender: 2 | BlueprintContainerImpl
> >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.osgi is waiting for
> >> >>> namespace handlers
> >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> >> >>> 09:46:09,796 | WARN | JMX OSGi Agent | jmx
> >> >>> | ? ? | 20 - org.apache.aries.jmx -
> >> >>> 0.2.0.incubating | There are no MBean servers registred, can't register
> >> >>> MBeans
> >> >>> 09:46:09,890 | WARN | rint Extender: 2 | BlueprintContainerImpl
> >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.console is waiting for
> >> >>> namespace handlers
> >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0))]
> >> >>> 09:46:09,968 | WARN | rint Extender: 2 | BlueprintContainerImpl
> >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.dev is waiting for
> >> >>> namespace handlers
> >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> >> >>> 09:46:10,218 | WARN | rint Extender: 3 | BlueprintContainerImpl
> >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.ssh is waiting for
> >> >>> namespace handlers
> >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> >> >>> 09:46:10,234 | WARN | rint Extender: 3 | BlueprintContainerImpl
> >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> >> >>> 0.2.0.incubating | Bundle org.apache.karaf.admin.command is waiting for
> >> >>> namespace handlers
> >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> >> >>> 09:46:10,250 | WARN | rint Extender: 3 | BlueprintContainerImpl
> >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.commands is waiting for
> >> >>> namespace handlers
> >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> >> >>> 09:46:10,375 | WARN | rint Extender: 2 | BlueprintContainerImpl
> >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.packages is waiting for
> >> >>> namespace handlers
> >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> >> >>> 09:46:11,609 | INFO | Thread-5 | FeaturesServiceImpl
> >> >>> | res.internal.FeaturesServiceImpl 293 | 19 -
> >> >>> org.apache.karaf.features.core - 2.1.3 | Bundles to refresh:
> >> >>> 09:46:11,640 | INFO | rint Extender: 3 | SecurityUtils
> >> >>> | e.sshd.common.util.SecurityUtils 80 | 25 - sshd-core - 0.4.0 |
> >> >>> BouncyCastle not registered, using the default JCE provider
> >> >>> 09:46:11,968 | INFO | JMX OSGi Agent | jmx
> >> >>> | ? ? | 20 - org.apache.aries.jmx -
> >> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.BundleStateMBean to
> >> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
> >> >>> osgi.core:type=bundleState,version=1.5
> >> >>> 09:46:12,000 | INFO | JMX OSGi Agent | jmx
> >> >>> | ? ? | 20 - org.apache.aries.jmx -
> >> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.ServiceStateMBean to
> >> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
> >> >>> osgi.core:type=serviceState,version=1.5
> >> >>> 09:46:12,000 | INFO | JMX OSGi Agent | jmx
> >> >>> | ? ? | 20 - org.apache.aries.jmx -
> >> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.FrameworkMBean to
> >> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
> >> >>> osgi.core:type=framework,version=1.5
> >> >>> 09:46:12,031 | INFO | JMX OSGi Agent | jmx
> >> >>> | ? ? | 20 - org.apache.aries.jmx -
> >> >>> 0.2.0.incubating | Registering
> >> >>> org.osgi.jmx.service.cm.ConfigurationAdminMBean to MBeanServer
> >> >>> com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
> >> >>> osgi.compendium:service=cm,version=1.3
> >> >>> 09:46:12,031 | INFO | JMX OSGi Agent | jmx
> >> >>> | ? ? | 20 - org.apache.aries.jmx -
> >> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.PackageStateMBean to
> >> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
> >> >>> osgi.core:type=packageState,version=1.5
> >> >>> 09:48:08,234 | INFO | l Console Thread | FeaturesServiceImpl
> >> >>> | res.internal.FeaturesServiceImpl 293 | 19 -
> >> >>> org.apache.karaf.features.core - 2.1.3 | Bundles to refresh:
> >> >>> 09:48:08,656 | INFO | l Console Thread | ContextLoaderListener
> >> >>> | .activator.ContextLoaderListener 356 | 44 -
> >> >>> org.springframework.osgi.extender - 1.2.0 | Starting
> >> >>> [org.springframework.osgi.extender] bundle v.[1.2.0]
> >> >>> 09:48:08,781 | INFO | l Console Thread | ExtenderConfiguration
> >> >>> | al.support.ExtenderConfiguration 150 | 44 -
> >> >>> org.springframework.osgi.extender - 1.2.0 | No custom extender configuration
> >> >>> detected; using defaults...
> >> >>> 09:48:08,781 | INFO | l Console Thread | TimerTaskExecutor
> >> >>> | heduling.timer.TimerTaskExecutor 106 | 38 - org.springframework.context
> >> >>> - 3.0.5.RELEASE | Initializing Timer
> >> >>> 09:48:09,281 | INFO | l Console Thread | Activator
> >> >>> | apache.camel.impl.osgi.Activator 83 | 51 - org.apache.camel.camel-core
> >> >>> - 2.6.0 | Camel activator starting
> >> >>> 09:48:09,312 | INFO | l Console Thread | Activator
> >> >>> | apache.camel.impl.osgi.Activator 86 | 51 - org.apache.camel.camel-core
> >> >>> - 2.6.0 | Camel activator started
> >> >>> 09:48:10,968 | INFO | l Console Thread | Activator
> >> >>> | apache.camel.impl.osgi.Activator 90 | 51 - org.apache.camel.camel-core
> >> >>> - 2.6.0 | Camel activator stopping
> >> >>> 09:48:10,968 | INFO | l Console Thread | Activator
> >> >>> | apache.camel.impl.osgi.Activator 92 | 51 - org.apache.camel.camel-core
> >> >>> - 2.6.0 | Camel activator stopped
> >> >>> 09:48:11,984 | INFO | l Console Thread | ContextLoaderListener
> >> >>> | .activator.ContextLoaderListener 449 | 44 -
> >> >>> org.springframework.osgi.extender - 1.2.0 | Stopping
> >> >>> [org.springframework.osgi.extender] bundle v.[1.2.0]
> >> >>> 09:48:11,984 | INFO | l Console Thread | TimerTaskExecutor
> >> >>> | heduling.timer.TimerTaskExecutor 179 | 38 - org.springframework.context
> >> >>> - 3.0.5.RELEASE | Cancelling Timer
> >> >>> 09:48:12,281 | INFO | l Console Thread | Console
> >> >>> | araf.shell.console.jline.Console 188 | 11 -
> >> >>> org.apache.karaf.shell.console - 2.1.3 | Exception caught while executing
> >> >>> command
> >> >>> java.lang.Exception: Could not start bundle
> >> >>> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.saaj-impl/1.3.2_1
> >> >>> in feature(s) camel-cxf-2.6.0: Unresolved constraint in bundle
> >> >>> org.apache.servicemix.bundles.saaj-impl [97]: Unable to resolve 97.0:
> >> >>> missing requirement [97.0] package;
> >> >>> (package=com.sun.org.apache.xerces.internal.dom)
> >> >>> at
> >> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:326)[19:org.apache.karaf.features.core:2.1.3]
> >> >>> at
> >> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:254)[19:org.apache.karaf.features.core:2.1.3]
> >> >>> at
> >> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:250)[19:org.apache.karaf.features.core:2.1.3]
> >> >>> at
> >> >>> org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:51)[9:org.apache.karaf.features.command:2.1.3]
> >> >>> at
> >> >>> org.apache.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:39)[9:org.apache.karaf.features.command:2.1.3]
> >> >>> at
> >> >>> org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[11:org.apache.karaf.shell.console:2.1.3]
> >> >>> at
> >> >>> org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[11:org.apache.karaf.shell.console:2.1.3]
> >> >>> at
> >> >>> org.apache.felix.gogo.runtime.shell.CommandProxy.execute(CommandProxy.java:50)[11:org.apache.karaf.shell.console:2.1.3]
> >> >>> at
> >> >>> org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:229)[11:org.apache.karaf.shell.console:2.1.3]
> >> >>> at
> >> >>> org.apache.felix.gogo.runtime.shell.Closure.executeStatement(Closure.java:162)[11:org.apache.karaf.shell.console:2.1.3]
> >> >>> at
> >> >>> org.apache.felix.gogo.runtime.shell.Pipe.run(Pipe.java:101)[11:org.apache.karaf.shell.console:2.1.3]
> >> >>> at
> >> >>> org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:79)[11:org.apache.karaf.shell.console:2.1.3]
> >> >>> at
> >> >>> org.apache.felix.gogo.runtime.shell.CommandSessionImpl.execute(CommandSessionImpl.java:71)[11:org.apache.karaf.shell.console:2.1.3]
> >> >>> at
> >> >>> org.apache.karaf.shell.console.jline.Console.run(Console.java:170)[11:org.apache.karaf.shell.console:2.1.3]
> >> >>> at java.lang.Thread.run(Thread.java:662)[:1.6.0_23]
> >> >>> Caused by: org.osgi.framework.BundleException: Unresolved constraint in
> >> >>> bundle org.apache.servicemix.bundles.saaj-impl [97]: Unable to resolve 97.0:
> >> >>> missing requirement [97.0] package;
> >> >>> (package=com.sun.org.apache.xerces.internal.dom)
> >> >>> at
> >> >>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3409)[org.apache.felix.framework-3.0.2.jar:]
> >> >>> at
> >> >>> org.apache.felix.framework.Felix.startBundle(Felix.java:1709)[org.apache.felix.framework-3.0.2.jar:]
> >> >>> at
> >> >>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)[org.apache.felix.framework-3.0.2.jar:]
> >> >>> at
> >> >>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892)[org.apache.felix.framework-3.0.2.jar:]
> >> >>> at
> >> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:323)[19:org.apache.karaf.features.core:2.1.3]
> >> >>> ... 14 more
> >> >>>
> >> >
> >>
> >>
> >>
> >> --
> >> Cheers,
> >> Guillaume Nodet
> >> ------------------------
> >> Blog: http://gnodet.blogspot.com/
> >> ------------------------
> >> Open Source SOA
> >> http://fusesource.com
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: Branching karaf-2.2.x now (Re: Thoughts about Karaf
profiles/releases / growing number of dependencies (Re: AW: AW: Problem
whenstartingcamel-cxf in karaf)
Posted by "Jamie G." <ja...@gmail.com>.
I've updated the Release Guide to include a small section on community
awareness messages.
https://cwiki.apache.org/confluence/display/KARAF/Release+Guide
We don't branch trunk for dot zero releases all that often so I don't
think this would lead to a situation where we are spamming everyone's
inbox with updates.
Cheers,
Jamie
On Sat, Feb 5, 2011 at 9:56 AM, Jamie G. <ja...@gmail.com> wrote:
> Good idea Andreas.
>
> To me it sounds like part of the release manager role as it's an
> administrative detail. I'd be happy to add the above concept as a
> preamble to the release procedures (something along the lines of "in
> the time leading up to a release please perform the following").
>
> Jamie
>
> On Sat, Feb 5, 2011 at 8:43 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> Indeed, it could be interesting and give more information to the community.
>>
>> However it requires some "administrative" work. I can take the lead on this if someone else would like, he's welcome.
>>
>> Regards
>> JB
>> -----Original Message-----
>> From: Andreas Pieber <an...@gmail.com>
>> Date: Sat, 5 Feb 2011 13:04:09
>> To: <de...@karaf.apache.org>; <jb...@nanthrax.net>
>> Reply-To: dev@karaf.apache.org
>> Subject: Re: Branching karaf-2.2.x now (Re: Thoughts about Karaf profiles
>> /releases / growing number of dependencies (Re: AW: AW: Problem when
>> startingcamel-cxf in karaf)
>>
>> I don't think that an automated report is sufficient (finally we don't want to
>> spam the community to death :)). Maybe some kind of "news-letter".
>>
>> e.g. we branch off 2.2.x; mail to the user group:
>>
>> we've just branched off 2.2.x and started to stabilize it; latest artifacts are
>> available via apache-snapshot repo... simply add the following repo to your pom,
>> change the version to and provide us with feedback
>>
>> then 2 weeks later:
>>
>> thanks for all your feedback; we've fixed XX bugs/problems on the release branch
>> and will start a release about next week; thanks for all your contribution
>>
>> Also some information like: we've started developing according to 3.x because
>> we plan some major changes nailed down here: we think karaf requires ...
>> Everything could be found here...
>>
>> None of those mails should be longer than 5-7 lines; at least we want the
>> community to read them :)
>>
>> I think this shouldn't produce too much overhead for us but help us involving
>> a broader community and making our (IMHO really good) work @karaf more visibile?
>>
>> Feel free to correct me if you think I'm wrong ;)
>>
>> kind regards,
>> andreas
>>
>> On Sat, Feb 05, 2011 at 11:50:21AM +0000, Jean-Baptiste Onofré wrote:
>>> The most important is not the name (RC, M, snapshots or whatever), it's to keep the community aware of the availability of artifacts.
>>>
>>> So agree with Andreas, we can still user snapshots and just keep the user informed. Maybe we can send mail of user mailing list when a build is done of Hudson ?
>>>
>>> Regards
>>> JB
>>> -----Original Message-----
>>> From: Andreas Pieber <an...@gmail.com>
>>> Date: Sat, 5 Feb 2011 12:44:36
>>> To: <de...@karaf.apache.org>
>>> Reply-To: dev@karaf.apache.org
>>> Subject: Re: Branching karaf-2.2.x now (Re: Thoughts about Karaf profiles /
>>> releases / growing number of dependencies (Re: AW: AW: Problem when starting
>>> camel-cxf in karaf)
>>>
>>> One "aftermatch" message to this thread. You're right, the snapshots should be
>>> sufficient. But one thing here, WDYT about informing a broader community (e.g.
>>> via user list too) that we've started branching off a specific x.X version and
>>> stabilizing it and that we would welcome testing and feedback on the branch
>>> during the next 2-3 stabilization weeks?
>>>
>>> kind regards,
>>> andreas
>>>
>>> On Fri, Feb 04, 2011 at 07:05:36AM +0100, Guillaume Nodet wrote:
>>> > If there are no objections, I'll branch karaf-2.2.x now in order to
>>> > get the release stabilized as suggested by Andreas.
>>> > This means any new development will occur in trunk which will moved to
>>> > 2.99.99-SNAPSHOT ?
>>> >
>>> > On Fri, Feb 4, 2011 at 04:34, Andreas Pieber <an...@gmail.com> wrote:
>>> > > OK, there are many points in my head about this for some time now and I hope I
>>> > > get them out straight here. If I'm not able to make any of my points clear don't
>>> > > hesitate to ask :)
>>> > >
>>> > > First of all I'm completely with Guillaume. I don't like the way Karaf blows
>>> > > up. We have a standard and an enterprise distribution and a minimal distribution
>>> > > and in future one for android... STOP. I think this is not the way Karaf should go.
>>> > >
>>> > > In addition, tbh I also don't like the way client projects (such as smx) have to
>>> > > tweak Karaf around to make it runnable. This makes everything complex and not
>>> > > easy to use understand/start with.
>>> > >
>>> > > Next I think the root of all evil are our configuration files. The need that we
>>> > > have to tweak system.properties, custom.properties, jre.properties,
>>> > > org...features.cfg to get a running, custom distribution. This does not feel
>>> > > right.
>>> > >
>>> > > Fourth: I don't like that we need to use our own maven plugins to build Karaf is
>>> > > IMHO a sign that Karaf is becoming much too big...
>>> > >
>>> > > Last but not least, I hate that I have to google for all those feature urls
>>> > > and collect them locally to not forgetting them :)
>>> > >
>>> > > OK, so far to the problems. According to the mails I've read by now I think I'm
>>> > > not the only one aware of those problems :) --> I would propose some roadmap
>>> > > to get this straight again:
>>> > >
>>> > > 1) branch off karaf-2.x branch now (independent of the missing versions) and
>>> > > stay as it is now. Some ppl already depend on karaf-2.1.99-SNAPSHOT and I don't
>>> > > think that we'll make friends if we make any drastically changes to this
>>> > > version.
>>> > >
>>> > > 2) Start developing karaf-2.99.99-SNAPSHOT right now.
>>> > >
>>> > > 3) As a first step I think we should add something like an online registry to
>>> > > Karaf where feature files could be found. E.g. something like
>>> > > karaf.apache.org/registry.xml. This would allow us to make Karaf behave the same
>>> > > without having to pack everything together during assembly phase. Here it may
>>> > > also help to add a features:addregistryurl command allowing clients to host
>>> > > their own registries.
>>> > >
>>> > > 4) Move enterprise.features.xml into aries project, split standard.features.xml
>>> > > into the different projects: karaf-obr, karaf-ssh, ops4j-web (e.g. with jetty),
>>> > > spring2, spring3, ... and create own projects for the additional components. I'm
>>> > > with Jamie that this will complex the release process, but IMHO everything we
>>> > > create features files for shouldn't be in the core. As said somehow I even don't
>>> > > like that we have features.xml in the core at all. All those features.xml have
>>> > > to be added to the registry. This way we could guarantee that Karaf still
>>> > > behaves the same although we've reduced the core packages/repo/distribution.
>>> > >
>>> > > 5) We have to extend the kar/features.xml model drastically adding variation
>>> > > points for the different configuration possibilities in Karaf. E.g. we need a
>>> > > variation point for lib, jre.properties, etc/(to add additional property files),
>>> > > system (where we drop additional .jre bundles, ...), brandings, ... With that some variation
>>> > > points require Karaf to reboot (we couldn't change everything at runtime). Which
>>> > > means we have to cache the changes and apply them on reboot. In addition I know
>>> > > that there will be some pain in config file merging, but I think this will be
>>> > > worth the effort.
>>> > >
>>> > > 6) Now that we've removed all the specific things from Karaf we can reduce the
>>> > > build process completely to one minimal distribution of Karaf (at maximum one
>>> > > additional for android?!) without using the features concepts directly in the
>>> > > kernel. This will also allow us to develop the karaf-maven-plugin directly in
>>> > > the kernel without the burden of forking the process anywhere.
>>> > >
>>> > > 7) I think by that we're almost finished now. We can start contributing
>>> > > features/kar packages for cxf, apache ds, camel, ... and add them again to the
>>> > > registry. For this process the karaf-maven-plugin could/should be used.
>>> > >
>>> > > 8) Now a user will first of all create its own kar/features which tweak the
>>> > > kernel as required. Finally he can either provide the kar/features bundle only.
>>> > > The assembly process will (and should) always look like (reduced):
>>> > >
>>> > > karaf-maven-plugin
>>> > > execution: distribution
>>> > > kar-list (branding, docs, ... everything is a kar file, nothing more here)
>>> > >
>>> > > IMHO with all of this we can finally provide only one very small distribution.
>>> > > Someone only experimenting/developing can do a
>>> > >
>>> > > features:install war, cfx, ds
>>> > > admin:reboot
>>> > >
>>> > > Everyone else can create distributions as he likes.
>>> > >
>>> > > OK, I know that not all of those points are new or exclusively by me, some go a
>>> > > little bit a different direction than discussed by now and not all of them are
>>> > > nailed down to the latest detail (by now). Please don't flame me because of this;
>>> > > I know that this is not the only way to go but it somehow feels right to me :)
>>> > >
>>> > > so... wdyt?
>>> > >
>>> > > kind regards,
>>> > > andreas
>>> > >
>>> > > On Fri, Feb 04, 2011 at 12:07:42AM +0100, Guillaume Nodet wrote:
>>> > >> 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
>>> > >> >>>
>>> > >> >>>
>>> > >> >>> -----Ursprüngliche Nachricht-----
>>> > >> >>> Von: Christian Schneider [mailto:cschneider@talend.com]
>>> > >> >>> Gesendet: Mittwoch, 2. Februar 2011 09:52
>>> > >> >>> An: users@camel.apache.org
>>> > >> >>> Betreff: Problem when starting camel-cxf in karaf
>>> > >> >>>
>>> > >> >>> Hi all,
>>> > >> >>>
>>> > >> >>> I am trying to run Apache Camel (feature camel-cxf) in Apache Karaf.
>>> > >> >>>
>>> > >> >>> I am using a fresh Karaf 2.1.3 download.
>>> > >> >>> I start karaf and enter:
>>> > >> >>>
>>> > >> >>>> features:addurl
>>> > >> >>>> mvn:org.apache.camel.karaf/apache-camel/2.6.0/xml/features
>>> > >> >>>> features:install camel-cxf
>>> > >> >>>
>>> > >> >>> I get an exception while starting
>>> > >> >>> org.apache.servicemix.bundles.saaj-impl:
>>> > >> >>> Unable to resolve 97.0: missing requirement [97.0] package;
>>> > >> >>> (package=com.sun.org.apache.xerces.internal.dom)
>>> > >> >>>
>>> > >> >>> Any idea what I am doing wrong?
>>> > >> >>>
>>> > >> >>> Christian
>>> > >> >>>
>>> > >> >>> ----------------------
>>> > >> >>>
>>> > >> >>> 02.02.2011 09:46:08 org.apache.karaf.main.SimpleFileLock lock
>>> > >> >>> INFO: locking
>>> > >> >>> 09:46:09,765 | INFO | FelixStartLevel | jmx
>>> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
>>> > >> >>> 0.2.0.incubating | Starting JMX OSGi agent
>>> > >> >>> 09:46:09,781 | INFO | FelixStartLevel | jmx
>>> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
>>> > >> >>> 0.2.0.incubating | Registering MBean with ObjectName
>>> > >> >>> [osgi.compendium:service=cm,version=1.3] for service with service.id [10]
>>> > >> >>> 09:46:09,796 | WARN | rint Extender: 3 | BlueprintContainerImpl
>>> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.features.command is waiting for
>>> > >> >>> namespace handlers
>>> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>> > >> >>> 09:46:09,796 | WARN | rint Extender: 2 | BlueprintContainerImpl
>>> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.osgi is waiting for
>>> > >> >>> namespace handlers
>>> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>> > >> >>> 09:46:09,796 | WARN | JMX OSGi Agent | jmx
>>> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
>>> > >> >>> 0.2.0.incubating | There are no MBean servers registred, can't register
>>> > >> >>> MBeans
>>> > >> >>> 09:46:09,890 | WARN | rint Extender: 2 | BlueprintContainerImpl
>>> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.console is waiting for
>>> > >> >>> namespace handlers
>>> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0))]
>>> > >> >>> 09:46:09,968 | WARN | rint Extender: 2 | BlueprintContainerImpl
>>> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.dev is waiting for
>>> > >> >>> namespace handlers
>>> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>> > >> >>> 09:46:10,218 | WARN | rint Extender: 3 | BlueprintContainerImpl
>>> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.ssh is waiting for
>>> > >> >>> namespace handlers
>>> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>> > >> >>> 09:46:10,234 | WARN | rint Extender: 3 | BlueprintContainerImpl
>>> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.admin.command is waiting for
>>> > >> >>> namespace handlers
>>> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>> > >> >>> 09:46:10,250 | WARN | rint Extender: 3 | BlueprintContainerImpl
>>> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.commands is waiting for
>>> > >> >>> namespace handlers
>>> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>> > >> >>> 09:46:10,375 | WARN | rint Extender: 2 | BlueprintContainerImpl
>>> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>>> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.packages is waiting for
>>> > >> >>> namespace handlers
>>> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>>> > >> >>> 09:46:11,609 | INFO | Thread-5 | FeaturesServiceImpl
>>> > >> >>> | res.internal.FeaturesServiceImpl 293 | 19 -
>>> > >> >>> org.apache.karaf.features.core - 2.1.3 | Bundles to refresh:
>>> > >> >>> 09:46:11,640 | INFO | rint Extender: 3 | SecurityUtils
>>> > >> >>> | e.sshd.common.util.SecurityUtils 80 | 25 - sshd-core - 0.4.0 |
>>> > >> >>> BouncyCastle not registered, using the default JCE provider
>>> > >> >>> 09:46:11,968 | INFO | JMX OSGi Agent | jmx
>>> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
>>> > >> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.BundleStateMBean to
>>> > >> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
>>> > >> >>> osgi.core:type=bundleState,version=1.5
>>> > >> >>> 09:46:12,000 | INFO | JMX OSGi Agent | jmx
>>> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
>>> > >> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.ServiceStateMBean to
>>> > >> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
>>> > >> >>> osgi.core:type=serviceState,version=1.5
>>> > >> >>> 09:46:12,000 | INFO | JMX OSGi Agent | jmx
>>> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
>>> > >> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.FrameworkMBean to
>>> > >> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
>>> > >> >>> osgi.core:type=framework,version=1.5
>>> > >> >>> 09:46:12,031 | INFO | JMX OSGi Agent | jmx
>>> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
>>> > >> >>> 0.2.0.incubating | Registering
>>> > >> >>> org.osgi.jmx.service.cm.ConfigurationAdminMBean to MBeanServer
>>> > >> >>> com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
>>> > >> >>> osgi.compendium:service=cm,version=1.3
>>> > >> >>> 09:46:12,031 | INFO | JMX OSGi Agent | jmx
>>> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
>>> > >> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.PackageStateMBean to
>>> > >> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
>>> > >> >>> osgi.core:type=packageState,version=1.5
>>> > >> >>> 09:48:08,234 | INFO | l Console Thread | FeaturesServiceImpl
>>> > >> >>> | res.internal.FeaturesServiceImpl 293 | 19 -
>>> > >> >>> org.apache.karaf.features.core - 2.1.3 | Bundles to refresh:
>>> > >> >>> 09:48:08,656 | INFO | l Console Thread | ContextLoaderListener
>>> > >> >>> | .activator.ContextLoaderListener 356 | 44 -
>>> > >> >>> org.springframework.osgi.extender - 1.2.0 | Starting
>>> > >> >>> [org.springframework.osgi.extender] bundle v.[1.2.0]
>>> > >> >>> 09:48:08,781 | INFO | l Console Thread | ExtenderConfiguration
>>> > >> >>> | al.support.ExtenderConfiguration 150 | 44 -
>>> > >> >>> org.springframework.osgi.extender - 1.2.0 | No custom extender configuration
>>> > >> >>> detected; using defaults...
>>> > >> >>> 09:48:08,781 | INFO | l Console Thread | TimerTaskExecutor
>>> > >> >>> | heduling.timer.TimerTaskExecutor 106 | 38 - org.springframework.context
>>> > >> >>> - 3.0.5.RELEASE | Initializing Timer
>>> > >> >>> 09:48:09,281 | INFO | l Console Thread | Activator
>>> > >> >>> | apache.camel.impl.osgi.Activator 83 | 51 - org.apache.camel.camel-core
>>> > >> >>> - 2.6.0 | Camel activator starting
>>> > >> >>> 09:48:09,312 | INFO | l Console Thread | Activator
>>> > >> >>> | apache.camel.impl.osgi.Activator 86 | 51 - org.apache.camel.camel-core
>>> > >> >>> - 2.6.0 | Camel activator started
>>> > >> >>> 09:48:10,968 | INFO | l Console Thread | Activator
>>> > >> >>> | apache.camel.impl.osgi.Activator 90 | 51 - org.apache.camel.camel-core
>>> > >> >>> - 2.6.0 | Camel activator stopping
>>> > >> >>> 09:48:10,968 | INFO | l Console Thread | Activator
>>> > >> >>> | apache.camel.impl.osgi.Activator 92 | 51 - org.apache.camel.camel-core
>>> > >> >>> - 2.6.0 | Camel activator stopped
>>> > >> >>> 09:48:11,984 | INFO | l Console Thread | ContextLoaderListener
>>> > >> >>> | .activator.ContextLoaderListener 449 | 44 -
>>> > >> >>> org.springframework.osgi.extender - 1.2.0 | Stopping
>>> > >> >>> [org.springframework.osgi.extender] bundle v.[1.2.0]
>>> > >> >>> 09:48:11,984 | INFO | l Console Thread | TimerTaskExecutor
>>> > >> >>> | heduling.timer.TimerTaskExecutor 179 | 38 - org.springframework.context
>>> > >> >>> - 3.0.5.RELEASE | Cancelling Timer
>>> > >> >>> 09:48:12,281 | INFO | l Console Thread | Console
>>> > >> >>> | araf.shell.console.jline.Console 188 | 11 -
>>> > >> >>> org.apache.karaf.shell.console - 2.1.3 | Exception caught while executing
>>> > >> >>> command
>>> > >> >>> java.lang.Exception: Could not start bundle
>>> > >> >>> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.saaj-impl/1.3.2_1
>>> > >> >>> in feature(s) camel-cxf-2.6.0: Unresolved constraint in bundle
>>> > >> >>> org.apache.servicemix.bundles.saaj-impl [97]: Unable to resolve 97.0:
>>> > >> >>> missing requirement [97.0] package;
>>> > >> >>> (package=com.sun.org.apache.xerces.internal.dom)
>>> > >> >>> at
>>> > >> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:326)[19:org.apache.karaf.features.core:2.1.3]
>>> > >> >>> at
>>> > >> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:254)[19:org.apache.karaf.features.core:2.1.3]
>>> > >> >>> at
>>> > >> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:250)[19:org.apache.karaf.features.core:2.1.3]
>>> > >> >>> at
>>> > >> >>> org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:51)[9:org.apache.karaf.features.command:2.1.3]
>>> > >> >>> at
>>> > >> >>> org.apache.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:39)[9:org.apache.karaf.features.command:2.1.3]
>>> > >> >>> at
>>> > >> >>> org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[11:org.apache.karaf.shell.console:2.1.3]
>>> > >> >>> at
>>> > >> >>> org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[11:org.apache.karaf.shell.console:2.1.3]
>>> > >> >>> at
>>> > >> >>> org.apache.felix.gogo.runtime.shell.CommandProxy.execute(CommandProxy.java:50)[11:org.apache.karaf.shell.console:2.1.3]
>>> > >> >>> at
>>> > >> >>> org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:229)[11:org.apache.karaf.shell.console:2.1.3]
>>> > >> >>> at
>>> > >> >>> org.apache.felix.gogo.runtime.shell.Closure.executeStatement(Closure.java:162)[11:org.apache.karaf.shell.console:2.1.3]
>>> > >> >>> at
>>> > >> >>> org.apache.felix.gogo.runtime.shell.Pipe.run(Pipe.java:101)[11:org.apache.karaf.shell.console:2.1.3]
>>> > >> >>> at
>>> > >> >>> org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:79)[11:org.apache.karaf.shell.console:2.1.3]
>>> > >> >>> at
>>> > >> >>> org.apache.felix.gogo.runtime.shell.CommandSessionImpl.execute(CommandSessionImpl.java:71)[11:org.apache.karaf.shell.console:2.1.3]
>>> > >> >>> at
>>> > >> >>> org.apache.karaf.shell.console.jline.Console.run(Console.java:170)[11:org.apache.karaf.shell.console:2.1.3]
>>> > >> >>> at java.lang.Thread.run(Thread.java:662)[:1.6.0_23]
>>> > >> >>> Caused by: org.osgi.framework.BundleException: Unresolved constraint in
>>> > >> >>> bundle org.apache.servicemix.bundles.saaj-impl [97]: Unable to resolve 97.0:
>>> > >> >>> missing requirement [97.0] package;
>>> > >> >>> (package=com.sun.org.apache.xerces.internal.dom)
>>> > >> >>> at
>>> > >> >>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3409)[org.apache.felix.framework-3.0.2.jar:]
>>> > >> >>> at
>>> > >> >>> org.apache.felix.framework.Felix.startBundle(Felix.java:1709)[org.apache.felix.framework-3.0.2.jar:]
>>> > >> >>> at
>>> > >> >>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)[org.apache.felix.framework-3.0.2.jar:]
>>> > >> >>> at
>>> > >> >>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892)[org.apache.felix.framework-3.0.2.jar:]
>>> > >> >>> at
>>> > >> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:323)[19:org.apache.karaf.features.core:2.1.3]
>>> > >> >>> ... 14 more
>>> > >> >>>
>>> > >> >
>>> > >>
>>> > >>
>>> > >>
>>> > >> --
>>> > >> Cheers,
>>> > >> Guillaume Nodet
>>> > >> ------------------------
>>> > >> Blog: http://gnodet.blogspot.com/
>>> > >> ------------------------
>>> > >> Open Source SOA
>>> > >> http://fusesource.com
>>> > >
>>> >
>>> >
>>> >
>>> > --
>>> > Cheers,
>>> > Guillaume Nodet
>>> > ------------------------
>>> > Blog: http://gnodet.blogspot.com/
>>> > ------------------------
>>> > Open Source SOA
>>> > http://fusesource.com
>>>
>>
>>
>
Re: Branching karaf-2.2.x now (Re: Thoughts about Karaf
profiles/releases / growing number of dependencies (Re: AW: AW: Problem
whenstartingcamel-cxf in karaf)
Posted by "Jamie G." <ja...@gmail.com>.
Good idea Andreas.
To me it sounds like part of the release manager role as it's an
administrative detail. I'd be happy to add the above concept as a
preamble to the release procedures (something along the lines of "in
the time leading up to a release please perform the following").
Jamie
On Sat, Feb 5, 2011 at 8:43 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Indeed, it could be interesting and give more information to the community.
>
> However it requires some "administrative" work. I can take the lead on this if someone else would like, he's welcome.
>
> Regards
> JB
> -----Original Message-----
> From: Andreas Pieber <an...@gmail.com>
> Date: Sat, 5 Feb 2011 13:04:09
> To: <de...@karaf.apache.org>; <jb...@nanthrax.net>
> Reply-To: dev@karaf.apache.org
> Subject: Re: Branching karaf-2.2.x now (Re: Thoughts about Karaf profiles
> /releases / growing number of dependencies (Re: AW: AW: Problem when
> startingcamel-cxf in karaf)
>
> I don't think that an automated report is sufficient (finally we don't want to
> spam the community to death :)). Maybe some kind of "news-letter".
>
> e.g. we branch off 2.2.x; mail to the user group:
>
> we've just branched off 2.2.x and started to stabilize it; latest artifacts are
> available via apache-snapshot repo... simply add the following repo to your pom,
> change the version to and provide us with feedback
>
> then 2 weeks later:
>
> thanks for all your feedback; we've fixed XX bugs/problems on the release branch
> and will start a release about next week; thanks for all your contribution
>
> Also some information like: we've started developing according to 3.x because
> we plan some major changes nailed down here: we think karaf requires ...
> Everything could be found here...
>
> None of those mails should be longer than 5-7 lines; at least we want the
> community to read them :)
>
> I think this shouldn't produce too much overhead for us but help us involving
> a broader community and making our (IMHO really good) work @karaf more visibile?
>
> Feel free to correct me if you think I'm wrong ;)
>
> kind regards,
> andreas
>
> On Sat, Feb 05, 2011 at 11:50:21AM +0000, Jean-Baptiste Onofré wrote:
>> The most important is not the name (RC, M, snapshots or whatever), it's to keep the community aware of the availability of artifacts.
>>
>> So agree with Andreas, we can still user snapshots and just keep the user informed. Maybe we can send mail of user mailing list when a build is done of Hudson ?
>>
>> Regards
>> JB
>> -----Original Message-----
>> From: Andreas Pieber <an...@gmail.com>
>> Date: Sat, 5 Feb 2011 12:44:36
>> To: <de...@karaf.apache.org>
>> Reply-To: dev@karaf.apache.org
>> Subject: Re: Branching karaf-2.2.x now (Re: Thoughts about Karaf profiles /
>> releases / growing number of dependencies (Re: AW: AW: Problem when starting
>> camel-cxf in karaf)
>>
>> One "aftermatch" message to this thread. You're right, the snapshots should be
>> sufficient. But one thing here, WDYT about informing a broader community (e.g.
>> via user list too) that we've started branching off a specific x.X version and
>> stabilizing it and that we would welcome testing and feedback on the branch
>> during the next 2-3 stabilization weeks?
>>
>> kind regards,
>> andreas
>>
>> On Fri, Feb 04, 2011 at 07:05:36AM +0100, Guillaume Nodet wrote:
>> > If there are no objections, I'll branch karaf-2.2.x now in order to
>> > get the release stabilized as suggested by Andreas.
>> > This means any new development will occur in trunk which will moved to
>> > 2.99.99-SNAPSHOT ?
>> >
>> > On Fri, Feb 4, 2011 at 04:34, Andreas Pieber <an...@gmail.com> wrote:
>> > > OK, there are many points in my head about this for some time now and I hope I
>> > > get them out straight here. If I'm not able to make any of my points clear don't
>> > > hesitate to ask :)
>> > >
>> > > First of all I'm completely with Guillaume. I don't like the way Karaf blows
>> > > up. We have a standard and an enterprise distribution and a minimal distribution
>> > > and in future one for android... STOP. I think this is not the way Karaf should go.
>> > >
>> > > In addition, tbh I also don't like the way client projects (such as smx) have to
>> > > tweak Karaf around to make it runnable. This makes everything complex and not
>> > > easy to use understand/start with.
>> > >
>> > > Next I think the root of all evil are our configuration files. The need that we
>> > > have to tweak system.properties, custom.properties, jre.properties,
>> > > org...features.cfg to get a running, custom distribution. This does not feel
>> > > right.
>> > >
>> > > Fourth: I don't like that we need to use our own maven plugins to build Karaf is
>> > > IMHO a sign that Karaf is becoming much too big...
>> > >
>> > > Last but not least, I hate that I have to google for all those feature urls
>> > > and collect them locally to not forgetting them :)
>> > >
>> > > OK, so far to the problems. According to the mails I've read by now I think I'm
>> > > not the only one aware of those problems :) --> I would propose some roadmap
>> > > to get this straight again:
>> > >
>> > > 1) branch off karaf-2.x branch now (independent of the missing versions) and
>> > > stay as it is now. Some ppl already depend on karaf-2.1.99-SNAPSHOT and I don't
>> > > think that we'll make friends if we make any drastically changes to this
>> > > version.
>> > >
>> > > 2) Start developing karaf-2.99.99-SNAPSHOT right now.
>> > >
>> > > 3) As a first step I think we should add something like an online registry to
>> > > Karaf where feature files could be found. E.g. something like
>> > > karaf.apache.org/registry.xml. This would allow us to make Karaf behave the same
>> > > without having to pack everything together during assembly phase. Here it may
>> > > also help to add a features:addregistryurl command allowing clients to host
>> > > their own registries.
>> > >
>> > > 4) Move enterprise.features.xml into aries project, split standard.features.xml
>> > > into the different projects: karaf-obr, karaf-ssh, ops4j-web (e.g. with jetty),
>> > > spring2, spring3, ... and create own projects for the additional components. I'm
>> > > with Jamie that this will complex the release process, but IMHO everything we
>> > > create features files for shouldn't be in the core. As said somehow I even don't
>> > > like that we have features.xml in the core at all. All those features.xml have
>> > > to be added to the registry. This way we could guarantee that Karaf still
>> > > behaves the same although we've reduced the core packages/repo/distribution.
>> > >
>> > > 5) We have to extend the kar/features.xml model drastically adding variation
>> > > points for the different configuration possibilities in Karaf. E.g. we need a
>> > > variation point for lib, jre.properties, etc/(to add additional property files),
>> > > system (where we drop additional .jre bundles, ...), brandings, ... With that some variation
>> > > points require Karaf to reboot (we couldn't change everything at runtime). Which
>> > > means we have to cache the changes and apply them on reboot. In addition I know
>> > > that there will be some pain in config file merging, but I think this will be
>> > > worth the effort.
>> > >
>> > > 6) Now that we've removed all the specific things from Karaf we can reduce the
>> > > build process completely to one minimal distribution of Karaf (at maximum one
>> > > additional for android?!) without using the features concepts directly in the
>> > > kernel. This will also allow us to develop the karaf-maven-plugin directly in
>> > > the kernel without the burden of forking the process anywhere.
>> > >
>> > > 7) I think by that we're almost finished now. We can start contributing
>> > > features/kar packages for cxf, apache ds, camel, ... and add them again to the
>> > > registry. For this process the karaf-maven-plugin could/should be used.
>> > >
>> > > 8) Now a user will first of all create its own kar/features which tweak the
>> > > kernel as required. Finally he can either provide the kar/features bundle only.
>> > > The assembly process will (and should) always look like (reduced):
>> > >
>> > > karaf-maven-plugin
>> > > execution: distribution
>> > > kar-list (branding, docs, ... everything is a kar file, nothing more here)
>> > >
>> > > IMHO with all of this we can finally provide only one very small distribution.
>> > > Someone only experimenting/developing can do a
>> > >
>> > > features:install war, cfx, ds
>> > > admin:reboot
>> > >
>> > > Everyone else can create distributions as he likes.
>> > >
>> > > OK, I know that not all of those points are new or exclusively by me, some go a
>> > > little bit a different direction than discussed by now and not all of them are
>> > > nailed down to the latest detail (by now). Please don't flame me because of this;
>> > > I know that this is not the only way to go but it somehow feels right to me :)
>> > >
>> > > so... wdyt?
>> > >
>> > > kind regards,
>> > > andreas
>> > >
>> > > On Fri, Feb 04, 2011 at 12:07:42AM +0100, Guillaume Nodet wrote:
>> > >> 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
>> > >> >>>
>> > >> >>>
>> > >> >>> -----Ursprüngliche Nachricht-----
>> > >> >>> Von: Christian Schneider [mailto:cschneider@talend.com]
>> > >> >>> Gesendet: Mittwoch, 2. Februar 2011 09:52
>> > >> >>> An: users@camel.apache.org
>> > >> >>> Betreff: Problem when starting camel-cxf in karaf
>> > >> >>>
>> > >> >>> Hi all,
>> > >> >>>
>> > >> >>> I am trying to run Apache Camel (feature camel-cxf) in Apache Karaf.
>> > >> >>>
>> > >> >>> I am using a fresh Karaf 2.1.3 download.
>> > >> >>> I start karaf and enter:
>> > >> >>>
>> > >> >>>> features:addurl
>> > >> >>>> mvn:org.apache.camel.karaf/apache-camel/2.6.0/xml/features
>> > >> >>>> features:install camel-cxf
>> > >> >>>
>> > >> >>> I get an exception while starting
>> > >> >>> org.apache.servicemix.bundles.saaj-impl:
>> > >> >>> Unable to resolve 97.0: missing requirement [97.0] package;
>> > >> >>> (package=com.sun.org.apache.xerces.internal.dom)
>> > >> >>>
>> > >> >>> Any idea what I am doing wrong?
>> > >> >>>
>> > >> >>> Christian
>> > >> >>>
>> > >> >>> ----------------------
>> > >> >>>
>> > >> >>> 02.02.2011 09:46:08 org.apache.karaf.main.SimpleFileLock lock
>> > >> >>> INFO: locking
>> > >> >>> 09:46:09,765 | INFO | FelixStartLevel | jmx
>> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
>> > >> >>> 0.2.0.incubating | Starting JMX OSGi agent
>> > >> >>> 09:46:09,781 | INFO | FelixStartLevel | jmx
>> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
>> > >> >>> 0.2.0.incubating | Registering MBean with ObjectName
>> > >> >>> [osgi.compendium:service=cm,version=1.3] for service with service.id [10]
>> > >> >>> 09:46:09,796 | WARN | rint Extender: 3 | BlueprintContainerImpl
>> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.features.command is waiting for
>> > >> >>> namespace handlers
>> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>> > >> >>> 09:46:09,796 | WARN | rint Extender: 2 | BlueprintContainerImpl
>> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.osgi is waiting for
>> > >> >>> namespace handlers
>> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>> > >> >>> 09:46:09,796 | WARN | JMX OSGi Agent | jmx
>> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
>> > >> >>> 0.2.0.incubating | There are no MBean servers registred, can't register
>> > >> >>> MBeans
>> > >> >>> 09:46:09,890 | WARN | rint Extender: 2 | BlueprintContainerImpl
>> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.console is waiting for
>> > >> >>> namespace handlers
>> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0))]
>> > >> >>> 09:46:09,968 | WARN | rint Extender: 2 | BlueprintContainerImpl
>> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.dev is waiting for
>> > >> >>> namespace handlers
>> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>> > >> >>> 09:46:10,218 | WARN | rint Extender: 3 | BlueprintContainerImpl
>> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.ssh is waiting for
>> > >> >>> namespace handlers
>> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>> > >> >>> 09:46:10,234 | WARN | rint Extender: 3 | BlueprintContainerImpl
>> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.admin.command is waiting for
>> > >> >>> namespace handlers
>> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>> > >> >>> 09:46:10,250 | WARN | rint Extender: 3 | BlueprintContainerImpl
>> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.commands is waiting for
>> > >> >>> namespace handlers
>> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>> > >> >>> 09:46:10,375 | WARN | rint Extender: 2 | BlueprintContainerImpl
>> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
>> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.packages is waiting for
>> > >> >>> namespace handlers
>> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
>> > >> >>> 09:46:11,609 | INFO | Thread-5 | FeaturesServiceImpl
>> > >> >>> | res.internal.FeaturesServiceImpl 293 | 19 -
>> > >> >>> org.apache.karaf.features.core - 2.1.3 | Bundles to refresh:
>> > >> >>> 09:46:11,640 | INFO | rint Extender: 3 | SecurityUtils
>> > >> >>> | e.sshd.common.util.SecurityUtils 80 | 25 - sshd-core - 0.4.0 |
>> > >> >>> BouncyCastle not registered, using the default JCE provider
>> > >> >>> 09:46:11,968 | INFO | JMX OSGi Agent | jmx
>> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
>> > >> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.BundleStateMBean to
>> > >> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
>> > >> >>> osgi.core:type=bundleState,version=1.5
>> > >> >>> 09:46:12,000 | INFO | JMX OSGi Agent | jmx
>> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
>> > >> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.ServiceStateMBean to
>> > >> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
>> > >> >>> osgi.core:type=serviceState,version=1.5
>> > >> >>> 09:46:12,000 | INFO | JMX OSGi Agent | jmx
>> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
>> > >> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.FrameworkMBean to
>> > >> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
>> > >> >>> osgi.core:type=framework,version=1.5
>> > >> >>> 09:46:12,031 | INFO | JMX OSGi Agent | jmx
>> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
>> > >> >>> 0.2.0.incubating | Registering
>> > >> >>> org.osgi.jmx.service.cm.ConfigurationAdminMBean to MBeanServer
>> > >> >>> com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
>> > >> >>> osgi.compendium:service=cm,version=1.3
>> > >> >>> 09:46:12,031 | INFO | JMX OSGi Agent | jmx
>> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
>> > >> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.PackageStateMBean to
>> > >> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
>> > >> >>> osgi.core:type=packageState,version=1.5
>> > >> >>> 09:48:08,234 | INFO | l Console Thread | FeaturesServiceImpl
>> > >> >>> | res.internal.FeaturesServiceImpl 293 | 19 -
>> > >> >>> org.apache.karaf.features.core - 2.1.3 | Bundles to refresh:
>> > >> >>> 09:48:08,656 | INFO | l Console Thread | ContextLoaderListener
>> > >> >>> | .activator.ContextLoaderListener 356 | 44 -
>> > >> >>> org.springframework.osgi.extender - 1.2.0 | Starting
>> > >> >>> [org.springframework.osgi.extender] bundle v.[1.2.0]
>> > >> >>> 09:48:08,781 | INFO | l Console Thread | ExtenderConfiguration
>> > >> >>> | al.support.ExtenderConfiguration 150 | 44 -
>> > >> >>> org.springframework.osgi.extender - 1.2.0 | No custom extender configuration
>> > >> >>> detected; using defaults...
>> > >> >>> 09:48:08,781 | INFO | l Console Thread | TimerTaskExecutor
>> > >> >>> | heduling.timer.TimerTaskExecutor 106 | 38 - org.springframework.context
>> > >> >>> - 3.0.5.RELEASE | Initializing Timer
>> > >> >>> 09:48:09,281 | INFO | l Console Thread | Activator
>> > >> >>> | apache.camel.impl.osgi.Activator 83 | 51 - org.apache.camel.camel-core
>> > >> >>> - 2.6.0 | Camel activator starting
>> > >> >>> 09:48:09,312 | INFO | l Console Thread | Activator
>> > >> >>> | apache.camel.impl.osgi.Activator 86 | 51 - org.apache.camel.camel-core
>> > >> >>> - 2.6.0 | Camel activator started
>> > >> >>> 09:48:10,968 | INFO | l Console Thread | Activator
>> > >> >>> | apache.camel.impl.osgi.Activator 90 | 51 - org.apache.camel.camel-core
>> > >> >>> - 2.6.0 | Camel activator stopping
>> > >> >>> 09:48:10,968 | INFO | l Console Thread | Activator
>> > >> >>> | apache.camel.impl.osgi.Activator 92 | 51 - org.apache.camel.camel-core
>> > >> >>> - 2.6.0 | Camel activator stopped
>> > >> >>> 09:48:11,984 | INFO | l Console Thread | ContextLoaderListener
>> > >> >>> | .activator.ContextLoaderListener 449 | 44 -
>> > >> >>> org.springframework.osgi.extender - 1.2.0 | Stopping
>> > >> >>> [org.springframework.osgi.extender] bundle v.[1.2.0]
>> > >> >>> 09:48:11,984 | INFO | l Console Thread | TimerTaskExecutor
>> > >> >>> | heduling.timer.TimerTaskExecutor 179 | 38 - org.springframework.context
>> > >> >>> - 3.0.5.RELEASE | Cancelling Timer
>> > >> >>> 09:48:12,281 | INFO | l Console Thread | Console
>> > >> >>> | araf.shell.console.jline.Console 188 | 11 -
>> > >> >>> org.apache.karaf.shell.console - 2.1.3 | Exception caught while executing
>> > >> >>> command
>> > >> >>> java.lang.Exception: Could not start bundle
>> > >> >>> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.saaj-impl/1.3.2_1
>> > >> >>> in feature(s) camel-cxf-2.6.0: Unresolved constraint in bundle
>> > >> >>> org.apache.servicemix.bundles.saaj-impl [97]: Unable to resolve 97.0:
>> > >> >>> missing requirement [97.0] package;
>> > >> >>> (package=com.sun.org.apache.xerces.internal.dom)
>> > >> >>> at
>> > >> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:326)[19:org.apache.karaf.features.core:2.1.3]
>> > >> >>> at
>> > >> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:254)[19:org.apache.karaf.features.core:2.1.3]
>> > >> >>> at
>> > >> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:250)[19:org.apache.karaf.features.core:2.1.3]
>> > >> >>> at
>> > >> >>> org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:51)[9:org.apache.karaf.features.command:2.1.3]
>> > >> >>> at
>> > >> >>> org.apache.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:39)[9:org.apache.karaf.features.command:2.1.3]
>> > >> >>> at
>> > >> >>> org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[11:org.apache.karaf.shell.console:2.1.3]
>> > >> >>> at
>> > >> >>> org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[11:org.apache.karaf.shell.console:2.1.3]
>> > >> >>> at
>> > >> >>> org.apache.felix.gogo.runtime.shell.CommandProxy.execute(CommandProxy.java:50)[11:org.apache.karaf.shell.console:2.1.3]
>> > >> >>> at
>> > >> >>> org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:229)[11:org.apache.karaf.shell.console:2.1.3]
>> > >> >>> at
>> > >> >>> org.apache.felix.gogo.runtime.shell.Closure.executeStatement(Closure.java:162)[11:org.apache.karaf.shell.console:2.1.3]
>> > >> >>> at
>> > >> >>> org.apache.felix.gogo.runtime.shell.Pipe.run(Pipe.java:101)[11:org.apache.karaf.shell.console:2.1.3]
>> > >> >>> at
>> > >> >>> org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:79)[11:org.apache.karaf.shell.console:2.1.3]
>> > >> >>> at
>> > >> >>> org.apache.felix.gogo.runtime.shell.CommandSessionImpl.execute(CommandSessionImpl.java:71)[11:org.apache.karaf.shell.console:2.1.3]
>> > >> >>> at
>> > >> >>> org.apache.karaf.shell.console.jline.Console.run(Console.java:170)[11:org.apache.karaf.shell.console:2.1.3]
>> > >> >>> at java.lang.Thread.run(Thread.java:662)[:1.6.0_23]
>> > >> >>> Caused by: org.osgi.framework.BundleException: Unresolved constraint in
>> > >> >>> bundle org.apache.servicemix.bundles.saaj-impl [97]: Unable to resolve 97.0:
>> > >> >>> missing requirement [97.0] package;
>> > >> >>> (package=com.sun.org.apache.xerces.internal.dom)
>> > >> >>> at
>> > >> >>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3409)[org.apache.felix.framework-3.0.2.jar:]
>> > >> >>> at
>> > >> >>> org.apache.felix.framework.Felix.startBundle(Felix.java:1709)[org.apache.felix.framework-3.0.2.jar:]
>> > >> >>> at
>> > >> >>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)[org.apache.felix.framework-3.0.2.jar:]
>> > >> >>> at
>> > >> >>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892)[org.apache.felix.framework-3.0.2.jar:]
>> > >> >>> at
>> > >> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:323)[19:org.apache.karaf.features.core:2.1.3]
>> > >> >>> ... 14 more
>> > >> >>>
>> > >> >
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >> Cheers,
>> > >> Guillaume Nodet
>> > >> ------------------------
>> > >> Blog: http://gnodet.blogspot.com/
>> > >> ------------------------
>> > >> Open Source SOA
>> > >> http://fusesource.com
>> > >
>> >
>> >
>> >
>> > --
>> > Cheers,
>> > Guillaume Nodet
>> > ------------------------
>> > Blog: http://gnodet.blogspot.com/
>> > ------------------------
>> > Open Source SOA
>> > http://fusesource.com
>>
>
>
Re: Branching karaf-2.2.x now (Re: Thoughts about Karaf profiles/releases / growing number of dependencies (Re: AW: AW: Problem whenstartingcamel-cxf in karaf)
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Indeed, it could be interesting and give more information to the community.
However it requires some "administrative" work. I can take the lead on this if someone else would like, he's welcome.
Regards
JB
-----Original Message-----
From: Andreas Pieber <an...@gmail.com>
Date: Sat, 5 Feb 2011 13:04:09
To: <de...@karaf.apache.org>; <jb...@nanthrax.net>
Reply-To: dev@karaf.apache.org
Subject: Re: Branching karaf-2.2.x now (Re: Thoughts about Karaf profiles
/releases / growing number of dependencies (Re: AW: AW: Problem when
startingcamel-cxf in karaf)
I don't think that an automated report is sufficient (finally we don't want to
spam the community to death :)). Maybe some kind of "news-letter".
e.g. we branch off 2.2.x; mail to the user group:
we've just branched off 2.2.x and started to stabilize it; latest artifacts are
available via apache-snapshot repo... simply add the following repo to your pom,
change the version to and provide us with feedback
then 2 weeks later:
thanks for all your feedback; we've fixed XX bugs/problems on the release branch
and will start a release about next week; thanks for all your contribution
Also some information like: we've started developing according to 3.x because
we plan some major changes nailed down here: we think karaf requires ...
Everything could be found here...
None of those mails should be longer than 5-7 lines; at least we want the
community to read them :)
I think this shouldn't produce too much overhead for us but help us involving
a broader community and making our (IMHO really good) work @karaf more visibile?
Feel free to correct me if you think I'm wrong ;)
kind regards,
andreas
On Sat, Feb 05, 2011 at 11:50:21AM +0000, Jean-Baptiste Onofré wrote:
> The most important is not the name (RC, M, snapshots or whatever), it's to keep the community aware of the availability of artifacts.
>
> So agree with Andreas, we can still user snapshots and just keep the user informed. Maybe we can send mail of user mailing list when a build is done of Hudson ?
>
> Regards
> JB
> -----Original Message-----
> From: Andreas Pieber <an...@gmail.com>
> Date: Sat, 5 Feb 2011 12:44:36
> To: <de...@karaf.apache.org>
> Reply-To: dev@karaf.apache.org
> Subject: Re: Branching karaf-2.2.x now (Re: Thoughts about Karaf profiles /
> releases / growing number of dependencies (Re: AW: AW: Problem when starting
> camel-cxf in karaf)
>
> One "aftermatch" message to this thread. You're right, the snapshots should be
> sufficient. But one thing here, WDYT about informing a broader community (e.g.
> via user list too) that we've started branching off a specific x.X version and
> stabilizing it and that we would welcome testing and feedback on the branch
> during the next 2-3 stabilization weeks?
>
> kind regards,
> andreas
>
> On Fri, Feb 04, 2011 at 07:05:36AM +0100, Guillaume Nodet wrote:
> > If there are no objections, I'll branch karaf-2.2.x now in order to
> > get the release stabilized as suggested by Andreas.
> > This means any new development will occur in trunk which will moved to
> > 2.99.99-SNAPSHOT ?
> >
> > On Fri, Feb 4, 2011 at 04:34, Andreas Pieber <an...@gmail.com> wrote:
> > > OK, there are many points in my head about this for some time now and I hope I
> > > get them out straight here. If I'm not able to make any of my points clear don't
> > > hesitate to ask :)
> > >
> > > First of all I'm completely with Guillaume. I don't like the way Karaf blows
> > > up. We have a standard and an enterprise distribution and a minimal distribution
> > > and in future one for android... STOP. I think this is not the way Karaf should go.
> > >
> > > In addition, tbh I also don't like the way client projects (such as smx) have to
> > > tweak Karaf around to make it runnable. This makes everything complex and not
> > > easy to use understand/start with.
> > >
> > > Next I think the root of all evil are our configuration files. The need that we
> > > have to tweak system.properties, custom.properties, jre.properties,
> > > org...features.cfg to get a running, custom distribution. This does not feel
> > > right.
> > >
> > > Fourth: I don't like that we need to use our own maven plugins to build Karaf is
> > > IMHO a sign that Karaf is becoming much too big...
> > >
> > > Last but not least, I hate that I have to google for all those feature urls
> > > and collect them locally to not forgetting them :)
> > >
> > > OK, so far to the problems. According to the mails I've read by now I think I'm
> > > not the only one aware of those problems :) --> I would propose some roadmap
> > > to get this straight again:
> > >
> > > 1) branch off karaf-2.x branch now (independent of the missing versions) and
> > > stay as it is now. Some ppl already depend on karaf-2.1.99-SNAPSHOT and I don't
> > > think that we'll make friends if we make any drastically changes to this
> > > version.
> > >
> > > 2) Start developing karaf-2.99.99-SNAPSHOT right now.
> > >
> > > 3) As a first step I think we should add something like an online registry to
> > > Karaf where feature files could be found. E.g. something like
> > > karaf.apache.org/registry.xml. This would allow us to make Karaf behave the same
> > > without having to pack everything together during assembly phase. Here it may
> > > also help to add a features:addregistryurl command allowing clients to host
> > > their own registries.
> > >
> > > 4) Move enterprise.features.xml into aries project, split standard.features.xml
> > > into the different projects: karaf-obr, karaf-ssh, ops4j-web (e.g. with jetty),
> > > spring2, spring3, ... and create own projects for the additional components. I'm
> > > with Jamie that this will complex the release process, but IMHO everything we
> > > create features files for shouldn't be in the core. As said somehow I even don't
> > > like that we have features.xml in the core at all. All those features.xml have
> > > to be added to the registry. This way we could guarantee that Karaf still
> > > behaves the same although we've reduced the core packages/repo/distribution.
> > >
> > > 5) We have to extend the kar/features.xml model drastically adding variation
> > > points for the different configuration possibilities in Karaf. E.g. we need a
> > > variation point for lib, jre.properties, etc/(to add additional property files),
> > > system (where we drop additional .jre bundles, ...), brandings, ... With that some variation
> > > points require Karaf to reboot (we couldn't change everything at runtime). Which
> > > means we have to cache the changes and apply them on reboot. In addition I know
> > > that there will be some pain in config file merging, but I think this will be
> > > worth the effort.
> > >
> > > 6) Now that we've removed all the specific things from Karaf we can reduce the
> > > build process completely to one minimal distribution of Karaf (at maximum one
> > > additional for android?!) without using the features concepts directly in the
> > > kernel. This will also allow us to develop the karaf-maven-plugin directly in
> > > the kernel without the burden of forking the process anywhere.
> > >
> > > 7) I think by that we're almost finished now. We can start contributing
> > > features/kar packages for cxf, apache ds, camel, ... and add them again to the
> > > registry. For this process the karaf-maven-plugin could/should be used.
> > >
> > > 8) Now a user will first of all create its own kar/features which tweak the
> > > kernel as required. Finally he can either provide the kar/features bundle only.
> > > The assembly process will (and should) always look like (reduced):
> > >
> > > karaf-maven-plugin
> > > execution: distribution
> > > kar-list (branding, docs, ... everything is a kar file, nothing more here)
> > >
> > > IMHO with all of this we can finally provide only one very small distribution.
> > > Someone only experimenting/developing can do a
> > >
> > > features:install war, cfx, ds
> > > admin:reboot
> > >
> > > Everyone else can create distributions as he likes.
> > >
> > > OK, I know that not all of those points are new or exclusively by me, some go a
> > > little bit a different direction than discussed by now and not all of them are
> > > nailed down to the latest detail (by now). Please don't flame me because of this;
> > > I know that this is not the only way to go but it somehow feels right to me :)
> > >
> > > so... wdyt?
> > >
> > > kind regards,
> > > andreas
> > >
> > > On Fri, Feb 04, 2011 at 12:07:42AM +0100, Guillaume Nodet wrote:
> > >> 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
> > >> >>>
> > >> >>>
> > >> >>> -----Ursprüngliche Nachricht-----
> > >> >>> Von: Christian Schneider [mailto:cschneider@talend.com]
> > >> >>> Gesendet: Mittwoch, 2. Februar 2011 09:52
> > >> >>> An: users@camel.apache.org
> > >> >>> Betreff: Problem when starting camel-cxf in karaf
> > >> >>>
> > >> >>> Hi all,
> > >> >>>
> > >> >>> I am trying to run Apache Camel (feature camel-cxf) in Apache Karaf.
> > >> >>>
> > >> >>> I am using a fresh Karaf 2.1.3 download.
> > >> >>> I start karaf and enter:
> > >> >>>
> > >> >>>> features:addurl
> > >> >>>> mvn:org.apache.camel.karaf/apache-camel/2.6.0/xml/features
> > >> >>>> features:install camel-cxf
> > >> >>>
> > >> >>> I get an exception while starting
> > >> >>> org.apache.servicemix.bundles.saaj-impl:
> > >> >>> Unable to resolve 97.0: missing requirement [97.0] package;
> > >> >>> (package=com.sun.org.apache.xerces.internal.dom)
> > >> >>>
> > >> >>> Any idea what I am doing wrong?
> > >> >>>
> > >> >>> Christian
> > >> >>>
> > >> >>> ----------------------
> > >> >>>
> > >> >>> 02.02.2011 09:46:08 org.apache.karaf.main.SimpleFileLock lock
> > >> >>> INFO: locking
> > >> >>> 09:46:09,765 | INFO | FelixStartLevel | jmx
> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
> > >> >>> 0.2.0.incubating | Starting JMX OSGi agent
> > >> >>> 09:46:09,781 | INFO | FelixStartLevel | jmx
> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
> > >> >>> 0.2.0.incubating | Registering MBean with ObjectName
> > >> >>> [osgi.compendium:service=cm,version=1.3] for service with service.id [10]
> > >> >>> 09:46:09,796 | WARN | rint Extender: 3 | BlueprintContainerImpl
> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.features.command is waiting for
> > >> >>> namespace handlers
> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> > >> >>> 09:46:09,796 | WARN | rint Extender: 2 | BlueprintContainerImpl
> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.osgi is waiting for
> > >> >>> namespace handlers
> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> > >> >>> 09:46:09,796 | WARN | JMX OSGi Agent | jmx
> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
> > >> >>> 0.2.0.incubating | There are no MBean servers registred, can't register
> > >> >>> MBeans
> > >> >>> 09:46:09,890 | WARN | rint Extender: 2 | BlueprintContainerImpl
> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.console is waiting for
> > >> >>> namespace handlers
> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0))]
> > >> >>> 09:46:09,968 | WARN | rint Extender: 2 | BlueprintContainerImpl
> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.dev is waiting for
> > >> >>> namespace handlers
> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> > >> >>> 09:46:10,218 | WARN | rint Extender: 3 | BlueprintContainerImpl
> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.ssh is waiting for
> > >> >>> namespace handlers
> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> > >> >>> 09:46:10,234 | WARN | rint Extender: 3 | BlueprintContainerImpl
> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.admin.command is waiting for
> > >> >>> namespace handlers
> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> > >> >>> 09:46:10,250 | WARN | rint Extender: 3 | BlueprintContainerImpl
> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.commands is waiting for
> > >> >>> namespace handlers
> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> > >> >>> 09:46:10,375 | WARN | rint Extender: 2 | BlueprintContainerImpl
> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.packages is waiting for
> > >> >>> namespace handlers
> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> > >> >>> 09:46:11,609 | INFO | Thread-5 | FeaturesServiceImpl
> > >> >>> | res.internal.FeaturesServiceImpl 293 | 19 -
> > >> >>> org.apache.karaf.features.core - 2.1.3 | Bundles to refresh:
> > >> >>> 09:46:11,640 | INFO | rint Extender: 3 | SecurityUtils
> > >> >>> | e.sshd.common.util.SecurityUtils 80 | 25 - sshd-core - 0.4.0 |
> > >> >>> BouncyCastle not registered, using the default JCE provider
> > >> >>> 09:46:11,968 | INFO | JMX OSGi Agent | jmx
> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
> > >> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.BundleStateMBean to
> > >> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
> > >> >>> osgi.core:type=bundleState,version=1.5
> > >> >>> 09:46:12,000 | INFO | JMX OSGi Agent | jmx
> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
> > >> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.ServiceStateMBean to
> > >> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
> > >> >>> osgi.core:type=serviceState,version=1.5
> > >> >>> 09:46:12,000 | INFO | JMX OSGi Agent | jmx
> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
> > >> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.FrameworkMBean to
> > >> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
> > >> >>> osgi.core:type=framework,version=1.5
> > >> >>> 09:46:12,031 | INFO | JMX OSGi Agent | jmx
> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
> > >> >>> 0.2.0.incubating | Registering
> > >> >>> org.osgi.jmx.service.cm.ConfigurationAdminMBean to MBeanServer
> > >> >>> com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
> > >> >>> osgi.compendium:service=cm,version=1.3
> > >> >>> 09:46:12,031 | INFO | JMX OSGi Agent | jmx
> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
> > >> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.PackageStateMBean to
> > >> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
> > >> >>> osgi.core:type=packageState,version=1.5
> > >> >>> 09:48:08,234 | INFO | l Console Thread | FeaturesServiceImpl
> > >> >>> | res.internal.FeaturesServiceImpl 293 | 19 -
> > >> >>> org.apache.karaf.features.core - 2.1.3 | Bundles to refresh:
> > >> >>> 09:48:08,656 | INFO | l Console Thread | ContextLoaderListener
> > >> >>> | .activator.ContextLoaderListener 356 | 44 -
> > >> >>> org.springframework.osgi.extender - 1.2.0 | Starting
> > >> >>> [org.springframework.osgi.extender] bundle v.[1.2.0]
> > >> >>> 09:48:08,781 | INFO | l Console Thread | ExtenderConfiguration
> > >> >>> | al.support.ExtenderConfiguration 150 | 44 -
> > >> >>> org.springframework.osgi.extender - 1.2.0 | No custom extender configuration
> > >> >>> detected; using defaults...
> > >> >>> 09:48:08,781 | INFO | l Console Thread | TimerTaskExecutor
> > >> >>> | heduling.timer.TimerTaskExecutor 106 | 38 - org.springframework.context
> > >> >>> - 3.0.5.RELEASE | Initializing Timer
> > >> >>> 09:48:09,281 | INFO | l Console Thread | Activator
> > >> >>> | apache.camel.impl.osgi.Activator 83 | 51 - org.apache.camel.camel-core
> > >> >>> - 2.6.0 | Camel activator starting
> > >> >>> 09:48:09,312 | INFO | l Console Thread | Activator
> > >> >>> | apache.camel.impl.osgi.Activator 86 | 51 - org.apache.camel.camel-core
> > >> >>> - 2.6.0 | Camel activator started
> > >> >>> 09:48:10,968 | INFO | l Console Thread | Activator
> > >> >>> | apache.camel.impl.osgi.Activator 90 | 51 - org.apache.camel.camel-core
> > >> >>> - 2.6.0 | Camel activator stopping
> > >> >>> 09:48:10,968 | INFO | l Console Thread | Activator
> > >> >>> | apache.camel.impl.osgi.Activator 92 | 51 - org.apache.camel.camel-core
> > >> >>> - 2.6.0 | Camel activator stopped
> > >> >>> 09:48:11,984 | INFO | l Console Thread | ContextLoaderListener
> > >> >>> | .activator.ContextLoaderListener 449 | 44 -
> > >> >>> org.springframework.osgi.extender - 1.2.0 | Stopping
> > >> >>> [org.springframework.osgi.extender] bundle v.[1.2.0]
> > >> >>> 09:48:11,984 | INFO | l Console Thread | TimerTaskExecutor
> > >> >>> | heduling.timer.TimerTaskExecutor 179 | 38 - org.springframework.context
> > >> >>> - 3.0.5.RELEASE | Cancelling Timer
> > >> >>> 09:48:12,281 | INFO | l Console Thread | Console
> > >> >>> | araf.shell.console.jline.Console 188 | 11 -
> > >> >>> org.apache.karaf.shell.console - 2.1.3 | Exception caught while executing
> > >> >>> command
> > >> >>> java.lang.Exception: Could not start bundle
> > >> >>> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.saaj-impl/1.3.2_1
> > >> >>> in feature(s) camel-cxf-2.6.0: Unresolved constraint in bundle
> > >> >>> org.apache.servicemix.bundles.saaj-impl [97]: Unable to resolve 97.0:
> > >> >>> missing requirement [97.0] package;
> > >> >>> (package=com.sun.org.apache.xerces.internal.dom)
> > >> >>> at
> > >> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:326)[19:org.apache.karaf.features.core:2.1.3]
> > >> >>> at
> > >> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:254)[19:org.apache.karaf.features.core:2.1.3]
> > >> >>> at
> > >> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:250)[19:org.apache.karaf.features.core:2.1.3]
> > >> >>> at
> > >> >>> org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:51)[9:org.apache.karaf.features.command:2.1.3]
> > >> >>> at
> > >> >>> org.apache.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:39)[9:org.apache.karaf.features.command:2.1.3]
> > >> >>> at
> > >> >>> org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[11:org.apache.karaf.shell.console:2.1.3]
> > >> >>> at
> > >> >>> org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[11:org.apache.karaf.shell.console:2.1.3]
> > >> >>> at
> > >> >>> org.apache.felix.gogo.runtime.shell.CommandProxy.execute(CommandProxy.java:50)[11:org.apache.karaf.shell.console:2.1.3]
> > >> >>> at
> > >> >>> org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:229)[11:org.apache.karaf.shell.console:2.1.3]
> > >> >>> at
> > >> >>> org.apache.felix.gogo.runtime.shell.Closure.executeStatement(Closure.java:162)[11:org.apache.karaf.shell.console:2.1.3]
> > >> >>> at
> > >> >>> org.apache.felix.gogo.runtime.shell.Pipe.run(Pipe.java:101)[11:org.apache.karaf.shell.console:2.1.3]
> > >> >>> at
> > >> >>> org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:79)[11:org.apache.karaf.shell.console:2.1.3]
> > >> >>> at
> > >> >>> org.apache.felix.gogo.runtime.shell.CommandSessionImpl.execute(CommandSessionImpl.java:71)[11:org.apache.karaf.shell.console:2.1.3]
> > >> >>> at
> > >> >>> org.apache.karaf.shell.console.jline.Console.run(Console.java:170)[11:org.apache.karaf.shell.console:2.1.3]
> > >> >>> at java.lang.Thread.run(Thread.java:662)[:1.6.0_23]
> > >> >>> Caused by: org.osgi.framework.BundleException: Unresolved constraint in
> > >> >>> bundle org.apache.servicemix.bundles.saaj-impl [97]: Unable to resolve 97.0:
> > >> >>> missing requirement [97.0] package;
> > >> >>> (package=com.sun.org.apache.xerces.internal.dom)
> > >> >>> at
> > >> >>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3409)[org.apache.felix.framework-3.0.2.jar:]
> > >> >>> at
> > >> >>> org.apache.felix.framework.Felix.startBundle(Felix.java:1709)[org.apache.felix.framework-3.0.2.jar:]
> > >> >>> at
> > >> >>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)[org.apache.felix.framework-3.0.2.jar:]
> > >> >>> at
> > >> >>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892)[org.apache.felix.framework-3.0.2.jar:]
> > >> >>> at
> > >> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:323)[19:org.apache.karaf.features.core:2.1.3]
> > >> >>> ... 14 more
> > >> >>>
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Cheers,
> > >> Guillaume Nodet
> > >> ------------------------
> > >> Blog: http://gnodet.blogspot.com/
> > >> ------------------------
> > >> Open Source SOA
> > >> http://fusesource.com
> > >
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
>
Re: Branching karaf-2.2.x now (Re: Thoughts about Karaf profiles
/releases / growing number of dependencies (Re: AW: AW: Problem when
startingcamel-cxf in karaf)
Posted by Andreas Pieber <an...@gmail.com>.
I don't think that an automated report is sufficient (finally we don't want to
spam the community to death :)). Maybe some kind of "news-letter".
e.g. we branch off 2.2.x; mail to the user group:
we've just branched off 2.2.x and started to stabilize it; latest artifacts are
available via apache-snapshot repo... simply add the following repo to your pom,
change the version to and provide us with feedback
then 2 weeks later:
thanks for all your feedback; we've fixed XX bugs/problems on the release branch
and will start a release about next week; thanks for all your contribution
Also some information like: we've started developing according to 3.x because
we plan some major changes nailed down here: we think karaf requires ...
Everything could be found here...
None of those mails should be longer than 5-7 lines; at least we want the
community to read them :)
I think this shouldn't produce too much overhead for us but help us involving
a broader community and making our (IMHO really good) work @karaf more visibile?
Feel free to correct me if you think I'm wrong ;)
kind regards,
andreas
On Sat, Feb 05, 2011 at 11:50:21AM +0000, Jean-Baptiste Onofré wrote:
> The most important is not the name (RC, M, snapshots or whatever), it's to keep the community aware of the availability of artifacts.
>
> So agree with Andreas, we can still user snapshots and just keep the user informed. Maybe we can send mail of user mailing list when a build is done of Hudson ?
>
> Regards
> JB
> -----Original Message-----
> From: Andreas Pieber <an...@gmail.com>
> Date: Sat, 5 Feb 2011 12:44:36
> To: <de...@karaf.apache.org>
> Reply-To: dev@karaf.apache.org
> Subject: Re: Branching karaf-2.2.x now (Re: Thoughts about Karaf profiles /
> releases / growing number of dependencies (Re: AW: AW: Problem when starting
> camel-cxf in karaf)
>
> One "aftermatch" message to this thread. You're right, the snapshots should be
> sufficient. But one thing here, WDYT about informing a broader community (e.g.
> via user list too) that we've started branching off a specific x.X version and
> stabilizing it and that we would welcome testing and feedback on the branch
> during the next 2-3 stabilization weeks?
>
> kind regards,
> andreas
>
> On Fri, Feb 04, 2011 at 07:05:36AM +0100, Guillaume Nodet wrote:
> > If there are no objections, I'll branch karaf-2.2.x now in order to
> > get the release stabilized as suggested by Andreas.
> > This means any new development will occur in trunk which will moved to
> > 2.99.99-SNAPSHOT ?
> >
> > On Fri, Feb 4, 2011 at 04:34, Andreas Pieber <an...@gmail.com> wrote:
> > > OK, there are many points in my head about this for some time now and I hope I
> > > get them out straight here. If I'm not able to make any of my points clear don't
> > > hesitate to ask :)
> > >
> > > First of all I'm completely with Guillaume. I don't like the way Karaf blows
> > > up. We have a standard and an enterprise distribution and a minimal distribution
> > > and in future one for android... STOP. I think this is not the way Karaf should go.
> > >
> > > In addition, tbh I also don't like the way client projects (such as smx) have to
> > > tweak Karaf around to make it runnable. This makes everything complex and not
> > > easy to use understand/start with.
> > >
> > > Next I think the root of all evil are our configuration files. The need that we
> > > have to tweak system.properties, custom.properties, jre.properties,
> > > org...features.cfg to get a running, custom distribution. This does not feel
> > > right.
> > >
> > > Fourth: I don't like that we need to use our own maven plugins to build Karaf is
> > > IMHO a sign that Karaf is becoming much too big...
> > >
> > > Last but not least, I hate that I have to google for all those feature urls
> > > and collect them locally to not forgetting them :)
> > >
> > > OK, so far to the problems. According to the mails I've read by now I think I'm
> > > not the only one aware of those problems :) --> I would propose some roadmap
> > > to get this straight again:
> > >
> > > 1) branch off karaf-2.x branch now (independent of the missing versions) and
> > > stay as it is now. Some ppl already depend on karaf-2.1.99-SNAPSHOT and I don't
> > > think that we'll make friends if we make any drastically changes to this
> > > version.
> > >
> > > 2) Start developing karaf-2.99.99-SNAPSHOT right now.
> > >
> > > 3) As a first step I think we should add something like an online registry to
> > > Karaf where feature files could be found. E.g. something like
> > > karaf.apache.org/registry.xml. This would allow us to make Karaf behave the same
> > > without having to pack everything together during assembly phase. Here it may
> > > also help to add a features:addregistryurl command allowing clients to host
> > > their own registries.
> > >
> > > 4) Move enterprise.features.xml into aries project, split standard.features.xml
> > > into the different projects: karaf-obr, karaf-ssh, ops4j-web (e.g. with jetty),
> > > spring2, spring3, ... and create own projects for the additional components. I'm
> > > with Jamie that this will complex the release process, but IMHO everything we
> > > create features files for shouldn't be in the core. As said somehow I even don't
> > > like that we have features.xml in the core at all. All those features.xml have
> > > to be added to the registry. This way we could guarantee that Karaf still
> > > behaves the same although we've reduced the core packages/repo/distribution.
> > >
> > > 5) We have to extend the kar/features.xml model drastically adding variation
> > > points for the different configuration possibilities in Karaf. E.g. we need a
> > > variation point for lib, jre.properties, etc/(to add additional property files),
> > > system (where we drop additional .jre bundles, ...), brandings, ... With that some variation
> > > points require Karaf to reboot (we couldn't change everything at runtime). Which
> > > means we have to cache the changes and apply them on reboot. In addition I know
> > > that there will be some pain in config file merging, but I think this will be
> > > worth the effort.
> > >
> > > 6) Now that we've removed all the specific things from Karaf we can reduce the
> > > build process completely to one minimal distribution of Karaf (at maximum one
> > > additional for android?!) without using the features concepts directly in the
> > > kernel. This will also allow us to develop the karaf-maven-plugin directly in
> > > the kernel without the burden of forking the process anywhere.
> > >
> > > 7) I think by that we're almost finished now. We can start contributing
> > > features/kar packages for cxf, apache ds, camel, ... and add them again to the
> > > registry. For this process the karaf-maven-plugin could/should be used.
> > >
> > > 8) Now a user will first of all create its own kar/features which tweak the
> > > kernel as required. Finally he can either provide the kar/features bundle only.
> > > The assembly process will (and should) always look like (reduced):
> > >
> > > karaf-maven-plugin
> > > execution: distribution
> > > kar-list (branding, docs, ... everything is a kar file, nothing more here)
> > >
> > > IMHO with all of this we can finally provide only one very small distribution.
> > > Someone only experimenting/developing can do a
> > >
> > > features:install war, cfx, ds
> > > admin:reboot
> > >
> > > Everyone else can create distributions as he likes.
> > >
> > > OK, I know that not all of those points are new or exclusively by me, some go a
> > > little bit a different direction than discussed by now and not all of them are
> > > nailed down to the latest detail (by now). Please don't flame me because of this;
> > > I know that this is not the only way to go but it somehow feels right to me :)
> > >
> > > so... wdyt?
> > >
> > > kind regards,
> > > andreas
> > >
> > > On Fri, Feb 04, 2011 at 12:07:42AM +0100, Guillaume Nodet wrote:
> > >> 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
> > >> >>>
> > >> >>>
> > >> >>> -----Ursprüngliche Nachricht-----
> > >> >>> Von: Christian Schneider [mailto:cschneider@talend.com]
> > >> >>> Gesendet: Mittwoch, 2. Februar 2011 09:52
> > >> >>> An: users@camel.apache.org
> > >> >>> Betreff: Problem when starting camel-cxf in karaf
> > >> >>>
> > >> >>> Hi all,
> > >> >>>
> > >> >>> I am trying to run Apache Camel (feature camel-cxf) in Apache Karaf.
> > >> >>>
> > >> >>> I am using a fresh Karaf 2.1.3 download.
> > >> >>> I start karaf and enter:
> > >> >>>
> > >> >>>> features:addurl
> > >> >>>> mvn:org.apache.camel.karaf/apache-camel/2.6.0/xml/features
> > >> >>>> features:install camel-cxf
> > >> >>>
> > >> >>> I get an exception while starting
> > >> >>> org.apache.servicemix.bundles.saaj-impl:
> > >> >>> Unable to resolve 97.0: missing requirement [97.0] package;
> > >> >>> (package=com.sun.org.apache.xerces.internal.dom)
> > >> >>>
> > >> >>> Any idea what I am doing wrong?
> > >> >>>
> > >> >>> Christian
> > >> >>>
> > >> >>> ----------------------
> > >> >>>
> > >> >>> 02.02.2011 09:46:08 org.apache.karaf.main.SimpleFileLock lock
> > >> >>> INFO: locking
> > >> >>> 09:46:09,765 | INFO | FelixStartLevel | jmx
> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
> > >> >>> 0.2.0.incubating | Starting JMX OSGi agent
> > >> >>> 09:46:09,781 | INFO | FelixStartLevel | jmx
> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
> > >> >>> 0.2.0.incubating | Registering MBean with ObjectName
> > >> >>> [osgi.compendium:service=cm,version=1.3] for service with service.id [10]
> > >> >>> 09:46:09,796 | WARN | rint Extender: 3 | BlueprintContainerImpl
> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.features.command is waiting for
> > >> >>> namespace handlers
> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> > >> >>> 09:46:09,796 | WARN | rint Extender: 2 | BlueprintContainerImpl
> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.osgi is waiting for
> > >> >>> namespace handlers
> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> > >> >>> 09:46:09,796 | WARN | JMX OSGi Agent | jmx
> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
> > >> >>> 0.2.0.incubating | There are no MBean servers registred, can't register
> > >> >>> MBeans
> > >> >>> 09:46:09,890 | WARN | rint Extender: 2 | BlueprintContainerImpl
> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.console is waiting for
> > >> >>> namespace handlers
> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0))]
> > >> >>> 09:46:09,968 | WARN | rint Extender: 2 | BlueprintContainerImpl
> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.dev is waiting for
> > >> >>> namespace handlers
> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> > >> >>> 09:46:10,218 | WARN | rint Extender: 3 | BlueprintContainerImpl
> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.ssh is waiting for
> > >> >>> namespace handlers
> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> > >> >>> 09:46:10,234 | WARN | rint Extender: 3 | BlueprintContainerImpl
> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.admin.command is waiting for
> > >> >>> namespace handlers
> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> > >> >>> 09:46:10,250 | WARN | rint Extender: 3 | BlueprintContainerImpl
> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.commands is waiting for
> > >> >>> namespace handlers
> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> > >> >>> 09:46:10,375 | WARN | rint Extender: 2 | BlueprintContainerImpl
> > >> >>> | container.BlueprintContainerImpl 252 | 7 - org.apache.aries.blueprint -
> > >> >>> 0.2.0.incubating | Bundle org.apache.karaf.shell.packages is waiting for
> > >> >>> namespace handlers
> > >> >>> [(&(objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service.blueprint.namespace=http://karaf.apache.org/xmlns/shell/v1.0.0))]
> > >> >>> 09:46:11,609 | INFO | Thread-5 | FeaturesServiceImpl
> > >> >>> | res.internal.FeaturesServiceImpl 293 | 19 -
> > >> >>> org.apache.karaf.features.core - 2.1.3 | Bundles to refresh:
> > >> >>> 09:46:11,640 | INFO | rint Extender: 3 | SecurityUtils
> > >> >>> | e.sshd.common.util.SecurityUtils 80 | 25 - sshd-core - 0.4.0 |
> > >> >>> BouncyCastle not registered, using the default JCE provider
> > >> >>> 09:46:11,968 | INFO | JMX OSGi Agent | jmx
> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
> > >> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.BundleStateMBean to
> > >> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
> > >> >>> osgi.core:type=bundleState,version=1.5
> > >> >>> 09:46:12,000 | INFO | JMX OSGi Agent | jmx
> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
> > >> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.ServiceStateMBean to
> > >> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
> > >> >>> osgi.core:type=serviceState,version=1.5
> > >> >>> 09:46:12,000 | INFO | JMX OSGi Agent | jmx
> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
> > >> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.FrameworkMBean to
> > >> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
> > >> >>> osgi.core:type=framework,version=1.5
> > >> >>> 09:46:12,031 | INFO | JMX OSGi Agent | jmx
> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
> > >> >>> 0.2.0.incubating | Registering
> > >> >>> org.osgi.jmx.service.cm.ConfigurationAdminMBean to MBeanServer
> > >> >>> com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
> > >> >>> osgi.compendium:service=cm,version=1.3
> > >> >>> 09:46:12,031 | INFO | JMX OSGi Agent | jmx
> > >> >>> | ? ? | 20 - org.apache.aries.jmx -
> > >> >>> 0.2.0.incubating | Registering org.osgi.jmx.framework.PackageStateMBean to
> > >> >>> MBeanServer com.sun.jmx.mbeanserver.JmxMBeanServer@6e3d60 with name
> > >> >>> osgi.core:type=packageState,version=1.5
> > >> >>> 09:48:08,234 | INFO | l Console Thread | FeaturesServiceImpl
> > >> >>> | res.internal.FeaturesServiceImpl 293 | 19 -
> > >> >>> org.apache.karaf.features.core - 2.1.3 | Bundles to refresh:
> > >> >>> 09:48:08,656 | INFO | l Console Thread | ContextLoaderListener
> > >> >>> | .activator.ContextLoaderListener 356 | 44 -
> > >> >>> org.springframework.osgi.extender - 1.2.0 | Starting
> > >> >>> [org.springframework.osgi.extender] bundle v.[1.2.0]
> > >> >>> 09:48:08,781 | INFO | l Console Thread | ExtenderConfiguration
> > >> >>> | al.support.ExtenderConfiguration 150 | 44 -
> > >> >>> org.springframework.osgi.extender - 1.2.0 | No custom extender configuration
> > >> >>> detected; using defaults...
> > >> >>> 09:48:08,781 | INFO | l Console Thread | TimerTaskExecutor
> > >> >>> | heduling.timer.TimerTaskExecutor 106 | 38 - org.springframework.context
> > >> >>> - 3.0.5.RELEASE | Initializing Timer
> > >> >>> 09:48:09,281 | INFO | l Console Thread | Activator
> > >> >>> | apache.camel.impl.osgi.Activator 83 | 51 - org.apache.camel.camel-core
> > >> >>> - 2.6.0 | Camel activator starting
> > >> >>> 09:48:09,312 | INFO | l Console Thread | Activator
> > >> >>> | apache.camel.impl.osgi.Activator 86 | 51 - org.apache.camel.camel-core
> > >> >>> - 2.6.0 | Camel activator started
> > >> >>> 09:48:10,968 | INFO | l Console Thread | Activator
> > >> >>> | apache.camel.impl.osgi.Activator 90 | 51 - org.apache.camel.camel-core
> > >> >>> - 2.6.0 | Camel activator stopping
> > >> >>> 09:48:10,968 | INFO | l Console Thread | Activator
> > >> >>> | apache.camel.impl.osgi.Activator 92 | 51 - org.apache.camel.camel-core
> > >> >>> - 2.6.0 | Camel activator stopped
> > >> >>> 09:48:11,984 | INFO | l Console Thread | ContextLoaderListener
> > >> >>> | .activator.ContextLoaderListener 449 | 44 -
> > >> >>> org.springframework.osgi.extender - 1.2.0 | Stopping
> > >> >>> [org.springframework.osgi.extender] bundle v.[1.2.0]
> > >> >>> 09:48:11,984 | INFO | l Console Thread | TimerTaskExecutor
> > >> >>> | heduling.timer.TimerTaskExecutor 179 | 38 - org.springframework.context
> > >> >>> - 3.0.5.RELEASE | Cancelling Timer
> > >> >>> 09:48:12,281 | INFO | l Console Thread | Console
> > >> >>> | araf.shell.console.jline.Console 188 | 11 -
> > >> >>> org.apache.karaf.shell.console - 2.1.3 | Exception caught while executing
> > >> >>> command
> > >> >>> java.lang.Exception: Could not start bundle
> > >> >>> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.saaj-impl/1.3.2_1
> > >> >>> in feature(s) camel-cxf-2.6.0: Unresolved constraint in bundle
> > >> >>> org.apache.servicemix.bundles.saaj-impl [97]: Unable to resolve 97.0:
> > >> >>> missing requirement [97.0] package;
> > >> >>> (package=com.sun.org.apache.xerces.internal.dom)
> > >> >>> at
> > >> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:326)[19:org.apache.karaf.features.core:2.1.3]
> > >> >>> at
> > >> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:254)[19:org.apache.karaf.features.core:2.1.3]
> > >> >>> at
> > >> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:250)[19:org.apache.karaf.features.core:2.1.3]
> > >> >>> at
> > >> >>> org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:51)[9:org.apache.karaf.features.command:2.1.3]
> > >> >>> at
> > >> >>> org.apache.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:39)[9:org.apache.karaf.features.command:2.1.3]
> > >> >>> at
> > >> >>> org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:38)[11:org.apache.karaf.shell.console:2.1.3]
> > >> >>> at
> > >> >>> org.apache.felix.gogo.commands.basic.AbstractCommand.execute(AbstractCommand.java:35)[11:org.apache.karaf.shell.console:2.1.3]
> > >> >>> at
> > >> >>> org.apache.felix.gogo.runtime.shell.CommandProxy.execute(CommandProxy.java:50)[11:org.apache.karaf.shell.console:2.1.3]
> > >> >>> at
> > >> >>> org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:229)[11:org.apache.karaf.shell.console:2.1.3]
> > >> >>> at
> > >> >>> org.apache.felix.gogo.runtime.shell.Closure.executeStatement(Closure.java:162)[11:org.apache.karaf.shell.console:2.1.3]
> > >> >>> at
> > >> >>> org.apache.felix.gogo.runtime.shell.Pipe.run(Pipe.java:101)[11:org.apache.karaf.shell.console:2.1.3]
> > >> >>> at
> > >> >>> org.apache.felix.gogo.runtime.shell.Closure.execute(Closure.java:79)[11:org.apache.karaf.shell.console:2.1.3]
> > >> >>> at
> > >> >>> org.apache.felix.gogo.runtime.shell.CommandSessionImpl.execute(CommandSessionImpl.java:71)[11:org.apache.karaf.shell.console:2.1.3]
> > >> >>> at
> > >> >>> org.apache.karaf.shell.console.jline.Console.run(Console.java:170)[11:org.apache.karaf.shell.console:2.1.3]
> > >> >>> at java.lang.Thread.run(Thread.java:662)[:1.6.0_23]
> > >> >>> Caused by: org.osgi.framework.BundleException: Unresolved constraint in
> > >> >>> bundle org.apache.servicemix.bundles.saaj-impl [97]: Unable to resolve 97.0:
> > >> >>> missing requirement [97.0] package;
> > >> >>> (package=com.sun.org.apache.xerces.internal.dom)
> > >> >>> at
> > >> >>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3409)[org.apache.felix.framework-3.0.2.jar:]
> > >> >>> at
> > >> >>> org.apache.felix.framework.Felix.startBundle(Felix.java:1709)[org.apache.felix.framework-3.0.2.jar:]
> > >> >>> at
> > >> >>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:905)[org.apache.felix.framework-3.0.2.jar:]
> > >> >>> at
> > >> >>> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:892)[org.apache.felix.framework-3.0.2.jar:]
> > >> >>> at
> > >> >>> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:323)[19:org.apache.karaf.features.core:2.1.3]
> > >> >>> ... 14 more
> > >> >>>
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Cheers,
> > >> Guillaume Nodet
> > >> ------------------------
> > >> Blog: http://gnodet.blogspot.com/
> > >> ------------------------
> > >> Open Source SOA
> > >> http://fusesource.com
> > >
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
>