Infer namespace URIs from Java blackbox classes

[eclipse-qvt-oml-bot]

| --- | --- | | Bugzilla Link | 565747 | | Status | REOPENED | | Importance | P3 normal | | Reported | Jul 31, 2020 11:50 EDT | | Modified | Feb 19, 2021 13:32 EDT | | Version | 3.4.0 | | See also | Gerrit change 176318, Gerrit change 176317, Gerrit change 176319, Gerrit change 176320, Gerrit change 176321, Gerrit change 176325, Gerrit change 176326 | | Reporter | Christopher Gerking |

Description

Bug 472482 enables Java blackboxes to be defined more conveniently inside the workspace, without registering specific extensions. A remaining limitation is that a blackbox class still requires an explicit indication of any metamodels it should be resolved against. For example, a blackbox method such as

public static String getFullName(EPackage pack) {...}

requires an indication of Ecore, which is then used to resolve the Java Class to the EClass named ecore::EPackage. To that end, blackbox classes require annotations like

@Module(packageURIs={"http://www.eclipse.org/emf/2002/Ecore"})

to specify the namespace URIs of their underlying metamodels. Isn't there a way to get around these annotations? Would it be possible to infer ecore::EPackage directly from the corresponding Class, without an explicit indication of the namespace URI?

[eclipse-qvt-oml-bot]

By Ed Willink on Jul 31, 2020 14:44

Much easier to use a static instance.

e.g.

public static final EPackage ECORE_INSTANCE = EcorePackage.eINSTANCE.

and have the QVTo support search for all public static fields of type EPackage.

(and you get to leverage ordinary Java type checking / refactoring / referemcing)

[eclipse-qvt-oml-bot]

By Christopher Gerking on Aug 06, 2020 08:40

(In reply to Ed Willink from comment #1)

Much easier to use a static instance.

Doesn't help because the @Module annotation was already put in place years ago, and it works. I was looking for a way to get rid of these annotations by inferring the EPackage fully automatically from the Java classes used, without any additional user effort.

For example, if the return type of a Java method is EStructuralFeature, is it somehow possible to infer programmatically that the corresponding EPackage is ecore?

It would be possible to assume that the name of the EPackage matches with the last segment of the Java package name. This works for ecore as the last segment of org.eclipse.emf.ecore, but it's only a rule of thumb.

[eclipse-qvt-oml-bot]

By Ed Willink on Aug 06, 2020 09:08

(In reply to Christopher Gerking from comment #2)

This works for ecore as the last segment of org.eclipse.emf.ecore, but it's only a rule of thumb.

and fails in general since the Classic OCL chose to re-use package names; org.eclipse.ocl.ecore(In reply to Christopher Gerking from comment #2)

Doesn't help because the @Module annotation was already put in place years ago, and it works.

If it really worked, this bug would be a trivial WONTFIX / INVALID.

I was looking for a way to get rid of these annotations by inferring the EPackage fully automatically from the Java classes used, without any additional user effort.

You need to resolve a specific EPackage (i.e. an instance) not just some EPackage as opposed to MyTechnologyAggregate.

You can keep @Module(packageURIs={"http://www.eclipse.org/emf/2002/Ecore"}) as a legacy instance that cannot be reliably resolved at compile time, but support EcorePackage.eINSTANCE which is unambiguous going forward,.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Aug 06, 2020 11:34

(In reply to Ed Willink from comment #3)

and fails in general since the Classic OCL chose to re-use package names; org.eclipse.ocl.ecore

I see.

Just found out that my context provides a local EPackage.Registry, which includes the modeltypes used by the corresponding QVTo file. This is a useful fallback to search if the blackbox itself does not specify its underlying metamodels (much better than searching the global package registry).

If it really worked, this bug would be a trivial WONTFIX / INVALID.

No because this bug is about the user's convenience when developing a blackbox, it was not meant to address reliability. However I agree that declaring an EPackage directly would be more failsafe.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Aug 21, 2020 03:56

(In reply to Christopher Gerking from comment #4)

Just found out that my context provides a local EPackage.Registry, which includes the modeltypes used by the corresponding QVTo file. This is a useful fallback to search if the blackbox itself does not specify its underlying metamodels (much better than searching the global package registry).

Pushed to cgerking/565747. Commit ID: e1b7118ec92c9faa0349f86dce2f9e24ead6f71a

[eclipse-qvt-oml-bot]

By Christopher Gerking on Aug 27, 2020 11:50

Test cases for parser and executor added in commit ba70bc4b6eca7c58fa6a373fd2f8b69420e9424e.

[eclipse-qvt-oml-bot]

Feb 16, 2021 04:49

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/176318

[eclipse-qvt-oml-bot]

Feb 16, 2021 04:49

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/176317

[eclipse-qvt-oml-bot]

Feb 16, 2021 04:49

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/176319

[eclipse-qvt-oml-bot]

Feb 16, 2021 04:56

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/176320

[eclipse-qvt-oml-bot]

Feb 16, 2021 04:56

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/176321

[eclipse-qvt-oml-bot]

Feb 16, 2021 04:57

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/176325

[eclipse-qvt-oml-bot]

Feb 16, 2021 04:57

New Gerrit change created: https://git.eclipse.org/r/c/mmt/org.eclipse.qvto/+/176326

[eclipse-qvt-oml-bot]

By Christopher Gerking on Feb 16, 2021 06:28

Branch cgerking/565747 rebased on master for review.

[eclipse-qvt-oml-bot]

By Ed Willink on Feb 17, 2021 05:30

Building ewillink/565747 which is the same as cgerking/565747 without the gratuitous merge fails on the Completion Proposal Tests. See https://ci.eclipse.org/qvt-oml/job/qvto-branch-tests/94/console

As per https://bugs.eclipse.org/bugs/show_bug.cgi?id=566230#c10 it would appear that JUnit test development has not been completed.

(In reply to Christopher Gerking from comment #14)

Branch cgerking/565747 rebased on master for review.

I see changes that mean nothing to me. Nothing obviously offensive. I can only make some totally trivial stylistic comments.

Bottom line, the non-UI tests presumably demonstrate an improvement.

We need to get this into M3 so that we stand some chance of feedback before releasing. Please fix the UI tests.

[eclipse-qvt-oml-bot]

By Ed Willink on Feb 17, 2021 06:04

(In reply to Ed Willink from comment #15)

fails on the Completion Proposal Tests

Oops. See Bug 571250. Gerrit builds do not seem to have been building the correct commit.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Feb 18, 2021 05:41

(In reply to Ed Willink from comment #15)

Please fix the UI tests.

Done on cgerking/565747.

[eclipse-qvt-oml-bot]

By Ed Willink on Feb 18, 2021 06:37

Branch origin/ewillink/565747 rebased on the bug 472482 fix looks good to go. batrch tests pass.

[eclipse-qvt-oml-bot]

By Ed Willink on Feb 18, 2021 13:38

Pushed to master for 3.10.3M3

[eclipse-qvt-oml-bot]

By Christopher Gerking on Feb 18, 2021 17:22

I forgot to register the test blackbox for the standalone tests (class TestQvtStandaloneExecutor). Done on cgerking/565747.

It would be helpful to run these tests on the CI server, see bug 543009.

[eclipse-qvt-oml-bot]

By Ed Willink on Feb 19, 2021 13:32

(In reply to Christopher Gerking from comment #20)

I forgot to register the test blackbox for the standalone tests (class TestQvtStandaloneExecutor). Done on cgerking/565747.

Or maybe I/GIT messed up the overlapping merges.

Anyway, pushed to master for 3.10.3M3