Avoid ECF dependency#989
Conversation
merks
commented
Dec 13, 2025
- Remove the one use of ECF for what is essentially "just a configuration convince" in what I believe to be rare instances where servers might be discoverable on the network.
- Remove the one use of ECF for what is essentially "just a configuration convince" in what I believe to be rare instances where servers might be discoverable on the network.
|
Mylyn has a lot of use cases that may be considered "rare". What is so special regarding ECF @merks ? |
|
It's a bit of a proof of concept that might one day become urgent... I don't wish to create a biased assessment, but the way I see it, there are a number of problems with ECF:
As such, the Platform and Oomph unfortunately need to start considering alternatives to the growing risks of a stalemate in this core communication layer. As a recent example, we needed to create P2SSLContextFactory as a workaround for a problem in ECF implementation: http://github.com/eclipse-equinox/p2/pull/968 That problem remains today. There appears to be little hopeful that this will change. As such, I see growing risk with little hope. And, even if we find an alternative solution (which could include an alternative discovery implementation, but that's yet more work, including testing which is difficult because p2 and Oomph do not use this) we might well end up in a situation where all the EPP packages include Mylyn and transitively include ECF without the P2SSLContextFactory workaround continuing to cause problems. |
|
Thank you for sharing your concerns @merks I agree with you proposal that reduces the surface of potential risk. |
|
Yes, it's definitely pity. I have tried to help keep things on track. We can leave this is PR in a draft state until such a time that we are forced to take some type of remedial action... |