escet merge requestshttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests2022-07-04T15:50:21Zhttps://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/343#389 Updated release notes for v0.6-RC2.2022-07-04T15:50:21ZDennis Hendriks#389 Updated release notes for v0.6-RC2.Addresses #389Addresses #389v0.6https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/763#38 AsciiDoc HTML breadcrumbs now include virtual TOC entries2024-01-10T08:00:20ZDennis Hendriks#38 AsciiDoc HTML breadcrumbs now include virtual TOC entries* Best to review per commit.
* Notes about the changes:
* The breadcrumbs are now based on the TOC, rather than on the page containment. This ensures consistency between the TOC and breadcrumbs.
* The virtual TOC entries that are anc...* Best to review per commit.
* Notes about the changes:
* The breadcrumbs are now based on the TOC, rather than on the page containment. This ensures consistency between the TOC and breadcrumbs.
* The virtual TOC entries that are ancestors of the current page are now also included in the breadcrumb.
* As before, the breadcrumbs end at the current page. Virtual TOC entries within the page are not part of the breadcrumb of that page.
* Note that section headings on a page are never part of breadcrumbs, as they can be in the TOC, but can't have child pages.
Addresses #38v3.0https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/768#38 AsciiDocHtmlModifier: fix two typos in comments.2024-01-15T11:39:17ZDennis Hendriks#38 AsciiDocHtmlModifier: fix two typos in comments.Addresses #38Addresses #38v3.0https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/767#38 AsciiDoc HTML TOC now animates collapse/expand.2024-01-15T16:04:17ZDennis Hendriks#38 AsciiDoc HTML TOC now animates collapse/expand.* Solution uses only CSS, no JavaScript.
* The animation makes it more apparent to users what happens. And I personally think it looks really cool :smile:
Addresses #38* Solution uses only CSS, no JavaScript.
* The animation makes it more apparent to users what happens. And I personally think it looks really cool :smile:
Addresses #38v3.0https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/759#38 Fix TOC item highlighting and expanding for current page section.2024-01-08T16:00:17ZDennis Hendriks#38 Fix TOC item highlighting and expanding for current page section.* Best to review per commit.
* First commit fixes TOC item highlighting and expanding for current page section.
* Second commit puts website JavaScript code in a separate file. This reduces the size of the HTML files, sharing the JavaScr...* Best to review per commit.
* First commit fixes TOC item highlighting and expanding for current page section.
* Second commit puts website JavaScript code in a separate file. This reduces the size of the HTML files, sharing the JavaScript code. Also has some other small improvements/fixes.
* Note that this fixes the TOC highlighting and expanding for TOC items that are sections on pages, rather than full pages. It does not yet fix the TOC for virtual TOC items, items that exist only in the TOC and are not pages or sections on pages. Fixing that is for a next merge request.
Addresses #38v3.0https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/750#38 Improved AsciiDoctor-generated documentation HTML pages style2024-01-05T15:45:08ZDennis Hendriks#38 Improved AsciiDoctor-generated documentation HTML pages style* Best to review per commit.
* Introduced custom AsciiDoctor stylesheet.
* Various HTML styling improvements/fixes. Also closer to the website style.
* Each docset now has its own theme, similar to the corresponding website theme.
* Redu...* Best to review per commit.
* Introduced custom AsciiDoctor stylesheet.
* Various HTML styling improvements/fixes. Also closer to the website style.
* Each docset now has its own theme, similar to the corresponding website theme.
* Reduced the size of the website by sharing CSS file between pages of each docset (mostly undone by including the full TOC, see below).
* Indicated external links with an icon after it.
* Includes rudimentary TOC interactivity (collapse/expand functionality).
* Include all TOC levels in TOCs of website pages.
* Changed Chi and ToolDef website link color to be same as documentation, and be less close to black.
* Some other changes. See separate commits.
Addresses #38
Fixes #395v3.0https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/761#38 Link virtual TOC entries and their targets.2024-01-09T14:55:29ZDennis Hendriks#38 Link virtual TOC entries and their targets.Some notes about the merge request:
* Best to review per commit.
* Fixed virtual TOC entries linking to the correct targets.
* Also improved virtual TOC entries/targets naming and styling consistency.
* Furthermore, fixed highlighting of...Some notes about the merge request:
* Best to review per commit.
* Fixed virtual TOC entries linking to the correct targets.
* Also improved virtual TOC entries/targets naming and styling consistency.
* Furthermore, fixed highlighting of the home page in the TOC.
* And some other small improvements. See individual commits.
Some notes about the virtual TOC entries:
* We have at certain places virtual TOC entries, wrappers that group a number of child pages:
* Chi documentation: -
* CIF documentation: SBE (2x), language tutorial (10x), reference manual (2x), tools (6x), simulator (5x)
* ESCET development documentation: index (1x)
* ESCET project documentation: -
* Tooldef documentation: reference manual (2x)
* These help to structure the pages under them, but are not actual sections (headings) on pages after splitting to multi-page HTML. Hence, they don't link to anything that exists.
* Potential solutions are:
* Make them real sections. But, the whole point was to have them be wrappers that only exist in the TOC. If they are sections/headings on the page, and there are multiple of them, you'd get them in the TOC, but the actual pages that they contain after all of them, as you can't mix sections and pages.
* Make them real pages. But, then the page needs content. This would lead to duplication, as we would need to duplicate the list of child references on the overview page and each virtual TOC entry turned new page. This would be annoying to maintain. Also, having the lists twice is not very intuitive to the user when navigating.
* Have no such wrappers. But, then we get larger groups of child pages directly under other pages. This is more difficult for users to grasp. It hinders navigation. We have the wrappers for a reason.
* Somehow relate the virtual TOC entries to their intended targets. Give the TOC entries and their targets relatable IDs (`virtual-toc-entry--<something>` and `virtual-toc-target--<something>`). This will work as desired, at the cost of an extra naming convention and some code in the multi-page HTML splitter to make it work.
* I opted for the last solution, as that is best for end users.
Addresses #38v3.0https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/794#38 Website: generated JS file now has a license header2024-02-06T19:16:11ZDennis Hendriks#38 Website: generated JS file now has a license header* Best to review per commit.
* Also switched to a resource file for the JS file content, rather than a multiline Java string.
Addresses #38* Best to review per commit.
* Also switched to a resource file for the JS file content, rather than a multiline Java string.
Addresses #38v3.0https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/378#390 develop to master for v0.72022-09-30T13:03:49ZDennis Hendriks#390 develop to master for v0.7Addresses #390Addresses #390v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/377#390 Update release notes for v0.7.2022-09-30T12:36:51ZDennis Hendriks#390 Update release notes for v0.7.Addresses #390Addresses #390v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/366#391 develop to master for v0.7-M12022-09-04T11:34:09ZDennis Hendriks#391 develop to master for v0.7-M1Addresses #391Addresses #391v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/365#391 Updated release notes for v0.7-M1.2022-09-04T11:00:02ZDennis Hendriks#391 Updated release notes for v0.7-M1.Addresses #391Addresses #391v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/375#392 develop to master for v0.7-RC12022-09-28T11:54:46ZDennis Hendriks#392 develop to master for v0.7-RC1Addresses #392Addresses #392v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/371#392 Update release notes for v0.7-RC1.2022-09-28T10:14:27ZDennis Hendriks#392 Update release notes for v0.7-RC1.Addresses #392Addresses #392v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/348#393 Prepare Git repo for v0.72022-07-07T17:32:22ZFerdie Reijnen#393 Prepare Git repo for v0.7Closes #393Closes #393v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/438#394 Add script to switch standard visible website.2022-12-18T19:15:23ZDennis Hendriks#394 Add script to switch standard visible website.- Allows to automate various steps.
- Replaces version-specific URLs in HTML files.
Closes #394- Allows to automate various steps.
- Replaces version-specific URLs in HTML files.
Closes #394v0.8https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/441#394 Fixed copy/paste mistake in message of switch-standard-visible-website.bash2022-12-18T20:41:37ZDennis Hendriks#394 Fixed copy/paste mistake in message of switch-standard-visible-website.bashCloses #394Closes #394v0.8https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/345#396 Link release note issues to GitLab issue URLs2022-07-06T20:27:56ZFerdie Reijnen#396 Link release note issues to GitLab issue URLsCloses #396Closes #396v0.6https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/368#398 Various CIF check violation reporting improvements2022-09-23T06:38:53ZDennis Hendriks#398 Various CIF check violation reporting improvementsI opted to create a new merge request, rather than updating !350, as due to renaming all checks, there were heavy conflicts.
While implementing the design discussed at https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/350#...I opted to create a new merge request, rather than updating !350, as due to renaming all checks, there were heavy conflicts.
While implementing the design discussed at https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/350#note_959716, it quickly became more complicated than expected.
The messages may depend on whether the violation is reported on the object itself, or an ancestor of that object.
For instance, for a named location, it will report on the object itself, and it 'is urgent', while for a nameless location, it will be reported on the parent automaton, which 'has an urgent location'.
I then added a second replacement pattern, allowing for conditional replacement, explained it in the JavaDoc, etc.
This became a monster, and was completely non-extensible.
I therefore opted for a more extensive design, allowing for arbitrary trees of messages, and which is easily extensible.
Summary of the changes:
* `CifViolation` and `CifViolations` now allow reporting violations on both 'Specification' objects and 'null' values. This allows checks to just report violations on components, and not have to worry about whether they happen to be a `Specification`.
* `CifViolations` normalizes `Specification` objects to `null`, to have a single unique representation for specifications. This simplifies some of the other changes.
* `CifViolation` and `CifViolations` now allow reporting on non-named object. If the object is not named, they will automatically find the closest named ancestor and use that instead. The checks no longer have to find that closest named ancestor themselves anymore.
* Improved the JavaDoc with violation reporting instructions.
* Introduced message trees (type `CifCheckViolationMessage`) to build up more complex messages. `LiteralMessage` is for literal text. `ReportObjectTypeDescriptionMessage` implements the `{type-of-reported-object}` placeholder that we discussed at https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/350#note_959716. It uses the new `CifTextUtils.getTypeDescriptionForNamedObject` method. `IfReportOnSelfMessage` and `IfReportOnAncestorMessage` allow for conditional messages for when reporting on the object itself, or an ancestor. `SequenceMessage` allows concatenating messages, but should rarely be needed directly, as `CifViolations.add` has a varargs parameter for messages, so for the top level of the messages, it adds the `SequenceMessage` wrapper automatically.
* `CifViolation` can no longer decide from its field alone whether it will produce the same message as another `CifViolation` instance. Hence, `CifPreconditionChecker` removes duplicate messages now.
* I also fixed and improved some violation messages.
Closes #398v0.7https://gitlab.eclipse.org/eclipse/escet/escet/-/merge_requests/560#399 #468 #221 Upgrade to Eclipse 2023-03 with in-place upgrade2023-05-30T18:55:39ZDennis Hendriks#399 #468 #221 Upgrade to Eclipse 2023-03 with in-place upgradeGeneral info on merge request:
* This upgrades from Eclipse 2022-06 to 2023-03. See the individual commits for details. Best reviewed per commit.
* You can set up a new development environment from scratch, but you can also in-place upgr...General info on merge request:
* This upgrades from Eclipse 2022-06 to 2023-03. See the individual commits for details. Best reviewed per commit.
* You can set up a new development environment from scratch, but you can also in-place upgrade your existing development environment now. See the `dependency-upgrades.asciidoc` file for the instructions. **It would be nice if you could all try that out**, so that we can mature the instructions listed there.
In this particular instance, you need to remove the 'Tycho Project Configurators' manually, if you have them still in your development environment. See the step-by-step instructions for details.
Some issues I had while trying out the in-place update. I was trying things out and did not use the step-by-step instructions as they are now, so hopefully you will not encounter them, but it **would be good if you could try**, to see how 'stable' and in-place update is in practice:
* When pressing 'Ctrl+Shift+T' for 'Open Type' I at some point had two commands associated to it. I restored all default keybindings to resolve this.
* Using the 'Open Type' dialog and choosing a class from the JDK led to errors like: `Type 'java.lang.String' could not be found in '.org.eclipse.jdt.core.external.folders/.link23/jre/lib/jrt-fs.jar'. Make sure all workspace resources are refreshed.`. A workspace refresh and full clean/rebuild did not resolve this. I solved it by removing all projects from my workspace and re-importing them.
* Commiting the provisioning operation (for P2 or target platform) by Oomph would fail with `java.lang.ClassCastException: class org.bouncycastle.openpgp.PGPPublicKey cannot be cast to class org.bouncycastle.openpgp.PGPPublicKey (org.bouncycastle.openpgp.PGPPublicKey is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @685f5d0d; org.bouncycastle.openpgp.PGPPublicKey is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @4e2f2438)`.
I resolved this by updating the Oomph version in my development environment: 'Help' -> 'Check for updates...', which only listed Oomph updates, and then 'Next' -> 'Next', accepting all licenses, 'Finish', 'Select all' -> 'Trust selected' -> 'Restart Now'.
Important further details on the changes, some of which affect our way of working into the future:
* I got rid of the Apache XML serializer specific version pinning that was needed for the previous Eclipse version. However, I also got rid of that dependency altogether later on (see next point).
* I had quite some issues with getting Apache Xalan, Apache Xerces and Apache XML resolver to work properly. They were complaining about missing `Import-Package` dependencies.
The packages were JDK packages, so should always be present. I spent hours on this, but didn't manage.
Then I realized that (probably about a decade ago) I introduced them as the XML functionality of the JDK itself at that time wasn't working.
But we use much newer JDKs now, so these dependencies are no longer needed. I thus reduced the dependencies and no longer needed code/comments related to them.
This also fixes issues with saving SVG files from the SVG viewer/visualizer to paths with characters that get encoded as special characters in URLs, such as spaces.
This issue is unresolved for Apache Xalan, but my tests show that the JDK implementation handles this properly.
* I added the Eclipse PDE runtime (with 'Plug-in Registry' view) to the product, to enable debugging of dependency problems.
* The version of `org.apache.commons.lang3` got updated, deprecating its `StringEscapeUtils`. The class essentially got moved to `org.apache.commons.text`, but that is not available on Orbit, nor in the Eclipse 2023-03 update site.
Eclipse Platform and its projects are now using dependencies directly from Maven Central, if they are available there, and have proper OSGi metadata in their manifest (see [here](https://www.eclipse.org/lists/cross-project-issues-dev/msg19288.html), [here](https://www.eclipse.org/eclipse/news/4.25/pde.php#default-3rd-party-bundles) and [here](https://github.com/eclipse-platform/eclipse.platform.common/blob/master/bundles/org.eclipse.platform.doc.isv/porting/4.25/incompatibilities.html)).
In fact, they plan to no longer update or add such dependencies to Orbit at all, in the future (see [here](https://www.eclipse.org/lists/cross-project-issues-dev/msg19616.html)).
Hence, it makes sense that if we need additional dependencies, that we go the same route.
Eclipse PDE and Eclipse Tycho both support target platforms with Maven targets.
However, Oomph does not.
We therefore can no longer generate our target platform using Oomph, and have to switch to a manually crafted target platform.
This has the additional benefit that there will be less unneeded 'crap' in the target platform.
I implemented this change, removing target platform generation from the Oomph setup, and I manually cleaned up the target platform.
It is still possible to let Oomph reactive the target platform, after having edited it. This works in the same way as previous we generated a new target platform using Oomph. The Oomph task has a slightly different name, but is named in such a way that it is clear which one to use.
You can also just open the target platform file and pressing the 'Reload Target Platform' button at the top-right of the 'Definition' tab.
* Since our previous Eclipse upgrade, I get a lot of info-level items in the 'Problems' view when opening XML-based files that don't link to their schema. I configured Wild Web Developer's XML tools to ignore such 'issues'.
* We have M2E settings in our development environment configuration (set by Oomph) to ignore missing M2E lifecycle mappings. However, I still got some, and thus explicitly ignored them in `pom.xml` files.
* The Eclipse JDT compiler tool is no longer provided as a plug-in fragment, but is now provided as a regular plugin. Hence, we don't need special configuration for it anymore for our Maven build. See also [here](https://www.eclipse.org/eclipse/news/4.27/jdt.php#ecj-separated-from-core).
* When upgrading to Eclipse 2022-06, we had to ensure all projects have a project-specific encoding, or projects would get a warning. How, this can be configured to be ignored (see [here](https://www.eclipse.org/eclipse/news/4.25/platform.php#specify-project-encoding-severity) and [here](https://github.com/eclipse-platform/eclipse.platform.resources/issues/166)). We already configure the global encoding in the Eclipse ESCET product, so there is no need for project-specific encodings. Especially for projects of the user, this was annoying. Also, the changes we previously made to ensure the CIF examples and benchmarks had no such warnings (see !331, comment 828762), are no longer needed, and I thus reverted them.
* The development environment now contains Maven 3.8.7, but the Eclipse Foundation Jenkins servers only have 3.8.6, so they don't match, but hopefully that is not a big deal.
Other issues resolved by upgrading to a newer Eclipse version:
* The SVG viewer/visualizer 'Save as' dialog now properly starts in the right initial proposed directory. This fixes #221.
* We can now use records in our Java code without getting warnings about JavaDocs.
Remaining issues:
* We now require PGP signing, for the dependencies we take directly from Maven Central. This requires a PGP key that we have to request from the Eclipse IT team, so I'll do this in a separate isuse.
Closes #399 #468 #221v0.10