Exported model includes dependants, but shouldn't?

[dr_shorthair]

When I run "Export package to XMI file", the exported document also includes UML: Dependency, UML: Generalization and UML: Association links that involve dependant packages and classes that are in my model cache (.eap file) but are _not_ in the package being exported. These associations are owned by the dependant, not the elements in package being exported, so surely they should not be exported as part of the XMI representation of the package of interest?

This causes us trouble because we are processing the XMI representation, and we run conformance tests on the EAStub elements to check that dependencies are known to the processor. We don't care about dependants, so if they are also present in the EAStub list our conformance checking gets much harder.  

[Frank Horn]

When you have a package A containing an Element a and a package B containing an element b, and a connector saying a depends on b, then the connector belongs to package A. At least this is how EA handles it, and it looks sensible to me.

Now when you export package A but not B, A.xml will contain a stub for element b, and rightly so, because otherwise EA's mechanism of dividing a project into controlled packages would lose information (it still does sometimes due to bugs in stub handling, but that's another story).

Or do you mean to say that B.xml will contain a stub for element a as well? This would be weird indeed, and the last time I checked xmi files for stubs I think this was not the case. If it is now, it might be a desperate attempt to resolve the stub handling bugs mentioned above, but certainly a questionable strategy.

[«Midnight»]

On a different note, we really need to increase the allowed length of a topic. The above two posts are a perfect case in point.

Bug submitted.

[edit]I also mentioned to Sparx that the non-registered bug report form seems to not to accept the correct verification code.[/edit]

[dr_shorthair]

Frank - yes, I agree with your analysis. But I find that stubs for the dependants are included when I export the dependancy - though only when the dependant packages are present in the model cache when I run the export operation on the dependancy. If I remove them from the model cache then the exported document is as expected. That doesn't make sense to me. \-.

[Frank Horn]

If I remove them from the model cache then the exported document is as expected. That doesn't make sense to me.

I think this has been discussed in some other thread. The effect within a version control scenario is that when you check in a package from a model containing all dependencies, the stubs will be in included in the version controlled xmi file. But when someone else then uses the package via the "Get Package" menu in another (private) eap file and fails to import the packages containing the dependencies, but changes the package and checks in again, then the stubs are lost. An so are the dependencies when you update the package in your original model.

Sparx seems to have recognized this as a bug; they said someone was "looking into it".