You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 7a16e07
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: jamopp.doc/docs/development/workflow.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ For the development of the extended JaMoPP, we base the workflow on the Gitflow
4
4
5
5
1. While the `main` branch hosts the source code of all releases with Git tags, all changes are primarily merged into the (default) `develop` branch.
6
6
1. For every bug, feature, release, and other issue, a [GitHub issue](https://github.com/MDSD-Tools/TheExtendedJavaModelParserAndPrinter/issues) needs to be created.
7
-
1. For the resolution of an issue (except releases), there should be a separate feature branch, usually branched from the current `develop` branch, with the name `<issue number>_<meaningful_short_issue_description_with_words_separated_by_underscores>`. Please consider the `CHANGELOG.md` and this documentation, and update them if necessary.
7
+
1. For the resolution of an issue (except releases), there should be a separate feature branch, usually branched from the current `develop` branch, with the name `<issue_number>_<meaningful_short_issue_description_with_words_separated_by_underscores>`. Please consider the `CHANGELOG.md` and this documentation, and update them if necessary.
8
8
1. If the changes are ready for merging, a pull request needs to be created for meging the feature branch into the `develop` branch. It is reviewed by at least one person. After all comments and issues within the pull request are resolved and the pull request is approved, it is merged, closing the pull request and corresponding GitHub issue.
9
9
1. For a release:
10
10
1. The following parts should be adapted on the `develop` branch:
Copy file name to clipboardExpand all lines: jamopp.doc/docs/getting-started/advanced_features.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -159,7 +159,7 @@ classDiagram
159
159
160
160
Compared to the first visualization without the `calc` method, the model now includes the method. As a consequence, the parameters, return type (`typeReference` in the actual model), and the statements of the method are also represented with corresponding model elements. In particular, the `AdditiveExpression` for the addition of `a` and `b` contains `IdentifierReference` elements signaling that identifiers are present at this position in the Java code. The actual referenced elements (the method parameters) can be accessed via the `target` EMF reference.
161
161
162
-
:::caution
162
+
:::warning
163
163
The term `Reference` has a double meaning here:
164
164
165
165
1. It refers to identifiers (referencing types, fields, methods, ...) in Java code which are usually represented by `Reference` elements in the Java meta-model.
Copy file name to clipboardExpand all lines: jamopp.doc/docs/getting-started/first_steps.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,7 +7,7 @@ sidebar_label: First Steps
7
7
8
8
This document provides a minimal tutorial on how to use the extended JaMoPP to create your first models from Java code.
9
9
10
-
:::caution
10
+
:::warning
11
11
This tutorial assumes that you are familiar with the Eclipse Modeling Framework (EMF). In case you want more information about EMF or Eclipse, we provide a [list of external resources and tutorials](./resources).
The nightly update site can have different requirements (e.g., on the minimum Java version) compared to the latest release. So, before using it, please check the [`CHANGELOG` on the `develop` branch](https://github.com/MDSD-Tools/TheExtendedJavaModelParserAndPrinter/blob/develop/CHANGELOG.md) for the latest changes.
The first method prints the source code for the given root element into the `OutputStream`. Similarly, the second method prints the source code for an arbitrary model element into an `OutputStream`. At last, the third method prints the source code for a root element into a file, given by a `Path`. The printed source code is not pretty printed.
19
19
20
-
:::caution
20
+
:::warning
21
21
The printer assumes that the given models are valid.
Copy file name to clipboardExpand all lines: jamopp.doc/docs/guides/resolution.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,7 +11,7 @@ The extended JaMoPP provides three variants to resolve the references between di
11
11
12
12
Due to technical issues, the first variant is currently not available.
13
13
14
-
:::caution
14
+
:::warning
15
15
The corresponding class (`JaMoPPJDTParser`) is still included in the artifacts. However, it only returns empty models.
16
16
:::
17
17
@@ -29,7 +29,7 @@ When using the [`JaMoPPJDTSingleFileParser`](./parsing.md), the second variant i
29
29
30
30
During parsing, the second variant creates a proxy object for every reference. The generated proxy URI has the format <`Base URI`>`/EMFTEXT_INTERNAL_URI_FRAGMENT_`<`counter`>`_`<`identifier`> where `Base URI` equals the URI of the model in which the proxy object is located, `counter` is the value of a proxy object counter incremented for every proxy object, and `identifier` is the identifier in the Java source code pointing to the actual Java element. In addition, the second variant stores the context of the proxy object independently from the models, including, for instance, the container of the proxy object or the reference for which the proxy object is set.
31
31
32
-
:::caution
32
+
:::warning
33
33
If Java models with proxy objects are saved on disk, the proxy objects' context is not stored. As a result, if such models are loaded again in a new process, the context is not available, and the proxy objects can potentially be not resolved.
0 commit comments