Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Project-Independent Monitoring and Change Propagation for Views #7

Open
HeikoKlare opened this issue Jan 17, 2021 · 0 comments
Open
Labels
enhancement New feature or request wontfix This will not be worked on

Comments

@HeikoKlare
Copy link
Contributor

We currently have project builders VitruvProjectBuilder for each domain, which are added to projects to start monitoring changes and propagate them to an associated VirtualModel.
This approach has several drawbacks. First, it initializes the domain-specific monitors implicitly during a project build, which requires projects to be (unecessarily) built on Eclipse startup. While this could be fixed with some better configuration, the second, more important problem is that change monitoring happens project-wise. If a VirtualModel is supposed to preserve consistency between multiple projects, in particular between multiple projects of the same domain (such as multiple Java plugin-in projects), changes become monitored and propagated in an isolated way, which can easily result in unnecessary failures, because projects depend on each other and thus the models within the VirtualModel will be inconsistent. We need to consider a development project (not an Eclipse project) as a whole, which means that one domain needs to monitor changes to all associated Eclipse projects.

I thus propose to do something like the following:
We do not use builders anymore but implement a kind of virtual model view extensions for Eclipse. We have some explicit representation of active views for a virtual model (can be an explicit project like the VSUM project), which stores the monitoring information, i.e., the projects, file extensions and whatever other information necessary for each domain.
Please note that this, in the current implement, leads to some overlaps which may make thinking about responsibilities diffult: The project to monitor are both a current state representation of the virtual model, as well as views on which the user operates. This is not how views should finally work, but how is currently done. At the end, the virtual model should have a current representation of all models it covers, and the user may have another representation of the views he operates on.
Monitoring is only relevant for the latter, which is why we must not mix up the current VSUM project, which manages the state of the virtual model, with monitoring information for views.

This is just an initial documentation of problems and first ideas, but the topic requires further discussion and its proper solution especially requires a proper definition and implementation of views, as well as according workflows in Eclipse. I only want to document my initial ideas, as I faced these problems when refactoring view-related implementations of domains.

@HeikoKlare HeikoKlare added the enhancement New feature or request label Jan 17, 2021
@HeikoKlare HeikoKlare transferred this issue from vitruv-tools/Vitruv Aug 11, 2022
@TomWerm TomWerm added the wontfix This will not be worked on label Sep 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants