Loading transformation from plugin requires org.eclipse.m2m.qvt.oml.project

[eclipse-qvt-oml-bot]

| --- | --- | | Bugzilla Link | 414662 | | Status | NEW | | Importance | P3 normal | | Reported | Aug 08, 2013 08:16 EDT | | Modified | Apr 02, 2015 05:19 EDT | | Reporter | Christopher Gerking |

Description

Running a QVTo transformation inside an RCP application requires a dependency from the plugin that contains the transformation to org.eclipse.m2m.qvt.oml.project. Otherwise, the error "Could not find unit: ..." occurs when the TransformationExecutor loads the transformation from a platform:/plugin URI. I don't really see a comprehensible reason for this dependency to be required.

Due to my narrow RCP experiences, are there any preferences on how a repro should look like?

[eclipse-qvt-oml-bot]

By Ed Willink on Aug 08, 2013 08:33

platform:/plugin URIs do not work until EMF and/or other registruies are properly initialized.

You can probably reproduce the problem in a standalone environment. (Use a naked Java rather than Eclipse Java launch to make sure that you don't get a helpful claspath)

[eclipse-qvt-oml-bot]

By Christopher Gerking on Aug 09, 2013 07:51

Since I'm invoking QVTo from within a GMF-based editor, I expect EMF to be properly initialized.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Jan 21, 2014 06:41

Ok, this is simply because without a dependency to org.eclipse.m2m.qvt.oml.project, this plugin does not get installed along with other user plugins. As a consequence, class EclipseUnitResolverFactory is missing as an extension for the org.eclipse.m2m.qvt.oml.unitResolverFactory extension point.

Is it sensible manage the core functionality of resolving/loading units by means of the extension mechanism? If yes, we should at least add this dependency per default to every newly created QVTo project.

[eclipse-qvt-oml-bot]

By Ed Willink on Jan 21, 2014 07:05

Why not just put a class reference from a standard plugin that exists to the standard plugin that's required?

[eclipse-qvt-oml-bot]

By Christopher Gerking on Jan 21, 2014 07:33

(In reply to Ed Willink from comment #4)

Why not just put a class reference from a standard plugin that exists to the standard plugin that's required?

I'm not sure what you mean, so I should maybe explain the problem in more detail.

1. When running a QVTo transformation from Java via class TransformationExecutor, the Java code compiles as long as there is a dependency to org.eclipse.m2m.qvt.oml (which contains TransformationExecutor).

2. At runtime, the TransformationExecutor requires a specific extension from a different plugin (org.eclipse.m2m.qvt.oml.project) which is not necessarily set as a dependency.

3. If the user has installed the entire QVTo SDK, this plugin is available and so is the extension. Everything works fine at runtime.

4. If some user does not have the entire QVTo SDK installed, only the referenced plugin org.eclipse.m2m.qvt.oml gets installed automatically by Eclipse. Thus, the required plugin that contributes the extension is not available, resulting in an error when resolving the transformation via its URI.

So, we can always avoid this problem by adding the appropriate dependency. However, from the Java point of view, there is absolutely no indication for this dependency to be necessary. That's why people usually omit it. As a result, there are problems when running the transformation without having the entire QVTo SDK installed before.

[eclipse-qvt-oml-bot]

By Ed Willink on Jan 21, 2014 07:43

I suggest that perhaps

TransformationExecutor invokes

@SuppressWarnings("unused") String\
      ensureEclipseUnitResolverFactoryExtensionPointIsLoaded = \
            org.eclipse.m2m.qvt.oml.project.QVTEngine.class.getName();

to guarantee the installation.

If the reference is optional, code a more dynamic test to generate an explanatory diagnostic.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Jan 21, 2014 07:51

Got it. But this would introduce a circular dependency between qvt.oml and qvt.oml.project.

[eclipse-qvt-oml-bot]

By Ed Willink on Jan 21, 2014 07:59

Maybe you can only do diagnosis then.

Maybe you can do the reference from somewhere that doesn't cause a loop.

Maybe project shouldn't be a separate plugin.

Maybe the extension point definition should be moved rather than the plugin referenced.

[Sorry I'm not familiar with the code.]

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 17, 2014 07:36

Created attachment 240949 Patch for setting default plugin dependencies

The proposed patch adds dependencies to org.eclipse.m2m.qvt.oml and org.eclipse.m2m.qvt.oml.project to every newly created QVTo plugin project. In addition, it reuses some preexisting String constants.

:notepad_spiral: org.eclipse.qvt.oml.ui.patch

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 17, 2014 07:39

However, this doesn't solve the issue, because the required dependency to org.eclipse.m2m.qvt.oml.project is still unobvious.

[eclipse-qvt-oml-bot]

By Ed Willink on Mar 17, 2014 07:52

If you want to force plugin A to load plugin B without A referencing B and without fancy class loading tricks, the solution is to have an extension point Z.

A declares Z, and loads all Z providers at an appropriately lazy time.

B implements Z and so gets loaded by A.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 17, 2014 08:08

The problem is not loading but installing. Without an explicit dependency to the 'project' plugin, it will never be installed along with a user-defined feature that uses QVTo internally.

[eclipse-qvt-oml-bot]

By Ed Willink on Mar 17, 2014 08:29

Perhaps this is something that really must be a user choice.

The 'JDT' create Plugin Project has an RCP option on its second page. Perhaps the QVTo wizard needs a similar option and consequent functionality.

And if you're really enthusiastic a QVTo->Configure As RCP rescue action.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 17, 2014 12:59

I think the problem that you address has already been solved by the proposed patch, which enforces the required dependencies such that "oml.project" gets installed along with any user-defined QVTo plugin.

However, PDE's dependency analysis will always identify these dependencies as unused. Thus, they could easily be removed accidentally. I'm afraid that the complete solution is to merge "oml" and "oml.project" plugins.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 17, 2014 14:17

A different approach would be to just move class TransformationExecutor from "oml" to "oml.project" plugin. This way, client plugins that access QVTo via TransformationExecutor are required to always specify a plugin dependency to "oml.project", which ensures availability of the functionality to load/resolve units.

Moving an API class will cause legacy problems, though.

[eclipse-qvt-oml-bot]

By Ed Willink on Mar 17, 2014 14:57

Moving an API class is not really an option, but you can deprecate it so that users see the @Deprecated comment telling them which (derived) class to use instead.

[eclipse-qvt-oml-bot]

By Sergey Boyko on Apr 07, 2014 10:48

Pushed patch to master for M7.

commit 371ae82006cb901d28adcfa923c33c61d9da8338

[eclipse-qvt-oml-bot]

By Christopher Gerking on May 23, 2014 07:02

Interesting question: how does it work standalone without oml.project asdescribed here? https://wiki.eclipse.org/QVTo/New_and_Noteworthy/Helios

[eclipse-qvt-oml-bot]

By Sergey Boyko on May 23, 2014 12:33

(In reply to Christopher Gerking from comment #18)

Interesting question: how does it work standalone without oml.project asdescribed here? https://wiki.eclipse.org/QVTo/New_and_Noteworthy/Helios

Plug-in 'oml.project' is really not needed when QVTo runs standalone. This plug-in provides Eclipse workspace specific features to QVTo engine via extension point.

[eclipse-qvt-oml-bot]

By Christopher Gerking on May 26, 2014 02:45

(In reply to Sergey Boyko from comment #19)

Plug-in 'oml.project' is really not needed when QVTo runs standalone. This plug-in provides Eclipse workspace specific features to QVTo engine via extension point.

Yes, but then I wonder why it is strictly needed inside Eclipse. I would expect everything that works standalone to work inside Eclipse as well.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Jul 28, 2014 09:20

I think I finally figured out the actual problem here. Plugin qvt.oml.project is not required in standalone mode and therefore shouldn't be strictly required inside Eclipse as well. The reason why it does not work without is that, in absence of qvt.oml.project, the only available resolver is URIUnitResolver. This one lacks support for imports of modules that resist in a different directory than the importing one. Instead, the current configuration of URIUnitResolver only supports importing of units in the very same directory. Actually, this problem applies to standalone execution as well.

Solving this problem for URIUnitResolver requires detection of the QVTo source container, such that the resolver can be configured to resolve all imports against it. However, this is quite a hard task, if not impossible in standalone mode.

Thus, to solve the problem in Eclipse mode, I suggest to move PlatformPluginUnitResolver from qvt.oml.project into qvt.oml, such that it is available for resolving platform:/plugin URIs even in absence of qvt.oml.project.

For standalone mode, URIUnitResolver should at least mimic the behavior of PlatformPluginUnitResolver: assume that the source container is the plugin root and try to resolve against it. Fallback to lookup inside the importing unit's directory (which is what URIUnitResolver already does at present).

[eclipse-qvt-oml-bot]

By Ed Willink on Jul 28, 2014 09:32

(In reply to Christopher Gerking from comment #21)

Solving this problem for URIUnitResolver requires detection of the QVTo source container, such that the resolver can be configured to resolve all imports against it. However, this is quite a hard task, if not impossible in standalone mode.

Maybe the lightweight search in org.eclipse.ocl.internal.helper.PluginFinder will help (or the fuller search in EcorePlugin.ExtensionProcessor).

[eclipse-qvt-oml-bot]

By Christopher Gerking on Feb 12, 2015 10:24

(In reply to Christopher Gerking from comment #21)

I think I finally figured out the actual problem here. Plugin qvt.oml.project is not required in standalone mode and therefore shouldn't be strictly required inside Eclipse as well.

Consequently, I suggest to revert my change and do not add that dependency to new user projects.

For standalone mode, URIUnitResolver should at least mimic the behavior of PlatformPluginUnitResolver: assume that the source container is the plugin root and try to resolve against it. Fallback to lookup inside the importing unit's directory (which is what URIUnitResolver already does at present).

If properly configured, plugins should now support the above behavior by importing from the classpath (bug 433937). Not tested yet.

Closing this bug requires some documentation, telling users that FQN imports either require qvt.oml.project (in that case a dependency should be set to ensure installation), or require the source container to be part of the classpath. There is already another bug on missing documentation of module imports (bug 380136).

[eclipse-qvt-oml-bot]

By Christopher Gerking on Feb 12, 2015 10:26

(In reply to Christopher Gerking from comment #23)

There is already another bug on missing documentation of module imports (bug 380136).

Sorry, that's bug 319076.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Apr 02, 2015 05:19

(In reply to Christopher Gerking from comment #23)

Consequently, I suggest to revert my change and do not add that dependency to new user projects.

Pushed to master.

Commit ID: 5963287c78cc2a5b466a5502e7e83f48e5ae4272

I still find it desirable to make sure that the invocation of user scripts works whenever the invoking Java code compiles. For Mars+1, we should try to establish a unit resolver capable of resolving units at plugin level, residing in org.eclipse.m2m.qvt.oml (strictly separated from the workspace resolving policies in org.eclipse.m2m.qvt.oml.project).