Update Site Management and SimRel Participation

[merks]

The content contributed by MAT to SimRel is very old:

• https://eclipse.dev/simrel/?file=report/report.md#-memory-analyzer-mat
• https://github.com/eclipse-simrel/simrel.build/blob/main/mat.aggrcon
• https://download.eclipse.org/mat/2025-03/M2/update-site

From what I see, these updates sites are basically overwritten with new content occasionally/regular:

• https://download.eclipse.org/mat/latest/update-site/
• https://download.eclipse.org/mat/snapshots/update-site/

Sites with mutable content cannot be contributed to SimRel.

I see quite some activity in the GitHub repository so I assume there is new useful content, it's just not being contributed to SimRel and stable milestones and releases are not being recorded/captured.

One reason this caught my attention is because old versions of BIRT are being contributed to SimRel by MAT (and by PDT). While I could force a newer version of BIRT to be included in SimRel, MAT has not been tested against newer versions of BIRT so I don't know that this wouldn't break some functionality.

BIRT does produce regular quarterly releases:

https://download.eclipse.org/birt/updates/

For continued participation in SimRel, we do need semi-regular updated contributions from MAT and for that the project needs to produce semi-regular stable update sites.

JustJ provides a tool used by a significant number of projects to help with maintaining update sites, including those coordinated with product downloads:

https://eclipse.dev/justj/?page=tools

---

Do you have any plans to improve the release engineering for MAT to produce better-maintained update sites?

[krumts]

@merks
Hi Ed,

The MAT content of the repository in the Simrel still corresponds to the latest official release of MAT (https://download.eclipse.org/mat/1.16.1/update-site/)
The snapshots updates site should have our latest build (not release). And I have no explanation why the "latest" site points to a newer version than what we officially released. It should be the same as 1.16.1 (I'll double-ckeck what happened).

The real issue is that we haven't made a release and haven't engaged in a review for over a year now. This is not good - you see rather "old" content in the Simrel repo, but also because this violates the Eclipse development process.
It is typical for MAT (also in the past) to make releases rather seldom (typically once a year), but this time we went over that boundary.

I suggest that we plan a new MAT release and update the content of the next (2026-06) Simrel with it.
Would this be fine? Or are we (with our once-per-year-release practices) violating the Simrel requirements?

[merks]

A new release in time for 2026-06 would be awesome! Not releasing often is okay too. I’d really appreciate if you updated to the most recent release of BIRT. I help that project with releng support so I expect updates to work well for you. Thanks for the quick response! Your participation is valued and appreciated.

[merks]

BTW. You no longer need to associate your release with a release review, nor even create a record for it. Just ask for a progress review. The EMO has even started doing those automatically.

[krumts]

@merks I started preparing for a new MAT release with the intent to contribute 2026-06.
I updated the BIRT version we use to the latest I found (4.23.0).
My first attempt (eclipse-simrel/simrel.build#1317) to add our contribution failed, because one of the third-party libs the new BIRT version needs is not in the common repo.

04:32:29  Bundle(org.mozilla.rhino 1.9.0) is required by:
04:32:29    ValidationSet(main)
04:32:29      Contribution(PDT)
04:32:29        MappedRepository(https://download.eclipse.org/tools/pdt/updates/8.4rc2a/)
04:32:29          Feature(org.eclipse.php.profiler.feature.group)
04:32:29            InstallableUnit(org.eclipse.php.profile.ui 8.4.0.202512011310)
04:32:29              InstallableUnit(org.eclipse.birt.chart.engine 4.23.0.v202512100941)
04:32:29                InstallableUnit(org.eclipse.birt.core 4.23.0.v202602121516)

I am unsure how to proceed (no experience), could you help with a hint?
Is it ok to add the missing library (org.mozilla.rhino 1.9.0) to MAT's update site and from their contribute also it to simrel, or is there some additional process / approval I need to contribute the new library?

[merks]

Yes you should include it in your update site. But please don’t include it in a feature contributed to simrel. We’re trying to eliminate 3rd party includes

• https://eclipse.dev/simrel/?file=report/third-party-include-report.md
• Eliminate 3rd party includes from features eclipse-simrel/simrel.build#1205

All BIRT’s dependencies come from Orbit and can be used by any project so no concerns.

[merks]

FYI. You don’t need to specify that library in your contribution. It simply needs to be available when computing the transitive closure of dependencies.

Thanks for taking action early in the cycle!

[krumts]

Thank you! I'll give it a try - will build a new update site and prepare another contribution.

[krumts]

This time it worked, thanks for merging the Simrel PR!

We started contributing the BIRT libraries MAT needs at the time BIRT moved out of the Simrel. Back then, I think MAT was the only project to depend on BIRT (or at least I thought so).
You mentioned above, that there is another project contributing BIRT parts. Our BIRT-related coding hasn't changed for many years, and it always felt like we could work with any BIRT version. If it would be simpler for the Simrel, we could remove our BIRT parts and start using whatever version is in the repository.
I don't have anything against keeping things as they are now, i.e. add BIRT libs as part of MAT simerel contributions, but if you see a chance to simplify the overall process, let us know.

For now, I'll close this ticket - we triggered the process for a new release and made the first contribution to 2026-06. We'll continue then with all the things we need for the release separately.

[merks]

The other project using BIRT, that is PDT, is not including BIRT in their site, so without MAT’s site contribution they would fail aggregation. So your current approach is correct. Keep up the good work. And try to update BIRT whenever you plan ahead for a release.