@Entenwilli There are a lot of ResourceProvider error in testing after the migration. Interestingly these do not occur for me locally. Could you also have a look into this? I am currently also looking for a solution.

Locally the following happens:
The VertexTest.shouldCreateCorrectPrintableNodeInformation() unit test fails after migration. There were no direct changes to the analysis code.
Error message when running the maven build:

Tests run: 18, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.010 s <<< FAILURE! -- in org.dataflowanalysis.analysis.tests.unit.VertexTest
org.dataflowanalysis.analysis.tests.unit.VertexTest.shouldCreateCorrectPrintableNodeInformation -- Time elapsed: 0.001 s <<< FAILURE!
org.opentest4j.AssertionFailedError:
expected: <Propagated A Node characteristics: Type.Value Data flow Variables: incoming [Type.Value]>
but was: <Propagated A Node characteristics: Type.Value Data flow Variables: incoming [Type.Value]>
...
at org.dataflowanalysis.analysis.tests.unit.VertexTest.shouldCreateCorrectPrintableNodeInformation(VertexTest.java:277)

@Entenwilli There are a lot of ResourceProvider error in testing after the migration. Interestingly these do not occur for me locally. Could you also have a look into this? I am currently also looking for a solution.

Locally the following happens: The VertexTest.shouldCreateCorrectPrintableNodeInformation() unit test fails after migration. There were no direct changes to the analysis code. Error message when running the maven build:

Tests run: 18, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.010 s <<< FAILURE! -- in org.dataflowanalysis.analysis.tests.unit.VertexTest
org.dataflowanalysis.analysis.tests.unit.VertexTest.shouldCreateCorrectPrintableNodeInformation -- Time elapsed: 0.001 s <<< FAILURE!
org.opentest4j.AssertionFailedError:
expected: <Propagated A Node characteristics: Type.Value Data flow Variables: incoming [Type.Value]>
but was: <Propagated A Node characteristics: Type.Value Data flow Variables: incoming [Type.Value]>
...
at org.dataflowanalysis.analysis.tests.unit.VertexTest.shouldCreateCorrectPrintableNodeInformation(VertexTest.java:277)

I don't have any issues at all when running locally. Not in Eclipse, IntelliJ nor Maven. Are you sure you imported all projects from the same repo and don't have any from the (now) merged repos (e.g. Example Models, Converter)

I don't have any issues at all when running locally. Not in Eclipse, IntelliJ nor Maven. Are you sure you imported all projects from the same repo and don't have any from the (now) merged repos (e.g. Example Models, Converter)

Probably some local caching or something on my end. For clarification, you have no problem running the build of this branch locally? Even with all the tests failing here on Github?

The workflow fails here on GitHub, because of some incorrect formatting, not because some tests failed to run

Yes, the build does not fail, but look into the log/console output... there are a lot of error messages of this type:

Error: [ERROR] ResourceProvider - Error loading model pathmap://PCM_MODELS/PrimitiveTypes.repository
Error: [ERROR] ResourceProvider - java.net.MalformedURLException: unknown protocol: pathmap

After looking into other builds, I am quite certain these were not present.

Yes, this is likely caused by changes made in the example models. Eclipse automatically adds these elements to PCM models when they are opened.
These Errors can be ignored as long as the model does not require any resources from the models referenced in the error message

Still they should be fixed... I did not touch any of the models, just migrating them to this repository.
However, as the monorepo migration is blocking progress in other places, I think this can be merged once one of you approves this PR.

I would actually wait before merging this PR, as it rewrites the history a bit and definitly leads to conflicts in the other !5! open PRs

Of the "5" other PRs, 2 are drafts, 1 has been open since last year (and adds documentation) and 1 only changes one single file.
Additionally, none of the other PRs rename/delete/move files, but only modify java files or add in the .github or docs folder. Both should not lead to conflicts as the structure of the previously existing plugins stayed untouched.

I will not postpone this migration for some drafts, documentation changes or minimal fixes. The earlier we start working with this version (also for changes in other migrated repos) the better.

Another thing: Should we commit the generated code and model files for the metamodels? They could be built automatically using MWE2 (this would however complicate the building process).
Perhaps this is something we can discuss in our meeting today

Another thing: Should we commit the generated code and model files for the metamodels? They could be built automatically using MWE2 (this would however complicate the building process).

There a several pros and cons to whatever you do.
We do use mwe2 in the build to automatically generate everything. However, I think for the maven build, we still need project stumps/hulls/mocks for maven to even identify and build the edit and editor plugins. By committing them, I at least make sure that there is a somewhat working version available, even if your eclipse instance does not have everything installed.

But lets discuss later.

The funny thing with the formatting is that we still generate everything, and spotless will fail checking the generated code regardless.

🎉