Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [simrel-dev] Staging for SimRel 2025-09 M1 is Complete | ACTION REQUIRED: Do not include non-project content in features

Yes, the late M1a was my doing, trying to prevent problems for M1 overall.  Of course RAP generally does not cause duplicates except for the period between when the Platform updates on a Friday and RAP updates on the following Wednesday.

A Validation Set can also specify a Validation Repository to ensure that the transitive closure of dependencies of the Mapped Repositories is complete, without aggregating the content from that repository, e.g.,

But I think you also have the goal that the transitive closure of the repository itself is complete so that someone can easily build a complete target platform for RAP using Planner mode:

  https://download.eclipse.org/rt/rap/4.4/M1-20250709-1612/

That can be accomplished by configuring Tycho to do that for you.

The above is how the Platform ensures the repository is complete without including 3rd party bundles in their features.

But you already have that:

https://github.com/eclipse-rap/org.eclipse.rap/blob/1738397cf8be122ce7a2c4981e1300b7aec4111a/releng/org.eclipse.rap.build/repository/pom.xml#L56

I'm not sure the role that org.eclipse.rap.equinox.target.feature.feature.group plays.  Is it important that this be contributed to SimRel?  Might it use imports instead of includes, or is it important to be used in slicer mode?  Isn't it kind of tricky to ensure you actually maintain the closure of Equinox dependencies as evolves its use of 3rd party dependencies?  And do you need to even do that given you include all dependencies in the repo anyway (or again, is there a target platform slicer-mode use-case)?

I guess we both have quite a few question.  Probably it's best to start a discussion so that the questions and answers are all recorded in one place...


On 7/30/2025 4:08 PM, Markus Knauer wrote:
Hello Ed,

Regarding (2.) and since you mentioned RAP: We ensure that we provide the correct versions from the platform project, but due to the late M1a (and because it is ‘only’ an M1), we did not do so at the time.

But in general, we have a problem with the above requirement. Since we live with our bundles in a separate validation set, we also have to provide everything within this validation set to make it self-contained and validatable. And to my knowledge, the only way to do this is to ensure that the required platform bundles (in the correct version, of course) are available in it.

Any ideas or comments?

Thanks,
Markus

On Thu, 10 Jul 2025 at 09:28, Ed Merks via simrel-dev <simrel-dev@xxxxxxxxxxx> wrote:
The staging repository content of

  https://download.eclipse.org/staging/2025-09/

has been promoted to the following repository for 2025-09 M1:

  https://download.eclipse.org/releases/2025-09/202507111000/

This is ready for consumption by EPP.

It will become visible in the composite as scheduled Friday, July 11, 2025:

  https://download.eclipse.org/releases/2025-09

___________________

Reminder:  Do not include non-project content in features

https://eclipse.dev/eclipse/markdown/?file=eclipse-simrel/.github/main/wiki/SimRel/Simultaneous_Release_Requirements.md#do-not-include-non-project-content-in-features

In the coming weeks, I will be tracking down the offenders and if you are at the bottom of the dependencies graph I will disable your contribution:

https://raw.githubusercontent.com/merks/test/master/report.svg

___________________

We're regressing on the duplicates primarily because of including non-project content in features.

https://download.eclipse.org/staging/2025-09/buildInfo/archive/download.eclipse.org/staging/2025-09/

  1. We need a DLTK update https://github.com/eclipse-dltk/dltk.core/issues/5 but that appears completely stalled.
  2. My fault for contributing a late M1a of the Platform in Tuesday to avoid regression behavior in editors using the reconciler, though I do wonder why RAP to includes Platform projects in RAP features; see reminder above.
  3. We need a WTP update and this is caused by including Jetty in WTP's features; see reminder above.


_______________________________________________
simrel-dev mailing list
simrel-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org


--

### EclipseSource Group Telefon: +49 721 664733-0 (UTC +1) Telefax: +49 721 66473329 http://eclipsesource.com
Innoopract Informationssysteme GmbH Lammstrasse 21, 76133 Karlsruhe Germany General Manager: Jochen Krause Registered Office: Karlsruhe, Commercial Register Mannheim HRB 107883

Back to the top