Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 367703

Summary:	Inappropriate Collection Type references
Product:	[Modeling] Acceleo	Reporter:	Ed Willink <ed>
Component:	Core	Assignee:	Project Inbox <acceleo-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	laurent.goubet
Version:	3.2
Target Milestone:	---
Hardware:	PC
OS:	Windows Vista
Whiteboard:

Description Ed Willink

2012-01-02 06:19:29 EST

Using Acceleo 3.1.2, I have just rebuilt and compared *.emtl files before puttin g them into GIT.

For model2bodies.emtl I notice some subtle differences

Is now: <eType xsi:type="ocl.ecore:OrderedSetType" href="model2tables.emtl#/3/OrderedSet(Property)"/>

Was: <eType xsi:type="ocl.ecore:OrderedSetType" href="../common/pivotQueries.emtl#/3/OrderedSet(Property)"/>

This may be ok, but inefficient, since pivotQueries.emtl is required by model2bodies.emtl. model2tables.emtl therefore requires an extra resource to be loaded.

The OCL policy, since OCL 2.2, was that OrderedSet(Property) is the same object in all modules so model2tables.emtl#/3/OrderedSet(Property) and ../common/pivotQueries.emtl#/3/OrderedSet(Property) should be the same. And #/3/OrderedSet(Property) (perhaps not "3") should be the same too.

The external reference is therefore redundant, and since it may refer to an independent *.emtl file, it indicates that the compilation of one Acceleo transformation has erroneous dependencies on another.

[There may be an OCL bug that makes this the least bad workaround, but if so the OCL bug should be raised.]

Comment 1 Laurent Goubet

2016-04-07 05:24:29 EDT

We use the first "OrderedSet(Property)" object we find in our context to reference, which in this case seemed to be the one from "pivotQuery" (since it is the same everywhere). The only reason this would be an issue is if the "referencing" emtl is changed so that it no longer imports the "referenced", in which case we would indeed have an extra dependency to load (otherwise, it'll just be loaded anyway from the import). The rest is plain EMF serialization.

Closing since this has never been raised as being an issue and would be hard if not impossible to track down and fix.