Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 319076 - org.eclipse.m2m.qvt.oml.runtime.qvtTransformation extension point not explained in documentation
Summary: org.eclipse.m2m.qvt.oml.runtime.qvtTransformation extension point not explain...
Status: RESOLVED FIXED
Alias: None
Product: QVTo
Classification: Modeling
Component: Doc (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 380136 (view as bug list)
Depends on:
Blocks: 380136
  Show dependency tree
 
Reported: 2010-07-07 02:36 EDT by Dennis Hendriks CLA
Modified: 2015-05-29 09:30 EDT (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Dennis Hendriks CLA 2010-07-07 02:36:41 EDT 
Build Identifier: Build id: 20100617-1415 (Helios)

The 'QVT Operational Developer Guide' has a section about 'Blackbox support', and an extension point reference section about 'org.eclipse.m2m.qvt.oml.javaBlackboxUnits'. Similar documentation for 'org.eclipse.m2m.qvt.oml.runtime.qvtTransformation' is not present.

Reproducible: Always

Steps to Reproduce:
n/a
Comment 1 Christopher Gerking CLA 2012-06-27 10:37:22 EDT 
*** Bug 380136 has been marked as a duplicate of this bug. ***
Comment 2 Christopher Gerking CLA 2015-04-22 05:47:07 EDT 
As already mentioned in bug 380136, comment 1, the registered module ID is somewhat redundant. That is because, in order to enable importing the registered module, the ID is required to reflect the full path to the *.qvto file relative to the bundle root. Therefore the ID is usually required to start with "transforms" or any other source container specified. This breaks compatibility between workspace/deployed imports, because in workspace there is no need for imports to specify the source container. I think it is desirable to support arbitrary custom IDs when importing deployed modules, because it allows to reuse workspace modules as deployed modules without changing the import style.

Working on this issue saved a lot of code inside DeployedImportResolver. Pushed to new branch cgerking/319076.

Commit ID: 6d3b4faea0ffcd66c73481e0e42025c2434bd493
Comment 3 Sergey Boyko CLA 2015-04-29 09:53:55 EDT 
Pushed to master for M7 milestone.
Commit id: ed23ca0662f64fd3092355713a9e5ed745903bec
Comment 4 Christopher Gerking CLA 2015-05-29 09:30:15 EDT 
Provided simple usage examples.

Commit ID: ca6ceb8e04a3c7a76f5fa90b1f65f73980fe3e6c