Thomas,
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...
Tom
----- Original message -----
From: Mickael Istria <[email protected]>
Sent by: [email protected]
To: Equinox development mailing list <[email protected]>
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
[email protected]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/equinox-dev
<https://www.eclipse.org/mailman/listinfo/equinox-dev>
_______________________________________________
equinox-dev mailing list
[email protected]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
[email protected]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/equinox-dev
