On Thu, Oct 4, 2012 at 5:36 PM, James Carman wrote:
> Has there been a release of the software before? If so, and you are
> changing the maven coordinates, then you could run into class path
> collisions
Hi James,
These are only the Esper examples. You don't (at least you shouldn't)
include them
> Sorry but preparation for my travel takes more time than i expected. I will
> perform release in a few days.
I've staged the release [1] at Sonatype Nexus.
The Camel Extra version in the trunk is 2.10.1-SNAPSHOT now (I think
we might release it soon as well).
You're welcome to take a look at t
No hurry...
Best,
Christian
On Sat, Oct 6, 2012 at 6:57 PM, Henryk Konsek wrote:
> Sorry but preparation for my travel takes more time than i expected. I will
> perform release in a few days.
> 05-10-2012 01:00 użytkownik "Christian Müller" <
> christian.muel...@gmail.com>
> napisał:
>
> > Go a
I give it a try it's two changed imports and one dependeny change in pom of
camel-spring and everything works fine:
import org.eclipse.gemini.blueprint.context.BundleContextAware;
in
apache-camel-2.10.0\components\camel-spring\src\main\java\org\apache\camel\osgi\CamelContextFactoryBean.java
apach
But why not replace spring-osgi since gemini-blueprint is the successor of
spring-osgi and nearly 100% class compatible? As already said camel-spring
depends on a "dead end" called spring-osgi.
Original-Nachricht
> Datum: Tue, 9 Oct 2012 11:03:50 +0200
> Von: Claus Ibsen
> An
On Tue, Oct 9, 2012 at 10:08 AM, Benjamin Graf wrote:
> Hi,
>
> does anybody knows why camel-spring still depends on spring-osgi? This bundle
> is gemini-blueprint since 2009 and won't be developed anymore. This fact
> forces to use an old unsupported bundle if you like camel with spring and
>
I know. That's why I use the jboss osgi module.
Original-Nachricht
> Datum: Tue, 9 Oct 2012 10:39:31 +0200
> Von: Charles Moulliard
> An: dev@camel.apache.org
> Betreff: Re: Dependencies of camel-spring
> Be aware that JBoss Module (
> https://docs.jboss.org/author/display/MODU
Be aware that JBoss Module (
https://docs.jboss.org/author/display/MODULES/Introduction) proposes a
class loading solution which is "modular" based but is not OSGI based and
does not depend on a OSGI container/runtime.
On Tue, Oct 9, 2012 at 10:33 AM, Claus Ibsen wrote:
> This is a JBoss issue a
I'm using JBoss OSGi Container and fails because of an ClassNotFoundException
of spring-osgi which you say should be optional? I don't see something optional
in manifest files.
Original-Nachricht
> Datum: Tue, 9 Oct 2012 10:33:38 +0200
> Von: Claus Ibsen
> An: dev@camel.apache
This is a JBoss issue and not Camel. Because JBoss module loader tries
to load the classes from the org.apache.camel.osgi package which is
optional, and only in use for OSGi runtimes.
On Tue, Oct 9, 2012 at 10:28 AM, Benjamin Graf wrote:
> Well, look at that exception if using camel-spring witho
Well, look at that exception if using camel-spring without spring-osgi
installed!
10:24:16,572 WARN [org.jboss.modules] (ClassLoader Thread) Failed to define
class org.apache.camel.osgi.CamelContextFactoryBean in Module
"deployment.org.apache.camel.camel-spring:2.10.0" from Service Module Load
On Tue, Oct 9, 2012 at 10:08 AM, Benjamin Graf wrote:
> Hi,
>
> does anybody knows why camel-spring still depends on spring-osgi? This bundle
> is gemini-blueprint since 2009 and won't be developed anymore. This fact
> forces to use an old unsupported bundle if you like camel with spring and
>
Hi,
does anybody knows why camel-spring still depends on spring-osgi? This bundle
is gemini-blueprint since 2009 and won't be developed anymore. This fact forces
to use an old unsupported bundle if you like camel with spring and OSGi. :-( I
think it should change whether to create a new camel-g
13 matches
Mail list logo
