[mdt-ocl.dev] OCL.initialize API 'changes'

[edwillink+ed <ed@xxxxxxxxxxxxx>]

Hi

We 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.initialize

for Ecore/UML/Pivot eliminating all definition of plugin locations from 
launch configurations?

    Regards

        Ed Willink