| Re: [equinox-dev] Marking org.eclipse.osgi.compatibility.state APIs as deprecated? |
Thomas,
I think you'll find the use of these APIs have gone far a wide.
I count 15 uses of things from this package in my Oomph
workspace. Also 804 in my SDK workspace; you'll find them used in
PDE and in p2. I don't think anyone understands the implications
of removing/changing all these things, I don't think there are
"replacements" for them, and even if there are, they're
used/surfaced in APIs and I don't think anyone (and most certainly
not everyone) has time to rework everything downstream to use
replacements and make new APIs...
So that's all to say that this looks like a rat hole to me. :-(
You are correct, this is a rather a tricky situation. Especially because of things like org.eclipse.pde.core.plugin.IPluginModelBase.setBundleDescription(BundleDescription)I'm not entirely sure why that is API there, seems like an internal implementation detail to be able to set the BundleDescription which backs the implementation details of IPluginModel. Perhaps a more realistic consideration would be to move the API to PDE.
Tom
----- Original message -----
From: Ed Merks <ed.merks@xxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
To: equinox-dev@xxxxxxxxxxx
Cc:
Subject: [EXTERNAL] Re: [equinox-dev] Marking org.eclipse.osgi.compatibility.state APIs as deprecated?
Date: Fri, Jan 8, 2021 8:50 AM
What does it mean to deprecate "the API package org.eclipse.osgi.service.resolver"? Does that affect the use of things like org.eclipse.osgi.service.resolver.VersionRange, org.eclipse.osgi.service.resolver.BundleDescription, and other things in that package? These things are needed for stuff like org.eclipse.pde.core.plugin.PluginRegistry.findModel(String, VersionRange, PluginFilter) and org.eclipse.pde.core.plugin.IPluginModelBase.getBundleDescription() so surely there is not a suggestion here to deprecate these things too?!
On 08.01.2021 15:40, Thomas Watson wrote:I would be in favor of deprecating the API package org.eclipse.osgi.service.resolver which is contained in the Equinox Framework (org.eclipse.osgi). The framework fragment called org.eclipse.osgi.compatibility.state holds the actual implementation, which is internal. But anything needing to get an instance of the implementation should be using the StateObjectFactory API to do so (See org.eclipse.osgi.service.resolver.StateObjectFactory.defaultFactory)
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] [equinox-dev] Marking org.eclipse.osgi.compatibility.state APIs as deprecated?
Date: Fri, Jan 8, 2021 3:47 AM
Hello,https://bugs.eclipse.org/bugs/show_bug.cgi?id=570189 and https://git.eclipse.org/r/c/platform/eclipse.platform.releng.aggregator/+/174392 have revealed some bug in org.eclipse.osgi.compatibility.state. What's the status of the APIs in there? Are they actually deprecated and should be replaced with others whever possible?If yes, should we mark them all as @Deprecated with hints about which API should be used instead? I guess if this was done, it would hint consumers to progressively adopt newer/better APIs.What do you think?
--_______________________________________________
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_______________________________________________
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