| Re: [equinox-dev] Marking org.eclipse.osgi.compatibility.state APIs as deprecated? |
Thomas,
Comments below
I'm not negative about maintainers. I am very negative about one-sided attitudes though.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'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...
Tom
----- Original message -----
From: Mickael Istria <mistria@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Cc:
Subject: [EXTERNAL] Re: [equinox-dev] Marking org.eclipse.osgi.compatibility.state APIs as deprecated?
Date: Fri, Jan 8, 2021 12:30 PM
Ed,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
equinox-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________ equinox-dev mailing list equinox-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev