On Thu, Sep 17, 2009 at 11:17, Claus Ibsen wrote:
> On Thu, Sep 17, 2009 at 10:55 AM, Guillaume Nodet wrote:
>> I've looked at both spring-dm and blueprint, and there is no way to
>> have a single schema namespace supported by two different handlers.
>> I mean, you can always do that, but you hav
>> Having the schema versioned with 2.1, 2.2, etc sounds good to me.
+1 for versioning the schema - from the tools p.o.v. it
makes life easier as things like XML editors can cope
better with on-the-fly validation and element/attribute
completion options.
> Hmmm so in all other situations with OSG
On Thu, Sep 17, 2009 at 10:55 AM, Guillaume Nodet wrote:
> I've looked at both spring-dm and blueprint, and there is no way to
> have a single schema namespace supported by two different handlers.
> I mean, you can always do that, but you have no way to control which
> one will be used.
> So I gue
I've looked at both spring-dm and blueprint, and there is no way to
have a single schema namespace supported by two different handlers.
I mean, you can always do that, but you have no way to control which
one will be used.
So I guess versionning the schema is the only solution.
Having the schema v
Same here.
On Thu, Sep 17, 2009 at 10:49, Willem Jiang wrote:
> Hi Claus,
>
> The mock-javamail-1.7 building is passed on my box.
> Here is my environment.
>
> Apache Maven 2.2.0 (r788681; 2009-06-26 21:04:01+0800)
> Java version: 1.5.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/
Hi Claus,
The mock-javamail-1.7 building is passed on my box.
Here is my environment.
Apache Maven 2.2.0 (r788681; 2009-06-26 21:04:01+0800)
Java version: 1.5.0_20
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home
Default locale: en_US, platform encoding: MacRoman
OS nam
+1 for adding the version number on the camel-spring namespace.
But I don't know if the "http://camel.apache.org/schema/spring/2.1"; is
enough for use to pick the camel-spring 2.1.x instead of camel 2.1.0.
Willem
Gert Vanthienen wrote:
L.S.,
How about we register the default namespace
"http:
L.S.,
How about we register the default namespace
"http://camel.apache.org/schema/spring"; as well as a version-specific
namespace "http://camel.apache.org/schema/spring/2.1"; with the
namespace handler? If people are only using one version, they can
still use the default namespace and if they wa
On Thu, Sep 17, 2009 at 09:59, Claus Ibsen wrote:
> Hi
>
> This must be an universal problem with OSGi + Spring + Your Apps and
> having multiple versions in same container.
I think it is. I'll have a closer look as the spring-dm code, but I
suspect the only way would be to version the schema co
Right, I missed that. So the point is moot.
But as Claus noted, the problem will also happen between 2.1.x and 2.2.x ...
On Thu, Sep 17, 2009 at 09:52, Willem Jiang wrote:
> Hi Guillaume,
>
> Camel 1.6.x is still using the old namespace for the namespace handler
> "http://activemq.apache.org/cam
Yes, this is because OSGi versioning is strictly defined.
So we need to translate the maven version into an OSGi version.
Usually, the work is done by the maven bundle plugin, but in our case,
it's not completely covered yet, so I had to do a bit of maven-antrun
plugin to do this transformation.
I
On Thu, Sep 17, 2009 at 9:52 AM, Willem Jiang wrote:
> Hi Guillaume,
>
> Camel 1.6.x is still using the old namespace for the namespace handler
> "http://activemq.apache.org/camel/schema/spring";
>
> Can you check if your camel context is updated to new camel namespace
> "http://camel.apache.org/s
Hi
Just wondering about the versions below. I assume its correct that
OSGI is not identical to the maven version?
[INFO] Executing tasks
[echo] Maven version: 2.1-SNAPSHOT
[echo] OSGi version:2.1.0.SNAPSHOT
[mkdir] Created dir: /Users/davsclaus/workspace/camel/tooling/target
This one is failing with a mvn clean install -Dtest=false from camel trunk
[INFO] Building Apache Camel Test Bundles: mock-javamail-1.7
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting file
Hi
This must be an universal problem with OSGi + Spring + Your Apps and
having multiple versions in same container.
For example Mule ESB is also leveraging spring namespace handler and
thus will have same issue. So what are they doing?
Don't you have specified in the bundle that contains the cam
Hi Guillaume,
Camel 1.6.x is still using the old namespace for the namespace handler
"http://activemq.apache.org/camel/schema/spring";
Can you check if your camel context is updated to new camel namespace
"http://camel.apache.org/schema/spring";
Willem
Guillaume Nodet wrote:
Unfortunately, I
Unfortunately, I doubt it will work. The reason is that only the
schema namespace is used to choose the namespace handler, not it's
location, and both namespaces are defined by:
http://camel.apache.org/schema/spring
On Thu, Sep 17, 2009 at 09:31, Charles Moulliard wrote:
> Guillaume,
>
> I t
Guillaume,
I think that you can solve easily the problem by specifying in the xml file,
the version of the camel-spring file
By default, you don't mention it in the schema location and the last ont
will be used (so now 2.0)
xsi:schemaLocation="
http://www.springframework.org/schema/b
Ok, I'm mostly done with the OSGi metadata.
I've committed fixes to both trunk and 1.x branch.
But my original goal is only partially achieved.
I've run some basic tests in Karaf and deployed camel 1.6-SNAPSHOT and
2.1-SNAPSHOT.
Then, I deployed a simple spring-powered camel route and dropped it
i
> So while importing exported packages is fine to reduce class fragmentation,
> this should only be done for substituable packages, such as specifications,
> etc... For jars that don't provide any services, such as libraries
> transformed into OSGi bundles, this should be really avoided.
Of cou
Well, let's take an example: we want to publish a transaction manager
implementing javax.transaction.TransactionManager
To reduce class fragmentation, we want to import / export the
javax.transaction.xa package. This way, if another bundle provides the same
package, our bundle will be wired to t
> #1. bundles should not import the packages they export
This is kindof contrary to what OSGi recommends - that you should
always import what you export to prevent class fragmentation in
consumer bundles.
Full gory details here
http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importin
2009/9/7 Guillaume Nodet :
> Yeah, I was kinda thinking the same. If those bundles are tightly bound
> together, it would make sense to have a single bundle. Too many fine
> grained bundles isn't a good thing either in OSGi.
Agreed! Plus camel-core/spring/osgi are probably the hardest bits to
g
Yeah, I was kinda thinking the same. If those bundles are tightly bound
together, it would make sense to have a single bundle. Too many fine
grained bundles isn't a good thing either in OSGi.
On Mon, Sep 7, 2009 at 09:41, James Strachan wrote:
> Maybe camel-osgi could include camel-core and ca
Maybe camel-osgi could include camel-core and camel-spring in a single bundle?
Folks who don't use spring or osgi can use camel-core; folks can then
add camel-spring if they want - but maybe folks using osgi can have a
single bundle with camel+osgi+spring which is a very common
combination in osgi
I'm not quite sure that this is a good idea to merge camel-core and
camel-spring. Until now, we have three expressions languages :
1) Java DSL : camel-core
2) Spring DSL : camel-spring
3) Scala DSL : camel-scala
...
Even if java and spring DSL are the most used, we have no idea about what
the fut
Hi,
I have a question about merge the camel-spring and camel-osgi together.
Since camel-osgi have some dependency of the OSGi related jar,
Is it possible to let new merged camel-spring jar live with Non-OSGi
environment?
Thanks,
Willem
Claus Ibsen wrote:
On Mon, Sep 7, 2009 at 8:30 AM, Gui
On Mon, Sep 7, 2009 at 8:30 AM, Guillaume Nodet wrote:
> No problems for me. Though I wonder if this reflects something that have
> to be enhanced / modified. If those jars are so closely related, wouldn't
> it make sense to have only one ? I've already suggested merging
> camel-spring and cam
No problems for me. Though I wonder if this reflects something that have
to be enhanced / modified. If those jars are so closely related, wouldn't
it make sense to have only one ? I've already suggested merging
camel-spring and camel-osgi some time ago, but I know wonder if they should
be move
On Fri, Sep 4, 2009 at 11:53 AM, Willem Jiang wrote:
> Because there are some internal API dependencies between the camel-core ,
> camel-spring. I'm not sure if the OSGi version range can help us to find out
> the minor internal API change.
>
Yeah camel-core and camel-spring are really to tightly
I've attached a patch at
https://issues.apache.org/activemq/browse/CAMEL-1988 and put some
instructions on how to change a given component.
FWIW, I haven't had any time to test the whole thing in OSGi, but that may
mean we need to backport that stuff onto camel-1.x branch, at least to test
it.
On
Because there are some internal API dependencies between the camel-core
, camel-spring. I'm not sure if the OSGi version range can help us to
find out the minor internal API change.
Willem
Guillaume Nodet wrote:
On Fri, Sep 4, 2009 at 11:22, Willem Jiang wrote:
+1 for #1,
for the #2, I th
On Fri, Sep 4, 2009 at 11:22, Willem Jiang wrote:
> +1 for #1,
>
> for the #2, I think we could let the component dependent on the version
> ranges of camel-core, camel-spring, camel-osgi.
> But for camel-core, camel-spring and camel-osgi, they should dependent each
> other with specific version.
I don't remember why we use that flag, so feel free to remove it.
But I did have trouble to set the version range (such as import package
of CXF, mina) with that falg set to be true.
Willem
Guillaume Nodet wrote:
Will do. Still working on that.
I'm working on camel-core and camel-spring and
+1 for #1,
for the #2, I think we could let the component dependent on the version
ranges of camel-core, camel-spring, camel-osgi.
But for camel-core, camel-spring and camel-osgi, they should dependent
each other with specific version.
Willem
Guillaume Nodet wrote:
I've spotted a few probl
Will do. Still working on that.
I'm working on camel-core and camel-spring and will commit when I have
something that looks good.
Btw, anyone know why the flag camel.osgi.exclude.dependencies is set to true
?
It seems it makes the maven bundle plugin ignore versions from the
dependencies. Withou
I forget to mention:
camel-osgi,
camel-quickfix,
camel-activemq
I suppose that you will make modifications first with camel-core.
Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer
*
blog : http://cmoulliard.blogspot.com
On Fri, Sep 4, 2009 at 10:
Hi Guillaume,
I have been confronted yesterday to the problem that you describe here
(moving some components from camel 2.0 to 2.1-SNAPSHOT). I prefer to use
version range as they assume also a certain level of compatibility within
release. It means also that before to commit every new change, dev
38 matches
Mail list logo
