Disable ECF's SimRel Contribution

[merks]

"ECF project ending participation in simrel for 2025-06" has been announced:

https://www.eclipse.org/lists/cross-project-issues-dev/msg20026.html

So I will take steps to disable ECF contribution as soon as possible.

The first step is to disable the features. That will reduce ECF's contribution to the things required by other projects, i.e., currently these:

The ssl features and bundles will disappear once the Platform contributes M2.

I cannot update to ECF to 3.15.4 until a new contribution with the following change is available, i.e., when tracecompass provides json itself rather than piggybacking off of ECF:

eclipse-tracecompass/org.eclipse.tracecompass#206

The Platform already redistributes ECF's content that it requires. Once Mylyn does the same:

eclipse-mylyn/org.eclipse.mylyn#667

ECF's contribution as a whole can be disabled/deleted.

Both the Platform and Mylyn are using ECF 3.15.4 in their target platform.

[scottslewis]

I had intend to contribute 3.15.4 to 2025-03.

[scottslewis]

@merks I'm intending to remove the httpclient 4.5 to create ECF 3.15.5 this weekend, and would like to contribute that to 2025-03 simrel.

[scottslewis]

@merks ECF 3.15.5 released to https://download.eclipse.org/rt/ecf/3.15.5

WRT filetransfer, this repo has same contents at 3.15.4.

I would like to contribute the 3.15.5 release to 2025-03. I would also like to put a few more features into categories of the 2025-03 simrel composite repo. I'm not sure if this is still the way: by modifying the ecf.aggrcon file in org.eclipse.simrel.build repo. Please let me know here if there is some other way to move features into other simrel categories and update the ECF simrel contribution to 3.15.5.

[merks]

Unfortunately, until there is a new tracecompass contribution that addresses eclipse-tracecompass/org.eclipse.tracecompass#206 aggregation fails with recent ECF releases:

Aggregation Failure

Cannot complete the install because one or more required items could not be found. Software being installed: validationSet_main 1.0.0 Missing requirement: org.eclipse.tracecompass.ctf.core 4.6.1.202412041911 requires 'java.package; org.json 0.0.0' but it could not be found Cannot satisfy dependency: mappedRepo_download.eclipse.org_tracecompass_releases_10.2.0_repository 1.0.0 depends on: org.eclipse.equinox.p2.iu; org.eclipse.tracecompass.lttng2.control.feature.group 0.1.0 Cannot satisfy dependency: org.eclipse.tracecompass.lttng2.control.feature.group 10.2.0.202412041911 depends on: org.eclipse.equinox.p2.iu; org.eclipse.tracecompass.ctf.core 1.0.0, filter=(!(org.eclipse.equinox.p2.exclude.import=true)) Cannot satisfy dependency: validationSet_main 1.0.0 depends on: org.eclipse.equinox.p2.iu; mappedRepo_download.eclipse.org_tracecompass_releases_10.2.0_repository [1.0.0,1.0.0]
Missing requirement: Trace Compass CTF Core Plug-in 4.6.1.202412041911 (org.eclipse.tracecompass.ctf.core 4.6.1.202412041911) requires 'java.package; org.json 0.0.0' but it could not be found

JavaPackage(org.json) is required by:
  ValidationSet(main)
    Contribution(Trace Compass)
      MappedRepository(https://download.eclipse.org/tracecompass/releases/10.2.0/repository/)
        Feature(org.eclipse.tracecompass.lttng2.control.feature.group 0.1.0)
          InstallableUnit(org.eclipse.tracecompass.ctf.core 4.6.1.202412041911)

Any updates for ECF can (will have to) wait until post m2. (Generally ECF's contribution should match what's consumed by the Platform's contribution, and that has been completed for m2.)

---

I think it will be good to clarify plans and expectations before I proceed with further help. Looking at the history we can see that the contribution has effectively been maintained by me with only a single commit from you in the last 3 years:

https://github.com/eclipse-simrel/simrel.build/commits/main/ecf.aggrcon

So when you say "ECF will not participate in the 2025-06 simultaneous release" I interpret that to mean that you no longer desire the contribution to be maintained by me on your behalf and that the IDE WG's investment in mainlining SimRel as a whole is better invested elsewhere than on ECF. Sorry if I take it personally if that was not the intent. I have tried to be diligent helping maintain ECF's contribution to SimRel as well as helping maintain the project itself:

https://github.com/eclipse/ecf/commits/master/?author=merks

The above includes investments to modernize the target platform, eliminating ECF as a source of a bad org.apache.commons.logging version for example.

I see all this as effective open-source teamwork and as a good investment of the IDE WG's funds.

Now, for 2025-03, before you withdraw for the 2025-06 release cycle, you wish to spend time updating the structure of your contribution. Yes, I can help with that too, but I don't fully understand why I should help add something that I will subsequently need to help delete. I don't even understand why you would want to spend time on this now. I need to make plans now to solve the expected problems that will come in the future and I feel it's best to nip this in the bud sooner rather than later.

Please clarify the plans and expectations into the future. I assume ECF plans to produce releases in the future, but goodness knows it's bad to make assumptions. I have no problem updating/maintaining SimRel (the Platform and Mylyn) to keep up with those releases and I'm happy to help ECF if and when there are things with which you need help. So I'm happy to continue with the status quo. I'm not happy if ECF will not participate in 2025-06, nor in any other cycle in the future, but if that's the intent then best to stop immediately.

[scottslewis]

Unfortunately, until there is a new tracecompass contribution that addresses eclipse-tracecompass/org.eclipse.tracecompass#206 aggregation fails with recent ECF releases:
Aggregation Failure

Any updates for ECF can (will have to) wait until post m2. (Generally ECF's contribution should match what's consumed by the Platform's contribution, and that has been completed for m2.)

Would you please point me at the schedule?

I think it will be good to clarify plans and expectations before I proceed with further help.

Plans: As project lead, for personal reasons in 2025 I can no longer volunteer as much of my time on ECF or the Eclipse community. Further, I and others have plans to focus on Remote Services, tooling for RS (e.g. bndtools), and integration of e2e secure communications (e.g. signal) into ECF, and AI safety/responsibility tooling. These are my priorities for the project. With no support personally for maintenance over many years (an unsustainable situation for me), and the waning value of the sr to ECF, I've decided it's best for the project to leave the sr after 2025-03.

Expectations: That because of my personal situation, and the apparent unwillingness of the EF org, membership to address the general problem of resource allocation, I believe it's not feasible to be in the sr any longer.

Looking at the history we can see that the contribution has effectively been maintained by me with only a single commit from you in the last 3 years:

That has very little to do with anything, except your willingness to help (which I appreciate, btw). ECF has been releasing regularly over those two years (and for the 20 years prior to that). It has more to do with my own confusion wrt you making changes, and the changes in simrel that have been going on.

https://github.com/eclipse-simrel/simrel.build/commits/main/ecf.aggrcon

So when you say "ECF will not participate in the 2025-06 simultaneous release" I interpret that to mean that you no longer desire the contribution to be maintained by me on your behalf and that the IDE WG's investment in mainlining SimRel as a whole is better invested elsewhere than on ECF. Sorry if I take it personally if that was not the intent.

Yeah, you taking it personally was not the intent. Apologies as you seem to have done so. Ed, as I see it there is a structural and organizational problem with the way that resources are allocated for EF projects. That problem is that the people doing the actual daily work of maintenance (yourself, myself, other project leads/committers) are basically asked to volunteer their time (I expect you are getting paid for your work these days, but still overworked). When it comes to maintenance of the shared resource (dev time) that is not sustainable, and I personally can't bear that burden any longer. You might enjoy: Governing the Commons by Elinor Ostrom as it does provide some real world examples of community governance/maintenance that actually works.

I have tried to be diligent helping maintain ECF's contribution to SimRel as well as helping maintain the project itself:

https://github.com/eclipse/ecf/commits/master/?author=merks

The above includes investments to modernize the target platform, eliminating ECF as a source of a bad org.apache.commons.logging version for example.

I see all this as effective open-source teamwork and as a good investment of the IDE WG's funds.

Thank you. Yes that's appreciated. May actions are not an explicit nor implicit personal criticism.

Now, for 2025-03, before you withdraw for the 2025-06 release cycle, you wish to spend time updating the structure of your contribution. Yes, I can help with that too, but I don't fully understand why I should help add something that I will subsequently need to help delete.

Because the project has previously committed to being a part of 2025-03 and my understanding is that it's the project's decision about what to contribute to the sr. It's also possible that between now and 2025-06 that ECF maintenance resources can be found, and I am continuing to look. I have not given up on that. My intention with announcing so early (before 2025-03 was complete) was because of the Platform dependency...giving everyone necessary time to adjust.

I don't even understand why you would want to spend time on this now. I need to make plans now to solve the expected problems that will come in the future and I feel it's best to nip this in the bud sooner rather than later.

Because the project has implicitly previously agreed to be part of 2025-03, and it's possible that it can remain in 2025-06 and after.

Please clarify the plans and expectations into the future. I assume ECF plans to produce releases in the future, but goodness knows it's bad to make assumptions.

Yes it does, as described above: emphasis on Remote Services, tooling for RS, and secure e2e communications, and AI safety/responsibility tooling.

I have no problem updating/maintaining SimRel (the Platform and Mylyn) to keep up with those releases and I'm happy to help ECF if and when there are things with which you need help. So I'm happy to continue with the status quo. I'm not happy if ECF will not participate in 2025-06, nor in any other cycle in the future, but if that's the intent then best to stop immediately.

I don't think it's best to stop immediately. If everything were great in EF maintenance-land my intent would be to have ECF continue participating in the sr indefinitely. Unfortunately, reality does not currently match my intent.

[merks]

I post a link to cross-projects at the end/start of each release cycle with details relevant to the release cycle:

https://github.com/orgs/eclipse-simrel/discussions/669

That post includes a link to the schedule. If details are missing, best to suggest improvements in the discussion.

I empathize with the problems faced by ECF and by other SimRel participants. The best I can personally do is to offer help with release engineering issues and with anything else that is within my capacity. I must ensure that SimRel continues to function well one way or the other.

[merks]

The plan is to keep participating until further notice.

[scottslewis]

ECF has released 3.16.1 as per https://github.com/eclipse-ecf/ecf/blob/master/README.md

I would appreciate an update to the simrel contribution. If you are unable, please let me know here and I'll make the change.

[merks]

I've created this PR:

#866

Also this one:

eclipse-platform/eclipse.platform.releng.aggregator#3052