Replace embedded osgi packages by osgi-bundles from Maven-Central #18

HannesWell · 2022-04-18T18:15:26Z

In M2E we would like to use bnd.lib 6.1 respectively 6.2 (see eclipse-m2e/m2e-core#445) which imports newer version of the following OSGi packages than those that are embedded into org.eclipse.osgi respectively org.eclipse.osgi.util:

org.osgi.util.function 1.2.0 (available 1.1.0)
org.osgi.util.promise 1.2.0 (available 1.1.1)
org.osgi.util.tracker 1.5.4 (available 1.5.3, which is actually sufficient because bnd.lib requires only 1.5)

Furthermore it requires the package the following package that is not embedded into any equinox bundle (at least I did not find it):

org.osgi.service.repository 1.1.0

I assume it is desired to update those packages that are already available to the latest version?
Furthermore I assume to update them I have to copy the sources from the OSGi repository at the latest final release to the corresponding bundle in equinox:
https://github.com/osgi/osgi/releases/tag/r8-core-final-rerelease

How should we handle the missing org.osgi.service.repository?
M2E does not use the repository functionality (AFAICT) but it is required to resolve the bundle.
Should we fetch it from Maven-Central (and make it part of the M2E p2-repo and consequently contribute it to SimRel) or should it be embedded into an Equinox bundle too?

@tjwatson could you please provide some advice?

The text was updated successfully, but these errors were encountered:

bjhargrave · 2022-04-18T18:31:55Z

https://github.com/osgi/osgi/releases/tag/r8-core-final-rerelease

That is not the proper tag for function, promise, or repository which are part of Compendium. The proper tag is https://github.com/osgi/osgi/releases/tag/r8-cmpn-final.

The source jars for these are also on Maven Central.

Should we fetch it from Maven-Central (and make it part of the M2E p2-repo and consequently contribute it to SimRel) or should it be embedded into an Equinox bundle too?

We (Eclipse collectively) should start using things from Maven Central instead of repackaging in things like org.eclipse.osgi.util (which is wrong). We really should phase this bundle out.

Bndtools includes these artifacts in its p2 repo. So if m2e does the same, I would hope p2 will allow use to "share" the same bundles.

HannesWell · 2022-04-18T18:48:10Z

Thank you for the clarification.

Should we fetch it from Maven-Central (and make it part of the M2E p2-repo and consequently contribute it to SimRel) or should it be embedded into an Equinox bundle too?

We (Eclipse collectively) should start using things from Maven Central instead of repackaging in things like org.eclipse.osgi.util (which is wrong). We really should phase this bundle out.

Bndtools includes these artifacts in its p2 repo. So if m2e does the same, I would hope p2 will allow use to "share" the same bundles.

Fully agree, I also wondered if we should do that. My initial assumption in the linked M2E issue that we should not re-supply the packages that are already in org.eclipse.osgi.util was made before the announcement that Maven-Central dependencies can be used directly in SimRel.

So I think the question is more how (announcement, time-frame, ...) should bundles like org.eclipse.osgi.util and org.eclipse.osgi.services (which only seems to contain osgi source code) be phased out? And when we should start to use the jars from Maven-Central (I assume we should not have both).
Technically this should be doable quite fast if everybody is using Import-Package.
If you expect the time-frame to be relatively short I suggest to close this issue and create a new one dedicated to that topic.
We could then also update the bnd.lib immediately in M2E.

tjwatson · 2022-04-18T19:00:42Z

Getting rid of bundles is going to take a long time because of the history of the Eclipse project treating artifact names and versions as API. This predates usage of OSGi by the platform. In the mean time we could consider having org.eclipse.osgi.service and org.eclipse.osgi.util bundles simply require and re-export all the actual bundles published by OSGi for these service packages. That way the same packages (but allowed updated versiosn) are available at runtime as they would be with the old versions of the bundles but the actual content come from the OSGi project released versions and we no longer import the source for these projects into the Equinox source repository. This should reduce the concerns with installing multiple copies of the OSGi API bundles at runtime (assuming p2 correctly limits all the versions to the acceptable versions).

I don't suggest Equinox include any new packages (such as org.osgi.service.repository) in our p2 repositories for the project unless we actually provide implementations of the package. And even then I suggest that we would simply include the API artifact published by the OSGi specification project.

We can update the tracker package source within org.eclipse.osgi any time to pick up the micro version update to 1.5.4.

bjhargrave · 2022-04-18T19:13:28Z

In the mean time we could consider having org.eclipse.osgi.service and org.eclipse.osgi.util bundles simply require and re-export all the actual bundles published by OSGi for these service packages.

YES!

For reference, https://bugs.eclipse.org/bugs/show_bug.cgi?id=431633 seems to be the last attempt to get rid of org.eclipse.osgi.service and org.eclipse.osgi.util bundles.

tjwatson · 2022-04-18T19:18:15Z

YES!

For reference, https://bugs.eclipse.org/bugs/show_bug.cgi?id=431633 seems to be the last attempt to get rid of org.eclipse.osgi.service and org.eclipse.osgi.util bundles.

I think this becomes easier now that we have support in place to directly consume the bundles available in maven central into our repositories in our builds.

@HannesWell is this something you would be willing to look into? I think this would be safe to do from a compatibility standpoint.

bjhargrave · 2022-04-18T19:24:57Z

We can update the tracker package source within org.eclipse.osgi any time to pick up the micro version update to 1.5.4.

The change from 1.5.3 to 1.5.4 was to fix osgi/osgi#148. This fix changed to use nano seconds to wait.

tjwatson · 2022-04-18T19:31:22Z

The change from 1.5.3 to 1.5.4 was to fix osgi/osgi#148. This fix changed to use nano seconds to wait.

I haven't updated the packages in org.eclipse.osgi since the original core R8 release before the Eclipse OSGi WG was formed. I think that update was done when we did the re-release of core R8 under the OSGi WG. Is that correct?

HannesWell · 2022-04-18T19:34:37Z

In the mean time we could consider having org.eclipse.osgi.service and org.eclipse.osgi.util bundles simply require and re-export all the actual bundles published by OSGi for these service packages.

YES!

For reference, https://bugs.eclipse.org/bugs/show_bug.cgi?id=431633 seems to be the last attempt to get rid of org.eclipse.osgi.service and org.eclipse.osgi.util bundles.

Sounds like a very good solution for all our requirements to me as well!

I don't suggest Equinox include any new packages (such as org.osgi.service.repository) in our p2 repositories for the project unless we actually provide implementations of the package. And even then I suggest that we would simply include the API artifact published by the OSGi specification project.

That's reasonable. I just wanted to have mentioned/discussed it. Then we will simply include the OSGi-bundles directly it into the m2e repo.

We can update the tracker package source within org.eclipse.osgi any time to pick up the micro version update to 1.5.4.

For the case of m2e this is not very important at the moment, but I can have a look at that as well.

I think this becomes easier now that we have support in place to directly consume the bundles available in maven central into our repositories in our builds.

@HannesWell is this something you would be willing to look into? I think this would be safe to do from a compatibility standpoint.

Yes, I can take care this and if I don't oversee anything this should indeed be very simple now:
We just have to add the desired bundles from Maven-Central here:
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/eclipse.platform.releng.prereqs.sdk/eclipse-sdk-prereqs.target

And then do what Tom suggested and remove the resources so the plug-in becomes de-facto empty and only contains the Manifest.

To have the Maven-dependencies also available in the dev-workspaces via the Oomph setups I think we have to wait for an I-build, but I will check that.

bjhargrave · 2022-04-18T19:36:21Z

I think that update was done when we did the re-release of core R8 under the OSGi WG. Is that correct?

GitHub tells me that is indeed the case. osgi/osgi@cf7d482

tjwatson · 2022-04-18T21:10:28Z

And then do what Tom suggested and remove the resources so the plug-in becomes de-facto empty and only contains the Manifest.

In case it is not clear, I suggest we remove the Export-Package header completely from these bundles and then have stuff like this in the Require-Bundle header for each bundle we want from OSGi:

Require-Bundle: org.osgi.service.cm; bundle-version="[1.6.0, 1.7.0)"; visibility:="reexport"

In other words pick the minor version we should match to make sure is present for that version of org.eclipse.osgi.service and let micro-version updated versions be selected.

Note that we cannot simply have a range that moves everything to the very latest. For example, before pulling in the latest org.osgi.service.component bundle from the R8 compendium release we need to first update the org.apache.felix.scr bundle to get the R8 implementation.

And speaking of that. The current release of org.apache.felix.scr version 2.2.0 that implements OSGi R8 declarative services version 1.5 also exports the org.osgi.service.component packages. I think I should update Felix SCR to no longer export these packages and force users of org.apache.felix.scr to also have the separate org.osgi.service.component bundle to resolve to use Felix SCR (https://issues.apache.org/jira/browse/FELIX-6521).

The other complication is the org.osgi.service.component.annotations package. This package was never intended to be a runtime package and has been a mistake from the start to export at runtime. We will be disappointed in requiring the OSGi specification org.osgi.service.component.annotations bundle. It will never resolve because it has this requirement:

Require-Capability: osgi.unresolvable;filter:="(&(must.not.resolve=*)(!(must.not.resolve=*)))"

I think PDE is currently depending on this package for its support for processing annotations. I think PDE should pull in this package itself for that purpose. Sorry this is reminding me more and more why these bad bundles are still here.

tjwatson · 2022-04-18T21:15:15Z

Hannes lets start with the util bundle though. That should be something more simple that we can tackle and get the process down more easily.

HannesWell · 2022-04-18T21:46:17Z

The very first part was clear to me, nevertheless thank you for the clarification. :)
Of the part from your remarks regarding versions onwards I was not aware of so it is good you mention it.

The other complication is the org.osgi.service.component.annotations package. This package was never intended to be a runtime package and has been a mistake from the start to export at runtime. We will be disappointed in requiring the OSGi specification org.osgi.service.component.annotations bundle. It will never resolve because it has this requirement:
Require-Capability: osgi.unresolvable;filter:="(&(must.not.resolve=*)(!(must.not.resolve=*)))"

That's a problem. How can this be addressed?
One solution I can think of would be to leave the content only of that package in org.eclipse.osgi.services as it is and replace the others by corresponding re-exported Require-Bundles as you have described. The package would then be exported as as long org.eclipse.osgi.services is not finally removed and would have automatically the same 'deprecation'/removal procedure.

I think PDE is currently depending on this package for its support for processing annotations. I think PDE should pull in this package itself for that purpose. Sorry this is reminding me more and more why these bad bundles are still here.

It is indeed used there. But from my first look I have to impression only the tests relay on it.
Furthermore it looks like PDE embeds the annotation again in its org.eclipse.pde.ds.lib and org.eclipse.pde.ds1_2.lib plugin.
I wonder if those can be replaced by the org.osgi:org.osgi.service.component.annotations bundles from Maven-Central too.
For 1_2 there is the problem that 1.2 is not on Maven-Central.

HannesWell · 2022-04-18T21:48:57Z

Hannes lets start with the util bundle though. That should be something more simple that we can tackle and get the process down more easily.

Sounds good. 👍🏽

tjwatson · 2022-04-19T12:36:50Z

The other complication is the org.osgi.service.component.annotations package. This package was never intended to be a runtime package and has been a mistake from the start to export at runtime. We will be disappointed in requiring the OSGi specification org.osgi.service.component.annotations bundle. It will never resolve because it has this requirement:
Require-Capability: osgi.unresolvable;filter:="(&(must.not.resolve=*)(!(must.not.resolve=*)))"
That's a problem. How can this be addressed? One solution I can think of would be to leave the content only of that package in org.eclipse.osgi.services as it is and replace the others by corresponding re-exported Require-Bundles as you have described. The package would then be exported as as long org.eclipse.osgi.services is not finally removed and would have automatically the same 'deprecation'/removal procedure.

Yes, I think that is the path we need to take now and start the removal process/announcements.

I think PDE is currently depending on this package for its support for processing annotations. I think PDE should pull in this package itself for that purpose. Sorry this is reminding me more and more why these bad bundles are still here.

It is indeed used there. But from my first look I have to impression only the tests relay on it. Furthermore it looks like PDE embeds the annotation again in its org.eclipse.pde.ds.lib and org.eclipse.pde.ds1_2.lib plugin. I wonder if those can be replaced by the org.osgi:org.osgi.service.component.annotations bundles from Maven-Central too. For 1_2 there is the problem that 1.2 is not on Maven-Central.

I think it is more a question of how do typical developers use this annotation processing functionality of PDE. How do they get the annotations added to their classpaths. If they are using Import-Package which binds them at runtime then they are likely getting the content of that package from org.eclipse.osgi.services. So the problem becomes, how to handle such bundles for compilation and furthermore, how do we handle them at runtime when we finally do remove the package from org.eclipse.osgi.services. Do we simply not allow them to resolve?

HannesWell · 2022-04-19T19:46:44Z

That's a problem. How can this be addressed? One solution I can think of would be to leave the content only of that package in org.eclipse.osgi.services as it is and replace the others by corresponding re-exported Require-Bundles as you have described. The package would then be exported as as long org.eclipse.osgi.services is not finally removed and would have automatically the same 'deprecation'/removal procedure.

Yes, I think that is the path we need to take now and start the removal process/announcements.

Alright. Good. It looks like this is feasible. 👍🏽

I think PDE is currently depending on this package for its support for processing annotations. I think PDE should pull in this package itself for that purpose. Sorry this is reminding me more and more why these bad bundles are still here.

It is indeed used there. But from my first look I have to impression only the tests relay on it. Furthermore it looks like PDE embeds the annotation again in its org.eclipse.pde.ds.lib and org.eclipse.pde.ds1_2.lib plugin. I wonder if those can be replaced by the org.osgi:org.osgi.service.component.annotations bundles from Maven-Central too. For 1_2 there is the problem that 1.2 is not on Maven-Central.

I think it is more a question of how do typical developers use this annotation processing functionality of PDE. How do they get the annotations added to their classpaths. If they are using Import-Package which binds them at runtime then they are likely getting the content of that package from org.eclipse.osgi.services. So the problem becomes, how to handle such bundles for compilation and furthermore, how do we handle them at runtime when we finally do remove the package from org.eclipse.osgi.services. Do we simply not allow them to resolve?

The PDE DS Builder/Support has an option to add the annotations implicitly to the classpath so that they don't have to be referenced in the MANIFEST. At the moment this only works in the IDE, but @laeubi added support for Tycho 3.0.0 already:
https://github.com/eclipse/tycho/blob/master/RELEASE_NOTES.md#support-for-pde-declarative-component-annotation-progressing
The PDE DS builder could then warn/error if it spots corresponding imported-packages/required-bundles in the Manifest.MF to encourage users to remove it?

But I suggest we keep the scope of this issue about the compatible replacement of the packages and discuss the migration of PDE in a dedicated issue there.

Besides the already mentioned plug-ins I found the following equinox-plug-ins that embed osgi sources which could/should be replaced in the same way:

org.eclipse.equinox.app
org.eclipse.equinox.coordinator
org.eclipse.equinox.io
org.eclipse.equinox.log.stream

In contrast to the already mentioned plug-ins those also contain own sources so if we reexport the osgi-bundles this would be a more permanent solution.

I assume we will encounter boot-strapping problems when we try to replaced the embedded osgi/felix sources in org.eclipse.osgi, don't we?

tjwatson · 2022-04-19T20:10:24Z

org.eclipse.equinox.io

We no longer build the following bundles and we should remove the source from the main branch I think:

org.eclipse.equinox.io
org.eclipse.equinox.ip
org.eclipse.equinox.util
org.eclipse.equinox.wireadmin

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=533801

I don't recall if there was a particular reason to keep the source in the main branch. But if there was some lingering hope they would become active again I think that time has past and we should be able to safely delete the source now.

tjwatson · 2022-04-19T20:20:26Z

org.eclipse.equinox.app

org.eclipse.equinox.coordinator

org.eclipse.equinox.log.stream

These are not high on my priority list to "fix" because they are at least providing implementations of the org.osgi APIs they export. It does seem that we should at least make them "good citizens" and have them use substitutable imports so that they could use the OSGi specification bundle exports if they are installed.

Ultimately the best solution for these bundles would be to have them only use Import-Package to access the org.osgi packages and not do Require-Bundle re-export. The reason I recommend that approach for the org.eclipse.osgi.services/util bundles was I know there are many in the community of Eclipse plugins that use Require-Bundle to access content from these bundles.

For coordinator and log.stream we can probably safely only use Import-Package for the org.osgi packages and not export any of the org.osgi packages from them. The set of bundles that are using Require-Bundle to access the org.osgi packages from these bundles should be pretty low and it wouldn't be a best practice if they did.

The equinox.app may prove to be a bigger hit to current users. For that one we may need to use Require-Bundle/reexport but it really isn't a great position to be in. On the other hand it probably is a step forward from the current situation.

HannesWell · 2022-04-19T20:46:14Z

org.eclipse.equinox.io

We no longer build the following bundles and we should remove the source from the main branch I think:
* org.eclipse.equinox.io

* org.eclipse.equinox.ip

* org.eclipse.equinox.util

* org.eclipse.equinox.wireadmin
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=533801

I don't recall if there was a particular reason to keep the source in the main branch. But if there was some lingering hope they would become active again I think that time has past and we should be able to safely delete the source now.

Understand. I can create a PR to delete them.
To me it looks like there are some more plug-ins and features that are currently not build and not published.
Could they be deleted as well? This would also allow to leverage Tycho-pomless much better.

HannesWell · 2022-04-19T21:02:07Z

org.eclipse.equinox.app

org.eclipse.equinox.coordinator

org.eclipse.equinox.log.stream

These are not high on my priority list to "fix" because they are at least providing implementations of the org.osgi APIs they export. It does seem that we should at least make them "good citizens" and have them use substitutable imports so that they could use the OSGi specification bundle exports if they are installed.

Ultimately the best solution for these bundles would be to have them only use Import-Package to access the org.osgi packages and not do Require-Bundle re-export. The reason I recommend that approach for the org.eclipse.osgi.services/util bundles was I know there are many in the community of Eclipse plugins that use Require-Bundle to access content from these bundles.

For coordinator and log.stream we can probably safely only use Import-Package for the org.osgi packages and not export any of the org.osgi packages from them. The set of bundles that are using Require-Bundle to access the org.osgi packages from these bundles should be pretty low and it wouldn't be a best practice if they did.

The equinox.app may prove to be a bigger hit to current users. For that one we may need to use Require-Bundle/reexport but it really isn't a great position to be in. On the other hand it probably is a step forward from the current situation.

OK. I would then like to do it step by step then. Lets first tackle equinox-framework and then continue with easy once in equinox-bundles and finish with the hard once.

laeubi · 2022-04-20T04:20:10Z

I think no one will require-bundle the ds annotations, but import-package is quite frequent, but there are already dedicated providers for that package so I don't se a problem to remove that.
In JDT one could mark packages as "discourage" access maybe some kind of "discourage-import" would be possible as well in PDE?

mickaelistria · 2022-04-20T06:21:47Z

That's what "internal" in package names and x-internal flag on export-package are doing.

laeubi · 2022-04-20T06:52:57Z

That's what "internal" in package names

Nope this is just a convention, OSGi has no meaning of "internal exported package" beside that, the OSGi spec defines that package so we can't rename it.

x-internal flag on export-package

yep might be possible to use that flag, but that would require all providers to act on it and I'm not sure it conforms to the spec. This is more a tooling issue, that the DS generator might suggest to remove that import (as it is not forbidden or illegal to import it).

tjwatson · 2022-04-20T12:42:42Z

I think no one will require-bundle the ds annotations, but import-package is quite frequent, but there are already dedicated providers for that package

If you are referring to the one in maven at GAV org.osgi:org.osgi.service.component.annotations:1.5.0 see my #18. This bundle cannot be used to satisfy Import-Package because it will never resolve at runtime.

so I don't se a problem to remove that. In JDT one could mark packages as "discourage" access maybe some kind of "discourage-import" would be possible as well in PDE?

Yes, we could mark these as x-internal to discourage anyone importing them as a warning. The fact remains that PDE (and tycho) need some way to place the annotations on the classpath without requiring the bundle being built to use Require-Bundle or Import-Package to do it. It sounds like we are on a path to such a solution, but that needs to get widely adopted before we can drop the export here I think.

For BND, where it auto calculates the Import-Package header, it detects usage of annotations that have no runtime retention and avoids auto-adding Import-Package for such annotations. Perhaps PDE could detect such things as well and suggest a fix that uses the new approach.

laeubi · 2022-04-20T13:17:09Z

It sounds like we are on a path to such a solution, but that needs to get widely adopted before we can drop the export here I think.

I'm doing my best to enable this and get some acceptance for this, but as you noted its a long way down the road :-)

HannesWell · 2022-04-22T06:46:12Z

The fact remains that PDE (and tycho) need some way to place the annotations on the classpath without requiring the bundle being built to use Require-Bundle or Import-Package to do it.

The PDE DS Builder can do that already. I think the only reason Import-Package is used is that Tycho required it.

To address to problem to encourage users to remove existing Package-Imports/Require-Bundles of org.osgi.service.component.annotations I created eclipse-pde/eclipse.pde#38.

laeubi · 2023-12-20T08:25:04Z

From OSGi POV I think its more to be expsected as part of the OSGI identity for example:

<provided namespace='osgi.identity' name='org.osgi.services' version='3.12'>
       <properties size='1'>
            <property name='type' value='osgi.bundle'/>
            <property name='deprecated' value='true'/>
        </properties>
</provided>

@tjwatson wdyt?

Beside that the touch points seem to include the symbolic name + version for a bundle.

merks · 2023-12-20T08:33:39Z

As long as it's in the p2 metadata somewhere I can make use of it...

laeubi · 2023-12-20T09:36:11Z

I think the place to change this might be org.eclipse.osgi.internal.resolver.StateBuilder.createOsgiIdentityCapability(BundleDescription) but not completely sure, this seems to be where BundlesAction is taking the metadata from the manifest.

The bundle 'o.e.osgi.services' is deprecated for removal as part of eclipse-equinox/equinox#18 and already has been changed to only re-export the 'official' OSGi artifacts published to Maven-Central. It should be replaced by imports of the desired org.osgi.service.* packages so that the runtime can choose a suitable provider independently of the bundle name.

tjwatson · 2023-12-20T14:28:16Z

@tjwatson wdyt?

osgi.identiy capability is derived from the Bundle-SymbolicName header. So attributes for the osgi.identity need to be specified there. Note that capability attributes allowed by the OSGi specification are only 'String' | 'Version' | 'Long' | 'Double'

https://docs.osgi.org/specification/osgi.core/8.0.0/framework.module.html#d0e2870

So there is no Boolean to do something like:

Bundle-SymbolicName: org.eclipse.osgi.services; deprecated:Boolean="true"

You would have to use String (the default value type) "true" or "false" or use something else like Long where 0 is false and 1 is true.

Bundle-SymbolicName: org.eclipse.osgi.services; deprecated:Long="1"

I think the place to change this might be org.eclipse.osgi.internal.resolver.StateBuilder.createOsgiIdentityCapability(BundleDescription) but not completely sure, this seems to be where BundlesAction is taking the metadata from the manifest.

Not sure what context you are using to reference that deprecated implementation of the old deprecated Equinox resolver API. The framework does this here:

equinox/bundles/org.eclipse.osgi/container/src/org/eclipse/osgi/container/builders/OSGiManifestBuilderFactory.java

Lines 310 to 316 in bb97960

    
           // every bundle that has a symbolic name gets an identity; 
        
           // never use the symbolic name alias for the identity namespace 
        
           Map<String, Object> identityAttributes = new HashMap<>(attributes); 
        
           identityAttributes.put(IdentityNamespace.IDENTITY_NAMESPACE, builder.getSymbolicName()); 
        
           identityAttributes.put(IdentityNamespace.CAPABILITY_VERSION_ATTRIBUTE, builder.getVersion()); 
        
           identityAttributes.put(IdentityNamespace.CAPABILITY_TYPE_ATTRIBUTE, isFragment ? IdentityNamespace.TYPE_FRAGMENT : IdentityNamespace.TYPE_BUNDLE); 
        
           builder.addCapability(IdentityNamespace.IDENTITY_NAMESPACE, directives, identityAttributes);

merks · 2023-12-20T14:48:22Z

Note that this is already present:

equinox/bundles/org.eclipse.osgi.services/META-INF/MANIFEST.MF

Line 4 in bb97960

    
           Bundle-SymbolicName: org.eclipse.osgi.services;deprecated:="Deprecated in favour of the original jars published by the OSGi working-group."

So I suppose we should rephrase the question to ask, how best to represent that?

tjwatson · 2023-12-20T14:56:46Z

So I suppose we should rephrase the question to ask, how best to represent that?

Also note that is a directive (assignment with :=) vs an attribute (assignment with =). I could go either way on if deprecated should be an attribute vs. a directive. I've no idea if p2 represents anything about directives in its meta-data.

An attribute has an advantage that it can be used for matching or searching for capabilities in a repository, for example, by using a filter like (deprecated=*) to find all deprecated osgi.identity.

laeubi · 2023-12-21T07:54:07Z

osgi.identiy capability is derived from the Bundle-SymbolicName header. So attributes for the osgi.identity need to be specified there.

It is already there as mentioned by @merks

Note that capability attributes allowed by the OSGi specification are only 'String' | 'Version' | 'Long' | 'Double'

Alright, it was just a quick idea, I think the best would be to just put in the message string, so given this example

equinox/bundles/org.eclipse.osgi.services/META-INF/MANIFEST.MF

Line 4 in bb97960

    
           Bundle-SymbolicName: org.eclipse.osgi.services;deprecated:="Deprecated in favour of the original jars published by the OSGi working-group."

it should be

<provided namespace='osgi.identity' name='org.osgi.services' version='3.12'>
       <properties size='1'>
            <property name='type' value='osgi.bundle'/>
            <property name='deprecated' value='Deprecated in favour of the original jars published by the OSGi working-group.'/>
        </properties>
</provided>

Not sure what context you are using to reference that deprecated implementation of the old deprecated Equinox resolver API.

Sadly P2 is using the old API (or more formally some classes from it), if you look here (public API!):

https://github.com/eclipse-equinox/p2/blob/a795c7f4c05bc215cbe0048f833f7e1949daf412/bundles/org.eclipse.equinox.p2.publisher.eclipse/src/org/eclipse/equinox/p2/publisher/eclipse/BundlesAction.java#L181

org.eclipse.osgi.service.resolver.BundleDescription is used what only implementation seem to reside in the org.eclipse.osgi.compatibility.state it is a bit hard to track back where the capabilities are created but it leads me to the mentioned place.

If you see a way P2 can have its own implementation of org.eclipse.osgi.service.resolver.BundleDescription (e.g. a P2BundleDescription I think we can get rid of the compatibility stuff altogether in P2, the place to change would be org.eclipse.equinox.p2.publisher.eclipse.BundlesAction.createBundleDescription(Dictionary<String, String>, File) that seems the only place where BundleDescription is created.

iloveeclipse · 2023-12-21T15:34:39Z

Question from someone who didn't followed up the entire thread but sees hat org.eclipse.osgi.services bundle is now missing in the SDK - where it is this bundle is supposed to be now? I see at least Egit uses it, so "plain" SDK + Egit doesn't work anymore?

merks · 2023-12-21T15:47:53Z

It's still in the update site:

https://download.eclipse.org/eclipse/updates/4.31-I-builds/I20231221-0400/plugins/org.eclipse.osgi.services_3.12.0.v20231218-2126.jar

So that should be fine, shouldn't it?

iloveeclipse · 2023-12-21T15:53:08Z

So that should be fine, shouldn't it?

One needs also SDK + Egit + IBuild update site to install Egit? One can't simply "drop in" something to SDK that needs org.eclipse.osgi.services? Would this bundle also on the final update site for the release?

Asking because now I can't simply "merge" SDK & Egit & the rest of my offline zip repositories in a script running offline, I need to download some extra bits before, and I don't understand where those bits are supposed to be coming from.

laeubi · 2023-12-21T15:57:29Z

The "bits" should come from the so called "target platform" (that is what egit is build against) so this target will/must include everything egit requires.

iloveeclipse · 2023-12-21T15:58:48Z

OK, the answer is also "we don't care".

laeubi · 2023-12-21T16:05:56Z

OK, the answer is also "we don't care".

Don't understand what you wanted to say with that, I can't find out what egit uses as its prerequisites I can't even find a github repo (or do they use gitlab?), but you seem to know it good enough to look there what they use as there target release.

merks · 2023-12-21T16:21:51Z

In all fairness, I don't think "we" understand what scripts and zips are involved in alternative ways to assemble an installation from parts. So it's not an issue of not caring, but rather one of not understanding. If the SDK installation doesn't need that bundle, then I'm not sure it's a strong argument to say, we should include it anyway because it makes some zip assembly scripts (that we don't understand) simpler...

HannesWell · 2023-12-21T16:27:36Z

OK, the answer is also "we don't care".

Actually we do care, which is why I already reached out to all users and even provided PRs for those where I have the git repos cloned:
#18 (comment)

For EGit especially there is already eclipse-egit/egit#8, which was moved to https://eclipse.gerrithub.io/c/eclipse-egit/egit/+/1173902
IIRC you are a commiter at EGit and I would appreciate a review/submission. :)

The reason why it is not in the SDK anymore is probably because the o.e.sdk feature does not (transitively) contain it anymore and nothing else in the SDK installation requires it so that it is pulled in (which I think is a good news).

As I have written here before or in #403, o.e.osgi.services should stay in the eclipse/updates and simrel repo for the deprecation period so anything that requires it and has one of those p2-repos available can pull it in, if an installation is provisioned with P2.

iloveeclipse · 2023-12-21T16:58:00Z

Actually we do care, which is why I already reached out to all users and even provided PRs

Thanks, I haven't seen that.

IIRC you are a commiter at EGit and I would appreciate a review/submission. :)

I've not yet managed to migrate my account/setup to gerrithub, so I didn't saw the PR mail. I plan to migrate next year after vacation time.

HannesWell · 2023-12-21T17:00:46Z

No problem.

IIRC you are a commiter at EGit and I would appreciate a review/submission. :)

I've not yet managed to migrate my account/setup to gerrithub, so I didn't saw the PR mail. I plan to migrate next year after vacation time.

It is actually quite simple to setup. You can just go to the linked change, click on the login (through GitHub) button, enter your credentials and are then asked by GitHub to grant GerritHub (read) access to a few data from your Github account. And that's it and you should be able to review the change.

The bundle 'o.e.osgi.services' is deprecated for removal as part of eclipse-equinox/equinox#18 and already has been replaced to only re-export the 'official' OSGi artifacts published to Maven-Central. It should be replaced by imports of the desired org.osgi.service.* packages so that the runtime can choose a suitable provider independently of the bundle name. Change-Id: I7cd641671a3298fcb7b0d9dbdd3d0c2ef970a6c3

The bundle o.e.osgi.services has been deprecated for removal as part of eclipse-equinox/equinox#18

New and noteworthy entries for - eclipse-equinox/equinox#18 - eclipse-equinox/equinox#451

HannesWell · 2024-02-17T22:18:52Z

Just created the N&N entry for this:

Add N&N about Equinox bundle depreciations eclipse-platform/www.eclipse.org-eclipse#124

New and noteworthy entries for - eclipse-equinox/equinox#18 - eclipse-equinox/equinox#451

HannesWell · 2024-08-02T13:39:14Z

Except for Acelleo nobody in SimRel uses o.e.osgi.serives anymore. And Accelleo also intends to replace it in time:

Replace dependency to org.eclipse.osgi.services eclipse-acceleo/acceleo#127

HannesWell mentioned this issue Apr 18, 2022

[PDE] update biz.aQute.bndlib and -util to version 6.3.0 eclipse-m2e/m2e-core#445

Merged

HannesWell mentioned this issue Apr 18, 2022

Replace content of o.e.osgi.util by osgi-bundles from Maven-Central eclipse-equinox/equinox.framework#41

Merged

HannesWell changed the title ~~Update embedded osgi packages~~ Replace embedded osgi packages by osgi-bundles from Maven-Central Apr 19, 2022

HannesWell mentioned this issue Apr 19, 2022

Delete code of abandoned equinox-io, -ip, -util and -wireadmin plug-ins eclipse-equinox/equinox.bundles#17

Merged

HannesWell mentioned this issue Apr 22, 2022

Migrate pde.ds to 'org.osgi.service.component.annotations' from Maven-Central eclipse-pde/eclipse.pde#38

Closed

amartya4256 pushed a commit to amartya4256/eclipse.platform.ui that referenced this issue Feb 8, 2024

Remove deprecated o.e.osgi.services bundle from o.e.e4.rcp feature

3b4aeb1

The bundle o.e.osgi.services has been deprecated for removal as part of eclipse-equinox/equinox#18

HannesWell added a commit to HannesWell/www.eclipse.org-eclipse that referenced this issue Feb 17, 2024

Add N&N about Equinox bundle depreciations

1a058a1

New and noteworthy entries for - eclipse-equinox/equinox#18 - eclipse-equinox/equinox#451

HannesWell mentioned this issue Feb 17, 2024

Add N&N about Equinox bundle depreciations eclipse-platform/www.eclipse.org-eclipse#124

Merged

HannesWell mentioned this issue Feb 17, 2024

Deprecate the device service implementation #451

Merged

HannesWell added a commit to HannesWell/www.eclipse.org-eclipse that referenced this issue Feb 17, 2024

Add N&N about Equinox bundle depreciations

7c134e8

New and noteworthy entries for - eclipse-equinox/equinox#18 - eclipse-equinox/equinox#451

HannesWell added a commit to HannesWell/www.eclipse.org-eclipse that referenced this issue Feb 17, 2024

Add N&N about Equinox bundle depreciations

7d070d8

New and noteworthy entries for - eclipse-equinox/equinox#18 - eclipse-equinox/equinox#451

HannesWell added a commit to HannesWell/www.eclipse.org-eclipse that referenced this issue Feb 17, 2024

Add N&N about Equinox bundle depreciations

912ee93

New and noteworthy entries for - eclipse-equinox/equinox#18 - eclipse-equinox/equinox#451

HannesWell added a commit to eclipse-platform/www.eclipse.org-eclipse that referenced this issue Feb 17, 2024

Add N&N about Equinox bundle depreciations

0547373

New and noteworthy entries for - eclipse-equinox/equinox#18 - eclipse-equinox/equinox#451

HannesWell mentioned this issue May 6, 2024

Remove (now) obsolete equinox.launcher.releng and osgi.companion project #611

Merged

Replace embedded osgi packages by osgi-bundles from Maven-Central #18

Replace embedded osgi packages by osgi-bundles from Maven-Central #18

Comments

HannesWell commented Apr 18, 2022 • edited Loading

bjhargrave commented Apr 18, 2022

HannesWell commented Apr 18, 2022

tjwatson commented Apr 18, 2022

bjhargrave commented Apr 18, 2022

tjwatson commented Apr 18, 2022

bjhargrave commented Apr 18, 2022

tjwatson commented Apr 18, 2022

HannesWell commented Apr 18, 2022

bjhargrave commented Apr 18, 2022

tjwatson commented Apr 18, 2022

tjwatson commented Apr 18, 2022

HannesWell commented Apr 18, 2022 • edited Loading

HannesWell commented Apr 18, 2022

tjwatson commented Apr 19, 2022

HannesWell commented Apr 19, 2022

tjwatson commented Apr 19, 2022

tjwatson commented Apr 19, 2022

HannesWell commented Apr 19, 2022

HannesWell commented Apr 19, 2022 • edited Loading

laeubi commented Apr 20, 2022

mickaelistria commented Apr 20, 2022 • edited Loading

laeubi commented Apr 20, 2022

tjwatson commented Apr 20, 2022 • edited Loading

laeubi commented Apr 20, 2022

HannesWell commented Apr 22, 2022

laeubi commented Dec 20, 2023

merks commented Dec 20, 2023

laeubi commented Dec 20, 2023

tjwatson commented Dec 20, 2023

merks commented Dec 20, 2023

tjwatson commented Dec 20, 2023

laeubi commented Dec 21, 2023

iloveeclipse commented Dec 21, 2023

merks commented Dec 21, 2023

iloveeclipse commented Dec 21, 2023

laeubi commented Dec 21, 2023

iloveeclipse commented Dec 21, 2023

laeubi commented Dec 21, 2023 • edited Loading

merks commented Dec 21, 2023

HannesWell commented Dec 21, 2023 • edited Loading

iloveeclipse commented Dec 21, 2023

HannesWell commented Dec 21, 2023 • edited Loading

HannesWell commented Feb 17, 2024

HannesWell commented Aug 2, 2024

HannesWell commented Apr 18, 2022 •

edited

Loading

HannesWell commented Apr 18, 2022 •

edited

Loading

HannesWell commented Apr 19, 2022 •

edited

Loading

mickaelistria commented Apr 20, 2022 •

edited

Loading

tjwatson commented Apr 20, 2022 •

edited

Loading

laeubi commented Dec 21, 2023 •

edited

Loading

HannesWell commented Dec 21, 2023 •

edited

Loading

HannesWell commented Dec 21, 2023 •

edited

Loading