|[mdt-ocl.dev] OCL.initialize API 'changes'|
HiWe currently have an uncomfortable need to have a copy of the GIT repo on Hudson. https://bugs.eclipse.org/bugs/show_bug.cgi?id=375640 suggests eliminating this. Builds of branch bug/369123c have successfully done this for the old builds with a trivial bug still outstanding.
Fixing the repo highlights a different inelegance. It is currently necessary for standalone applications to identify the location of critical UML plugins via System properties. These are used by OCL.initialize (Ecore, UML and Pivot) variants.
The MWE2 technology reused in StandaloneProjectMap is able to discover the correct values by a class-path scan. I have temporarily used this in the test harnesses to auto-set the system property for API compatibility. Do we need this?
It seems hard to beleive that any application code successfully works without the UML plugins on the classpath, so I think it is safe to make a semantic API change and just make the system properties redundant, or perhaps just the second choice.
It is perhaps too early to promote the StandaloneProjectMap to org.eclipse.ocl.common, so a klunky 50 line duplicate private subroutine in each OCL seems the least impact. It is also necessary to make a minor change to the UML metamodel URI creations. These currently use URI.createFileURI which fails on the archive paths associated with packed plugins. A trivial change to createURI works. I've temporarily coded a try catch around createFileURI to fall back on createURI and increase compatibility; however if the source is known to be a plugin/project resource file: URIs are not an issue.
So, are there any objections to:a) using a classpath search as the primary standalone OCL.initialize discovery mechanism with the existing System property as a redundant compatibility backstop.
b) changing createFileURI to createURI in OCL.initializefor Ecore/UML/Pivot eliminating all definition of plugin locations from launch configurations?
Regards Ed Willink
Back to the top