Mark org.eclipse.osgi.services as for removal

[laeubi]

org.eclipse.osgi.services is/was a way back in the past to have the OSGi Api made available, but today this is replaced by using the individual artifacts.

I think we should now (maybe even for 2023-12?) announce deprecation / removal of org.eclipse.osgi.services so we can remove this after two years (or later) from now on.

@tjwatson @akurtakov @HannesWell WDYT?

[akurtakov]

I'm always in favor of us shipping less duplicated content .

[vogella]

+1 for mark for removal

[merks]

Some data

Is there perhaps more that needs to be deprecated?

If you are going to deprecate something for removal, perhaps you should stop using it yourself first to ensure that there is a viable alternative and to be able to document that alternative.

[laeubi]

If you are going to deprecate something for removal, perhaps you should stop using it yourself first

Not sure to who this is directed, but me as a person remove any usage I see and already have removed many usage of it, but not all projects are under my direct control :-)

ensure that there is a viable alternative

The alternative is simply use import-package of that, actually it is not an alternative, as this would mean you have a choice, but the OSGi spec most of the time states that "users of that service must import the package ...", the never tell you about require a bundle of whatever name this is more for historic reasons and because it was "convenient".

Is there perhaps more that needs to be deprecated?

Not that I'm aware of @tjwatson might can give better details, at least (after deprecation) we should not include it anymore actively in any feature like we did for javax.inject

[merks]

We can see that equinox and e4 include it in features. That needs to be addressed before it can be removed, and I think deprecating while you haven't stopped using it yourself is questionable. But that's just my opinion.

I saw this

but did not realize it comes from ECF. Go figure.

[akurtakov]

So first part - prior to deprecation should be dropping from features (which might require incl it direclty in p2 repo).

[laeubi]

So first part - prior to deprecation should be dropping from features (which might require incl it direclty in p2 repo).

That's the question for me, can we drop it from feature without deprecating it first? And must we ship it to SimRel or is it fine to "only" include it in the SDK ?!?

[akurtakov]

As long as it's in the repo(s) we can drop it from features as dependents still resolve.

[tjwatson]

We have to have this bundle as long as it has the http service interfaces are only in it. This was work still left over #18. I would not deprecate this until it really is a "shell" of a bundle with no .class content.

[laeubi]

We have to have this bundle as long as it has the http service interfaces are only in it

Can you explain what was the problem of "just" consume the official artifact for http service?

[HannesWell]

I created #403, which replaces the remaining (replaceable) embedded sources from org.eclipse.osgi.services by original bundles from Maven-Central and marks org.eclipse.osgi.services as deprecated.
This should also answer the questions about the difficulties of this replacement.