search

vitruv-tools / Vitruv

View-based Development and Model Consistency Framework
http://vitruv.tools
Eclipse Public License 1.0
14 stars 19 forks source link

Removal of change projects and folder restructuring #529

Closed HeikoKlare closed 2 years ago

HeikoKlare commented 2 years ago

This PR removes the change-related projects that have been moved to a separate repository (https://github.com/vitruv-tools/Vitruv-Change). It also restructures the folder to a depth of only 1 as the reduced number of projects does not require a sophisticated folder structure anymore. It also adds a property for the changes updatesite repository, such that it can be referenced in a local build of that site, and removes the obsolete Maven profile for DSLs generation.

JanWittler commented 2 years ago

While reviewing the changes, I noticed the PropagatedChangeListener interface - not to confuse with ChangePropagationListener - which is exclusively used for the Change Visualisation extension. 1) Do we still need this package? tools.vitruv.extensions.changevisualization 2) If yes, is it possible and worth refactoring it to use the ChangePropagationListener interface?

This would allow us to remove the PropagatedChangeListener and thus make the VSUM interface thinner and then also to move the change visualisation to the changes repository.

HeikoKlare commented 2 years ago

First of all, the mentioned PropagateChangeListenerinterface at least requires some refactoring, obviously (if not removing it / integrating it into another interface).

Regarding the change visualization: As this is declared as an extension, this is nothing we really "need", but it was supposed to ease debugging. It provides a UI that shows changes and their interrelation and can be attached to a "running" V-SUM. I do not know whether anyone uses it, but probably that is rather because its usage is not documented, as a visual representation of changes and their interrelation could be quite helpful in many cases.

The current implementation of the PropagatedChangeListener and thus the change visualization is tied to domains, but probably we can simplify the implementation to be usable by any ChangePropagator (and be, in the best case, integrated into the ChangePropagationListener) rather than a V-SUM to then be independent from V-SUMs, as you have already proposed, @JanWittler.

I would propose to put this into an issue and have it resolved independently. Since the code in the tools.vitruv.extensions.changevisualization project is not in a pretty good state, I would also propose to refactor it at the same time. Then it would not be so bad that we have to move the project from one repository to another losing the history (as otherwise we would have to split the change repository from this framework repository again, which is, in my opinion, not worth the effort).

HeikoKlare commented 2 years ago

I've documented the discussed issues in #532.