UML -> Java import generation untested, incomplete, and assumes order of execution

[JanWittler]

The import generation performed by the UML -> Java reactions is untested code. Furthermore, an import is only added when a typed element's type is updated. This implies that imports are not updated when an element is deleted or moved.
Additionally, the import routine requires the typed element to be already inserted in its containingCompilationUnit, otherwise an IllegalStateException is thrown. This behaviour is counter-intuitive to the design of the reactions language as the execution order of reactions is by design not deterministic.

Note

I only checked roughly but it seems that the PCM -> Java import generation is untested too. In addition, the PCM -> Java reactions use helper methods declared in tools.vitruv.domains.java.util to manage imports, while the UML -> Java reactions use helper methods declared in tools.vitruv.applications.util.temporary.java.

[JanWittler]

With the integration of move operations (see #102, move for attributes and methods coming soon), the assumption about execution order will become a critical issue, and the quality of the generated imports will decrease with the more move operations supported and applied.
A hotfix to disable assumptions about execution order would simply be to replace the following line by return null https://github.com/vitruv-tools/Vitruv-Applications-ComponentBasedSystems/blob/3f45c1008d9a62daede4ca5d36e7abe3362f7155/bundles/tools.vitruv.applications.util.temporary/src/tools/vitruv/applications/util/temporary/java/JavaTypeUtil.xtend#L272
However, this will create another scenario where an import is not correctly added. Therefore, it should be considered to completely disable the import generation until it is properly implemented.

[jGleitz]

Since I have spent my whole Master’s Thesis up to now fixing bugs in untested, incomplete and buggy code in Vitruv & the applications, I vote against merging a change that is ‘untested, incomplete and assumes order of execution’.

it should be considered to completely disable the import generation until it is properly implemented.

Yes, I’d be strongly in favour.