[build] What is the *.ecore xmi:id policy?

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 507888 | | Status | NEW | | Importance | P3 normal | | Reported | Nov 21, 2016 10:35 EDT | | Modified | Dec 09, 2016 02:27 EDT | | Reporter | Ed Willink |

Description

QVTc/i .ecore have no xmi:id QVTr mostly has xmi:id that match those in the QVT 1.4 .ecore files, which are independently generated from those in the *.uml files.

Pivot.ecore has no xmi:id. Pivot.oclas has algorithmic xmi:id.

Bug 412341 introduces a merge of .ecore and .ocl that loses xmi:ids and consequently prevents the genmodel reconciling successfully.

The Eclipse QVTd *.ecore will eventually be autogenerated and could be auto-xmi:ided.

---

Choices:

• Eliminate the partial xmi:ids - genmodel reconcile doesn't need them.

• Auto-generate them.

• Copy the AS xmi:id to the ES.

---

Pivot.ecore has no xmi:id because they are not needed. Models should refer to the AS.

But we cannot prohibit the use of traditional Ecore tools. Quite apart from GenModel, why should Acceleo or today's QVTo have to use Pivot models?

Try copying the AS xmi:id.

[eclipse-ocl-bot]

By Ed Willink on Dec 08, 2016 02:32

(In reply to Ed Willink from comment #0)

Try copying the AS xmi:id.

Quite a few of the build tools fail to support xmi:ids usefully. GenModelReloader is the worst and hardest. The incoming Ecore seems to get loaded twice, so the xmi:ids need to be transferred from incoming EObjects to different outgoing EObjects.

---

The original problem could be cured by just deleting all the QVTr ecore xmi:ids.

Why do we need ecore xmi:ids? The build only needs a genmodel reference to the EPackage, all others are reconciled.

However *.ecore files using positional references are fragile, cf. EGenericType is at the end of Ecore.ecore. Alphabeticising would break all EClass references to Ecore.ecore.

Maintaining historical order in auto-generated QVT*.ecore is probably more painful than assigning xmi:ids.

Choices:

• an independent deterministic xmi:id generator for *.ecore
• re-use of *.oclas xmi:ids

Once the ConstraintMerger is in use, the .ecore derives from a .oclas so re-using .oclas xmi:ids should be tractable, and the .oclas xmi:id assigner should already have a solution to the overloaded operation challenge.

Choices:

• propagate Ecore xmi:id through all build tools
• add a new assign Ecore xmi:id step

Perhaps both.

[eclipse-ocl-bot]

By Ed Willink on Dec 08, 2016 05:01

(In reply to Ed Willink from comment #1)

and the *.oclas xmi:id assigner should already have a solution to the overloaded operation challenge.

?? Does it ?? Coupling .ecore xmi:ids to .oclas xmi:ids could be crippling. It certainly may add to the debugging confusions that arise when erroneous URLs are in use.

It is EOperation and EParameter xmi:ids that are really difficult to do deterministically. We do not need them. The QVT models define no operations so EPackage/EClassifier/EStructuralFeature/EEnumerationLiteral xmi:ids will avoid fragility without imposing significant difficulties.

NB The prevailing QVTr.ecore xmi:ids come from a Pivot-like generator

P.qvtrelation\ T.qvtrelation.Key\ p.qvtrelation.Key.identifies

Do we want to make these deliberately different? e.g. "-" rather than ".", "F" rather than "p".

[eclipse-ocl-bot]

By Ed Willink on Dec 09, 2016 02:27

After updating the .ecore so that .ocl WFR merging works for QVTd, the only xmi:id that actually matters to OCL/QVTd is the EPackage xmi:id reference from the genmodel. (All other genmodel references are accommodated by reconcilation - at least in so far as the genmodel has no fine-grained non-default content.)

When might users require the xmi:id?

A validation/refactoring meta-transformation will have PropertyCallExp.referredProperty references, which an OCL/QVTc/QVTr exposition resolves at compile time. If this is persisted as .oclas/.qvtas then Pivot (not Ecore) xmi:ids are used. Not an Ecore problem.

A persisted Acceleo .emtl or QVTo .qvtox could be a problem. Supporting this seems like a courtesy rather than a necessity.

Do new stable xmi:ids do any harm? For QVTrelation.ecore, the file size increases by 15%. It has no impact on the generated Java or compiled usage. Therefore a total irrelevance for normal usage and a very minor cost in build time.

Introducing the stable xmi:ids is therefore helpful to a very obscure community. The introduction is totally breaking to that community but occurs before they care. In the case of Pivot.ecore which is 'released API', introduction of xmi:ids where none previously existed only breaks forward compatibility.