Add support for libraries from other projects

[eclipse-qvt-oml-bot]

| --- | --- | | Bugzilla Link | 433937 | | Status | NEW | | Importance | P3 normal | | Reported | May 01, 2014 11:57 EDT | | Modified | Jul 31, 2018 05:34 EDT | | Version | 3.4 | | Reporter | Christine Gerpheide |

Description

Currently it is not possible to import a QVTo library into a transformation if the library resides in a different project than the transformation.

Since large projects can require many libraries and it is good programming practice to bundle related code together to be reused, this is a very important feature. Much like being able to depend on other Java projects is an important feature in Java.

Apparently there was support, but it was removed, but it seems unclear why it can't be readded. See:

http://www.eclipse.org/forums/index.php/t/453589/\ https://bugs.eclipse.org/bugs/show_bug.cgi?id=307676

At least in our team, this is something very important to us.

[eclipse-qvt-oml-bot]

By Christine Gerpheide on May 01, 2014 11:58

Christopher Gerking posted in the related issue with respect to this issue:

---\ No progress, but you could use an Eclipse file link instead. Run the wizard to create a new file in the project that should reuse an existing module inside another project. In the wizard's advanced options, enable 'Link to file in the file system' and select the existing file to reuse. This practice enables sharing QVTo files among different projects. The actual file location should be transparent to the QVTo compiler. I hope that helps you.\

However, this results in "Compilation errors found in unit" when used in a standalone context or unit tests, I suppose because it's an Eclipse thing.

[eclipse-qvt-oml-bot]

By Ed Willink on May 01, 2014 12:25

(In reply to Christine Gerpheide from comment #0)

Apparently there was support, but it was removed, but it seems unclear why it can't be readded. See:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=307676

Bug 307676 was about gratuitous PDE dependencies.

Inter-project file imports should be trivial if intra-projects are supported, so yes there is a bug that deserves fixing, but no PDE support should not be re-instated.

[eclipse-qvt-oml-bot]

By Christopher Gerking on May 01, 2014 15:01

(In reply to Ed Willink from comment #2)

Inter-project file imports should be trivial if intra-projects are supported, so yes there is a bug that deserves fixing, but no PDE support should not be re-instated.

Probably not that trivial. How to deduce the actual location of an imported unit, if not using PDE to analyse the plugin dependencies? All imports are relative to the intra-project QVT source container.

Christine, I assume that you are working with plugin projects. Is it an option for you to convert to a simple project, and try setting up Project References? Not sure if this is possible in your "standalone" configuration. But at least the code in class ProjectDependencyHelper looks as if it supports inter-project imports for non-plugin projects with the appropriate project references.

[eclipse-qvt-oml-bot]

By Ed Willink on May 01, 2014 15:13

(In reply to Christopher Gerking from comment #3)

Probably not that trivial. How to deduce the actual location of an imported unit, if not using PDE to analyse the plugin dependencies? All imports are relative to the intra-project QVT source container.

Intelligent decution is IMHO the root of many evils.

QVTo is muich bertter than some other tools by providing the QVT Settings->Metamodel mappings preference page to allow the user to map 'vague NsURIs to precise platform URIs. This should be useable for imports too.

Can you provide an example that you think needs the help of PDE?

[eclipse-qvt-oml-bot]

By Christopher Gerking on Jun 24, 2014 07:41

What about using the Eclipse project references? It seems easy to make WorkspaceUnitResolver delegate to a distinct resolver per referenced project.

However, I'm afraid that this won't work standalone. Which UnitResolver is used in standalone mode at all?

(In reply to Ed Willink from comment #4)

Can you provide an example that you think needs the help of PDE?

Not really. But it is tedious to specify every dependency twice (once as plugin dependency, once using project references or any other mechanism).

[eclipse-qvt-oml-bot]

By Ed Willink on Jun 24, 2014 16:14

(In reply to Christopher Gerking from comment #5)

(In reply to Ed Willink from comment #4)

Can you provide an example that you think needs the help of PDE?

Not really. But it is tedious to specify every dependency twice (once as plugin dependency, once using project references or any other mechanism).

The essence of recent developments in EcorePlugin.ExtensionProcessor or OCL's ProjectMap is to give the same environment for standalone and plugin execution. For the standalone case the classpath is searched for interesting MANIFEST.MF/plugin.xml files and thereafter platform: is a compatible virtual root in both contexts. User code just does patform:/resource/.... and it works.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Jul 19, 2014 05:27

(In reply to Ed Willink from comment #6)

The essence of recent developments in EcorePlugin.ExtensionProcessor or OCL's ProjectMap is to give the same environment for standalone and plugin execution. For the standalone case the classpath is searched for interesting MANIFEST.MF/plugin.xml files and thereafter platform: is a compatible virtual root in both contexts. User code just does patform:/resource/.... and it works.

Thanks for the hints. In order to support EcorePlugin.ExtensionProcessor, I think we must get rid of the current QVTo assumption that the platform extension registry should only be considered in case of EMFPlugin.IS_ECLIPSE_RUNNING.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Jul 19, 2014 05:35

Created attachment 245212 ClassPathUnitResolver patch

What about searching the Java classpath for imported modules? This would require users to add the QVTo source container to the build path. Based on this assumption, the attached ClassPathUnitResolver first obtains the URL of an imported module, before delegating to an URIUnitResolver.

:notepad_spiral: ClassPathUnitResolver.patch

[eclipse-qvt-oml-bot]

By Christopher Gerking on Oct 31, 2014 09:07

Added support for inter-project imports in workspace (requires to set up project references).

Commit ID: b8b51d026337b2ae34b8063aeddbe5979566de4c

Also established standalone support for imports from the classpath (source container must be added to the classpath in order to support inter-project imports).

Commit ID: 326381d8ddb35244d9ca27ad87963ddb98996deb

Together with the existing mechanism for inter-plugin imports of modules deployed via the extension point 'org.eclipse.m2m.qvt.oml.runtime.qvtTransformation', I think we have support for all relevant situations.

[eclipse-qvt-oml-bot]

By Sergey Boyko on Nov 02, 2014 16:49

(In reply to Christopher Gerking from comment #9)

Added support for inter-project imports in workspace (requires to set up project references).

Commit ID: b8b51d026337b2ae34b8063aeddbe5979566de4c

There may some issues with names clashing when scripts with same name reside in the same containers but in different projects. I think notifications/warnings should be reported in such case.

\

Also established standalone support for imports from the classpath (source container must be added to the classpath in order to support inter-project imports).

Commit ID: 326381d8ddb35244d9ca27ad87963ddb98996deb

Could you please provide unit test for that case.

\

Together with the existing mechanism for inter-plugin imports of modules deployed via the extension point 'org.eclipse.m2m.qvt.oml.runtime.qvtTransformation', I think we have support for all relevant situations.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Nov 03, 2014 12:37

(In reply to Sergey Boyko from comment #10)

Could you please provide unit test for that case.

How, if we are running plugin tests?

[eclipse-qvt-oml-bot]

By Sergey Boyko on Nov 06, 2014 04:12

(In reply to Christopher Gerking from comment #11)

(In reply to Sergey Boyko from comment #10)

Could you please provide unit test for that case.

How, if we are running plugin tests?

Execuse me, I meant test for inter-project imports in workspace.

As for for imports from the classpath this possibly can be tested (though I'm not sure) from Ant runner.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Nov 10, 2014 04:35

(In reply to Sergey Boyko from comment #12)

Execuse me, I meant test for inter-project imports in workspace.

Can you guide me to the most efficient way of integrating with the existing test code? I noticed that the interpreter tests are running from a workspace project, but I'm not sure how to reuse.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Nov 12, 2014 04:34

(In reply to Christopher Gerking from comment #13)

Can you guide me to the most efficient way of integrating with the existing test code? I noticed that the interpreter tests are running from a workspace project, but I'm not sure how to reuse.

Figured out. But there's a problem as the tests seem to load the compiled modules from XMI (qvtox). Here the inter-project imports lead to nowhere because they are persisted as

This seems to be due to a non-specified resource for QvtOperationalFileEnv.

Sergey, can you help here?

[eclipse-qvt-oml-bot]

By Sergey Boyko on Nov 12, 2014 07:18

(In reply to Christopher Gerking from comment #14)

(In reply to Christopher Gerking from comment #13)

Can you guide me to the most efficient way of integrating with the existing test code? I noticed that the interpreter tests are running from a workspace project, but I'm not sure how to reuse.

Figured out. But there's a problem as the tests seem to load the compiled modules from XMI (qvtox). Here the inter-project imports lead to nowhere because they are persisted as

This seems to be due to a non-specified resource for QvtOperationalFileEnv.

Sergey, can you help here?

I see, interesting effect of inter-project imports. I'll investigate and fix this.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Nov 12, 2014 09:40

(In reply to Sergey Boyko from comment #15)

I see, interesting effect of inter-project imports. I'll investigate and fix this.

Thanks, I pushed my test case to cgerking/433937 (to be revised). Maybe it is useful for reproduction.

Commit ID: e908440028a1ff26812c9b79f361216a467c9026

[eclipse-qvt-oml-bot]

By Sergey Boyko on Dec 11, 2014 03:35

(In reply to Christopher Gerking from comment #16)

(In reply to Sergey Boyko from comment #15)

I see, interesting effect of inter-project imports. I'll investigate and fix this.

Thanks, I pushed my test case to cgerking/433937 (to be revised). Maybe it is useful for reproduction.

Commit ID: e908440028a1ff26812c9b79f361216a467c9026

Pushed to master for M4.\ Commit id b11fe4a2697828d9bd8d16b31c5c3fa0149033e5

For now this junit test sets flag of using serialized XMI to 'false' so the test is passing. Serialization of compiled modules will be improved to work with referenced projects.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Jul 31, 2018 05:34

(In reply to Sergey Boyko from comment #17)

For now this junit test sets flag of using serialized XMI to 'false' so the test is passing. Serialization of compiled modules will be improved to work with referenced projects.

Externalized to bug 537527.

I suggest to resolve this bug as fixed.