[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[mdt-ocl.dev] URIs for next MDT-OCL release
|
Kenn Hussey wrote in the "Backwards compatibility for MDT OCL" thread
You want to make sure that it is possible for both versions to
co-exist in the same environment. The fact that the Ecore packages
will have different version numbers in their URIs will help, and
assuming you're making use of content types instead of file extensions
for serialized artifacts (are there any?) you should be OK.
[OCL serialisations probably only exist within the context of QVT
Declarative JUnit tests since a derived language is necessary to provide
a context for synthesised artefacts. Once QVT Declarative is fit for use
com,piled artefacts may reference the OCL URI. Similarly for QVT
Operational once it migrates to the QVT Declarative version of the OMG
meta-models.]
How can both MDT-OCL 1.4.0 and 3.0.0 co-exist URI-wise?
MDT-OCL 1.4.0 provides the traditional plugin registration of the
"http://www.eclipse.org/ocl/1.1.0/Ecore"; URI and associated Java packages.
MDT-OCL 3.0.0 must not provide a registration of the
"http://www.eclipse.org/ocl/1.1.0/Ecore"; to avoid offering conflicting
Java packages.
MDT-OCL 3.0.0 must therefore support serialisations referencing the
earlier "http://www.eclipse.org/ocl/1.1.0/Ecore"; URI via a URI mapping
to "http://www.eclipse.org/ocl/3.0.0/Ecore";.
Imagine an application A that depends on B and C, and that B depends on
MDT-OCL 1.4.0 and C depends on MDT-OCL 3.0.0. Hopefully distinct plugin
class loaders ensure that B resolves
"http://www.eclipse.org/ocl/1.1.0/Ecore"; and associated classes to
MDT-OCL 1.4.0, while C resolves "http://www.eclipse.org/ocl/1.1.0/Ecore";
via the URI mapping to the MDT-OCL 3.0.0 classes.
Regards
Ed Willink
