[DS] Validation of transitive generated 'osgi.extender=osgi.component' requirement fails

[HannesWell]

When the dsVersion=1.4 is used the tycho-ds-plugin automatically adds the following requirement to a bundle providing declarative service components:
Require-Capability: osgi.extender; filter:="(&(osgi.extender=osgi.component)(version>=1.4.0)(!(version>=2.0.0)))"

In general this is good to ensure a corresponding service component runtime is available at runtime, but it fails the build of depending projects, probably if they don't contain any DS-component:

[ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:4.0.7:validate-classpath (default-validate-classpath) on project foo.bar2: Execution default-validate-classpath of goal org.eclipse.tycho:tycho-compiler-plugin:4.0.7:validate-classpath failed: org.osgi.framework.BundleException: Bundle foo.bar2 cannot be resolved:foo.bar2 [157]
[ERROR]   Unresolved requirement: Require-Bundle: foo.bar1; bundle-version="4.0.0"
[ERROR]     -> Bundle-SymbolicName: foo.bar1; bundle-version="1.0.0.202405060842"; singleton:="true"
[ERROR]        foo.bar1 [155]
[ERROR]          Unresolved requirement: Require-Capability: osgi.extender; filter:="(&(osgi.extender=osgi.component)(version>=1.4.0)(!(version>=2.0.0)))"

Adding the requirement manually/explicitly to the MANIFEST.MF in the project makes the build work.

[laeubi]

Can you provide an integration-test to demonstrate the issue?

[HannesWell]

Can you provide an integration-test to demonstrate the issue?

I'm working on it.

I forgot the mention that adding the requirement manually/explicitly to the MANIFEST.MF in the project makes the build work. Updated the initial comment.

[laeubi]

I think we should probably provide the capability here as a convenience, it has no real use at the compile stage.

[HannesWell]

I assembled a minimal reproducer and can confirm it is just as described initially: Have a plugin that contains a DS-component with DS version 1.4. Having another plugin depending on the former without a DS component fails. It looks like the failure is independent of if the second project has a DS component or not.

I'll provide the reproducer this evening (my Tycho dev workspace is not set up on this laptop).

I think we should probably provide the capability here as a convenience, it has no real use at the compile stage.

Yes. But what makes me wonder, if I add Require-Capability: osgi.extender;filter:="(&(osgi.extender=osgi.component)(version>=1.4.0)(!(version>=2.0.0)))" explicitly to the MANIFEST it is resolved, even as transitive dependency.
With that I would guess that the resolution context is somehow not correctly updated regarding the generated requirement? But I'm not familiar with that topic.

[mwgmnn]

We switched to tycho 4.0.7 the other day (came from an old 2.6.0) and had the same problem. We helped us by adding a dependency-resolution with eclipse-plugin org.apache.felix.scr to our target-platform-configuration. The workaround with the manually added Require-Capability header works in our environment too, but we don't want to add the header to all of our manifest files.

And we had by the way a similar problem with an optional package import of org.osgi.service.component.annotations, which was not resolved at compile time. Removing the optional attribute fixed this, but we don't want the runtime dependency so we also solved that by adding org.osgi.service.component as a requirement in the dependency-resolution.

We can live with these workarounds but maybe there are better solutions to these resolution problems.

[laeubi]

And we had by the way a similar problem with an optional package import of org.osgi.service.component.annotations, which was not resolved at compile time.

The package org.osgi.service.component.annotations should simply never be imported at all.

[laeubi]

The automatic added header itself can by the way be disabled with that option: https://tycho.eclipseprojects.io/doc/latest/tycho-packaging-plugin/package-plugin-mojo.html#deriveHeaderFromSource

[mwgmnn]

The package org.osgi.service.component.annotations should simply never be imported at all.

Yes, but unfortunately the classes need to be present at compile time because the annotations are used in component - classes so that eclipse is able generate the xml files automatically.

[mwgmnn]

The automatic added header itself can by the way be disabled with that option: https://tycho.eclipseprojects.io/doc/latest/tycho-packaging-plugin/package-plugin-mojo.html#deriveHeaderFromSource

Thanks for the info, looking into it...

[laeubi]

The package org.osgi.service.component.annotations should simply never be imported at all.

Yes, but unfortunately the classes need to be present at compile time because the annotations are used in component - classes so that eclipse is able generate the xml files automatically.

If you are using quite recent Eclipse/Tycho everything will work automatically.

[mwgmnn]

If you are using quite recent Eclipse/Tycho everything will work automatically.

Indeed, you're right, it's functioning without this package import in the current versions. I didn't know that. Thanks for the info.