>> 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 OSGi you need to control
> versioning in MANIFEST.MF files
> and then suddenly you need to do this specially for Camel?
>What
> happens when your bundle (which contains the camel xml route)
> has X version of Camel in MANIFEST.MF and then schema version have
> version Y? You need to keep them in sync?

I would attempt to avoid this situation by ensuring that the
schema is present in the Camel OSGi bundle, basically
tying it to the declared bundle version, then the  Camel build
can keep them in sync.

> If this is the only solution then the people working on 3rd party
> tooling such as Fuse Integration Designer needs to be aware of this so
> they can add tooling support
> for specifying Camel versions in the XML files.

With Eclipse at least, versioning in the namespace is the best
way to go, because then there's no clash when we register the
schema with the XML catalog extension (for editing), plus all
we need to do is pull that namespace and key off the version
at the end to choose EIP diagram validation strategies and
deployment capabilities...

 cheers
  --oh

Reply via email to