search

eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

Provide model registrations to support custom OMG metamodels #2112

Open eclipse-ocl-bot opened 1 week ago

eclipse-ocl-bot commented 1 week ago

| --- | --- | | Bugzilla Link | 562996 | | Status | NEW | | Importance | P3 normal | | Reported | May 09, 2020 03:24 EDT | | Modified | May 10, 2020 03:53 EDT | | See also | 551915 | | Reporter | Ed Willink |

Description

When using a new variant OMG specification, there may well be a suite of necessary registrations. e.g. UMLDI, requires PrimitiveTypes, UML, DC, DI, XMI, MOF

Programmatically (see Bug 551915) these can be provided by URI mappings. But if a *.ocl is exported, it may have locally correct imports, but transitively the non-global missing URI maps fail.

eclipse-ocl-bot commented 1 week ago

By Ed Willink on May 09, 2020 03:54

Options

OCL's 'import' could be generalized to provide a kind of xsi:schemaLocation to map transitive URIs in the prevailing ResourceSet.

This could work for OCL, but won't help other tools, and is a not particularly pleasant generalization. Maybe a different keyword.

A registration plugin's plugin.xml could solve problems in a nested Eclipse; not much help 'now', It could have an installer that zaps the current workspace from plugin.xml; a very naughty installation change that could be slightly mitigated by a matching uninstaller.

An installer/uninstaller could work with just a file if no nested Eclipse auto-install is wanted.

The uninstaller could retain in-memory state to save any need to persist anything.

?? A plugin.xml wizard that offers a checkbox tree of extension points to live install. Probably only support a couple of EMF extensions, unless there is a universal live install approach.

?? If a live install from plugin.xml has a class reference, that class must be (re)loaded from the live project. Ripple, ripple, ripple. Perhaps this is why live install never really happened.

It might be enough to install a new XMI content type which when used installs all the URI mappings.

Distributing a 'template' registration plugin that a user customises with their declarations would at least ensure that everything ran from the correct classpath. Clone plugin, edit registrations select Installer.java and Run As Java App is pretty minimal.

eclipse-ocl-bot commented 1 week ago

By Ed Willink on May 09, 2020 04:53

(In reply to Ed Willink from comment #1)

A registration plugin's plugin.xml could solve problems in a nested Eclipse;

Yes works fine; it's normal functionality.

not much help 'now',

Attempting to re-use plugin.xml live is painful. The natural platform functionality magically loads the plugin.xml as ObjectManager ids; really don't want to mess with those or even try to understand them. Therefore the EMF extension point readers cannot be re-used.

Unfortunately plugin.xml is not an EMF model so it will only be amenable to a naive XML load. A bit painful.

Initially it is probably easier to have duplicate declarations:

a) plugin.xml registrations for nested Eclipse

b) install(ResourceSet) global function to install locally (non-null ResourceSet) / globally (null ResourceSet)

main() calls install(null) for a Run As invocation.

install() can be called programmatically by JUnit tests.

eclipse-ocl-bot commented 1 week ago

By Ed Willink on May 10, 2020 03:53

(In reply to Ed Willink from comment #2)

Initially it is probably easier to have duplicate declarations:

...

main() calls install(null) for a Run As invocation.

No. The global package registry can only be tweaked by installed Eclipse code, so as a minimum an installed action is needed that might use a URLClassLoader to run the user-defined action code.

... But, yet again, this is not an easy tweak for no clear user demad. Kick it into touch and revisit once UML2Pivot is revisited.