Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Marking org.eclipse.osgi.compatibility.state APIs as deprecated?


Comments below

On 08.01.2021 20:07, Thomas Watson wrote:
I've certainly made fixes to this code long after Equinox has stopped using it and I don't mind maintaining fixes there when required.  I do care enough to not break existing projects that are using this API.  After all, I do use PDE nearly every day and we are very dependant on tycho to build.  Ed, lets not become overly negative about the maintainers of this old platform. 
I'm not negative about maintainers.  I am very negative about one-sided attitudes though.
I've been doing this for a very long time and understand your pain and position. 

Of course we both have been doing this for a very long time.  As is the case for me with EMF's 20 year track record.  I recently spent several days getting the build for EMF's GWT variant working.  This has worse than zero benefit for me.  No one pays me for this.  And the time I spend on it costs me time I could get paid for something else, so it literally costs me money to do this.   No one even says thank you and I have no idea who uses it.   Of course I'm very tempted to call a spade a spade and not just deprecate the whole thing but outright delete it.  Because, in all honesty, I care less about 'them' the more that it costs 'me' money.  But if I jettisoned everything that I don't directly use in my projects, there would not be much left of my projects.  But I'd be honest, I'd be calling a spade a spade, I'd be sending a signal that arguably sheds light where there is darkness, and I'd be well within my rights...

To be honest, removing this old implementation that I no long use is going to be a large effort to all, and much of that will fall to me as well to guide others to use something else and likely also contribute to their code base in doing so.

Well yes, this is my basic technical assumption.   There is a significantly large effort involved, for a lot of people (including me). We should consider that carefully.  So if we can set the politics aside, we can and should ask these kinds of questions.  It's easy to set up an IDE where you can see the impact on the Platform's own set of projects, as I have.  Perhaps we could avoid that each time an issue such as this comes up, a political cloud blows in to darken the skies, always with the same basic premise...

These APIs, i.e., the ones used in PDE's and p2's APIs, and hence even further downstream, appear to be highly stable, looking in the Git history of org.eclipse.osgi.service.resolver and org.eclipse.osgi.internal.resolver, and are in little need of maintenance.  Mostly they've just been prettified by sweeping style changes.  I'm not convinced that the replacement wouldn't be identical to what's there now.  Are some parts no longer relevant nor used elsewhere?  Maybe. 

Surely this is what needs to be considered and discussed first and foremost.  But unfortunately these technical points are not the discussion that ensues.  Instead there is discussion about deprecating the whole package to send signals, it's about spades and honesty, and if you don't want to come and maintain the API for everyone else by yourself then you should shut up and go away.  Don't let the door hit your ass on the way out and please take anyone in  the community who shares your concerns with you.

You rightly point out that it's likely to be more effort to design a replacement than to minimally maintain what's there and that decisions in Equinox has an effort impact on "all"...

As of now, because of the way PDE exposes the old resolver API in its own API, I don't see a clear path to removal from the Eclipse Project.  That being said I still think it is worth discussing the possibility of deprecating the API.  This is really a statement to indicate that there is a better way to do something now and we encourage the usage of that better way.  If consumers of the API choose to stay on the old API then that is their decision.  But as of now the users of the old API are left in the dark about it not being our recommended thing to use.

I don't want to be left in the dark using PDE and p2 APIs that I can't use without deprecation warnings.  Warnings that I can't eliminate as a result of the fact that while people had time to sprinkle in deprecation annotations, they didn't have time to design actual APIs.  Of course I did realize there was darkness here in the first place...

Did you know that the platform SDK's project contain 6,762 java deprecation warnings.  A few more will not likely be noticed.  I would assert that the community has gotten signal-deaf and either doesn't hear the signals or suppresses them as noise.  So I'm not convinced deprecation is the path for shedding light where there is darkness...

----- Original message -----
From: Mickael Istria <mistria@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [equinox-dev] Marking org.eclipse.osgi.compatibility.state APIs as deprecated?
Date: Fri, Jan 8, 2021 12:30 PM
Thomas said he's not so enthusiast about supporting this legacy API. As you're the one feeling the need for this API to remain maintained, are you willing to maintain it in high enough quality for continued usage by consumers? If so, then it's great, it's one less change to make in Tycho. If not, then let's call a spade a spade and mark unmaintained API as deprecated for honesty towards the consumer community and enable them to make the best technical decision for their continuous success, even if this one is about leaving the Eclipse Platform for something else.
equinox-dev mailing list
To unsubscribe from this list, visit

equinox-dev mailing list
To unsubscribe from this list, visit

Back to the top