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 set:
/Users/davsclaus/workspace/camel/tests/test-bundles/mock-javamail_1.7/target
(included: [**], excluded: [])
[INFO] [dependency:copy {execution: copy-legal}]
[INFO] Configured Artifact: org.apache.servicemix.legal:legal:1.0:xml
[INFO] Copying legal-1.0.xml to
/Users/davsclaus/workspace/camel/tests/test-bundles/mock-javamail_1.7/target/legal/legal.xml
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 6 resources
[INFO] Copying 3 resources
[INFO] [compiler:compile]
[INFO] Compiling 3 source files to
/Users/davsclaus/workspace/camel/tests/test-bundles/mock-javamail_1.7/target/classes
[INFO] [resources:testResources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/Users/davsclaus/workspace/camel/tests/test-bundles/mock-javamail_1.7/src/test/resources
[INFO] Copying 3 resources
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] Tests are skipped.
[INFO] [bundle:bundle]
[ERROR] Error building bundle
org.apache.camel.tests:org.apache.camel.tests.mock-javamail_1.7:bundle:2.1-SNAPSHOT
: No value after '=' sign for attribute version
[ERROR] Error(s) found in bundle configuration
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error(s) found in bundle configuration
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7 minutes 3 seconds
[INFO] Finished at: Thu Sep 17 09:58:42 CEST 2009
[INFO] Final Memory: 121M/216M
[INFO] ------------------------------------------------------------------------
On Thu, Sep 17, 2009 at 9:19 AM, Guillaume Nodet <gno...@gmail.com> wrote:
> 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
> into the Karaf deploy folder.
>
> Now the question is: how can I choose which version of camel I want to
> run for my route ?
> I guess part of the problem is that the schema are the same and both
> spring namespace handlers use the same schema.
> I've forced the generated bundle to be wired to camel 2.1, but spring
> was still using the 1.6 schema handler to load the route which was
> failing because of a missing component.
>
> I think we're missing some kind of versioning in the schema ...
> Thoughts ?
>
> On Fri, Sep 4, 2009 at 10:22, Guillaume Nodet <gno...@gmail.com> wrote:
>> I've spotted a few problems in the way the OSGi metadata for camel jars are
>> computed.
>> This makes deploying two versions of camel in OSGi nearly impossible.
>> To fix, I plan to enhance the metadata in two ways:
>>
>> #1. bundles should not import the packages they export
>> Here's an example what happen when you do so:
>> * install bundle A version vx that export foo.bar and import it
>> the OSGi framework will decide that A export this package because no
>> other package is available
>> * install the same bundle in version vy
>> as some of the packages are already exported by the first version of A,
>> the OSGi resolver may choose
>> to have this bundle import the package in version vx (provided that the
>> version constraints match)
>> this means that this bundle will not use its own classes for all the
>> packages that are in common, leading
>> to obvious problems
>> So not importing the package means that the OSGi framework will always use
>> the classes from inside the bundle.
>>
>> #2. always use version ranges
>> * For non camel imports, I think the default should be to have a range
>> equal to [v,v+1) assuming backward compatibility is preserved on minor
>> releases. So if one bundle has a dependency on foo.bar version 1.1, the
>> range will be [1.1,2) meaning the framework is allowed to choose any package
>> with a version >= 1.1 but < 2.0
>> * for camel imports, this is a bit trickier. I think the default range
>> should be restricted to minor versions, i.e. [1.1,1.2)
>>
>> The problem here is to allow someone to update a camel component or core
>> without updating the whole camel jars, so we need some flexibility on this
>> range. But usually, I don't think we really ensure full backward
>> compatibility between minor versions, so having [2.0,3) might not be a good
>> idea.
>> Furthermore, this would mean that you can't really deploy two different
>> minor versions of camel in the same framework, which I think is desirable.
>>
>> Now, the tricky part is to make sure that we always use consistent classes.
>> For example when camel-core discover a component, we don't really want
>> camel-core 1.4 discovering camel 2.0 components, as this would fail. So
>> the discovery mechanism has to be enhanced to make sure we load compatible
>> classes.
>> In OSGi, this can be done by loading a class from the component bundle and
>> making sure it's the same as our.
>> For example:
>> componentBundle.loadClass(org.apache.camel.Endpoint.class.getName()) ==
>> org.apache.camel.Endpoint.class
>> This way, the discovery mechanism will be retricted to components that are
>> actually wired to this camel-core bundle.
>>
>> So at the end we should be able to:
>> * deploy multiple versions of camel, provided they have different minor
>> releases (ex: 1.4, 2.0, 2.1)
>> * upgrade components / core with micro release (ex: camel-core 2.0,
>> camel-spring 2.0.2, camel-atom 2.0.1)
>> And everything should work nicely :-)
>>
>> I'll start updating the OSGi metadata, but any help would be welcome, as
>> there are tons of components here !
>> Also, any volunteer for upgrading and testing the discovery mechanism is
>> welcomed !
>>
>> --
>> 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
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
