Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
HannesWell opened this issue May 6, 2024 · 11 comments · Fixed by #3897
Closed

Comments

@HannesWell
Copy link
Member

HannesWell commented May 6, 2024

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
Copy link
Member

laeubi commented May 6, 2024

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

@HannesWell
Copy link
Member Author

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
Copy link
Member

laeubi commented May 6, 2024

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

@HannesWell
Copy link
Member Author

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.

HannesWell added a commit to HannesWell/tycho that referenced this issue May 7, 2024
Add a minimal reproducer test-case for
'[DS] Validation of transitive generated 'osgi.extender=osgi.component'
requirement fails'
eclipse-tycho#3824
HannesWell added a commit to HannesWell/tycho that referenced this issue May 7, 2024
Add a minimal reproducer test-case for issue
eclipse-tycho#3824

regarding the validation failure of transitive generated
'osgi.extender=osgi.component' requirements in bundles containing DS
components of version 1.4.
@mwgmnn
Copy link

mwgmnn commented May 8, 2024

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
Copy link
Member

laeubi commented May 8, 2024

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
Copy link
Member

laeubi commented May 8, 2024

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
Copy link

mwgmnn commented May 8, 2024

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
Copy link

mwgmnn commented May 8, 2024

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
Copy link
Member

laeubi commented May 8, 2024

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
Copy link

mwgmnn commented May 13, 2024

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.

HannesWell added a commit to HannesWell/tycho that referenced this issue May 20, 2024
Add a minimal reproducer test-case for issue
eclipse-tycho#3824

regarding the validation failure of transitive generated
'osgi.extender=osgi.component' requirements in bundles containing DS
components of version 1.4.
laeubi pushed a commit to HannesWell/tycho that referenced this issue May 31, 2024
Add a minimal reproducer test-case for issue
eclipse-tycho#3824

regarding the validation failure of transitive generated
'osgi.extender=osgi.component' requirements in bundles containing DS
components of version 1.4.
laeubi added a commit to laeubi/tycho that referenced this issue May 31, 2024
Currently Tycho always uses the INITIAL dependency metadata to compute
the preliminary target platform. As this metadata can change once the
project is packed (e.g. headers added / removed) this can lead to
problems in plugins that depend on the changed plugin because P2 sees
the updated metadata afterwards and fails.

This now distinguish both cases and used the SEED metadata if the
project was already packed.

Fix eclipse-tycho#3824
laeubi added a commit to laeubi/tycho that referenced this issue May 31, 2024
Currently Tycho always uses the INITIAL dependency metadata to compute
the preliminary target platform. As this metadata can change once the
project is packed (e.g. headers added / removed) this can lead to
problems in plugins that depend on the changed plugin because P2 sees
the updated metadata afterwards and fails.

This now distinguish both cases and used the SEED metadata if the
project was already packed.

Fix eclipse-tycho#3824
laeubi pushed a commit to laeubi/tycho that referenced this issue Jun 1, 2024
Add a minimal reproducer test-case for issue
eclipse-tycho#3824

regarding the validation failure of transitive generated
'osgi.extender=osgi.component' requirements in bundles containing DS
components of version 1.4.
laeubi added a commit to laeubi/tycho that referenced this issue Jun 1, 2024
Currently Tycho always uses the INITIAL dependency metadata to compute
the preliminary target platform. As this metadata can change once the
project is packed (e.g. headers added / removed) this can lead to
problems in plugins that depend on the changed plugin because P2 sees
the updated metadata afterwards and fails.

This now distinguish both cases and used the SEED metadata if the
project was already packed.

Fix eclipse-tycho#3824
laeubi added a commit to laeubi/tycho that referenced this issue Jun 1, 2024
Currently Tycho always uses the INITIAL dependency metadata to compute
the preliminary target platform. As this metadata can change once the
project is packed (e.g. headers added / removed) this can lead to
problems in plugins that depend on the changed plugin because P2 sees
the updated metadata afterwards and fails.

This now distinguish both cases and used the SEED metadata if the
project was already packed.

Fix eclipse-tycho#3824
laeubi added a commit to laeubi/tycho that referenced this issue Jun 1, 2024
Currently Tycho always uses the INITIAL dependency metadata to compute
the preliminary target platform. As this metadata can change once the
project is packed (e.g. headers added / removed) this can lead to
problems in plugins that depend on the changed plugin because P2 sees
the updated metadata afterwards and fails.

This now distinguish both cases and used the SEED metadata if the
project was already packed.

Fix eclipse-tycho#3824
laeubi pushed a commit to laeubi/tycho that referenced this issue Jun 6, 2024
Add a minimal reproducer test-case for issue
eclipse-tycho#3824

regarding the validation failure of transitive generated
'osgi.extender=osgi.component' requirements in bundles containing DS
components of version 1.4.
laeubi added a commit to laeubi/tycho that referenced this issue Jun 6, 2024
Currently Tycho always uses the INITIAL dependency metadata to compute
the preliminary target platform. As this metadata can change once the
project is packed (e.g. headers added / removed) this can lead to
problems in plugins that depend on the changed plugin because P2 sees
the updated metadata afterwards and fails.

This now distinguish both cases and used the SEED metadata if the
project was already packed.

Fix eclipse-tycho#3824
laeubi pushed a commit to laeubi/tycho that referenced this issue Jun 8, 2024
Add a minimal reproducer test-case for issue
eclipse-tycho#3824

regarding the validation failure of transitive generated
'osgi.extender=osgi.component' requirements in bundles containing DS
components of version 1.4.
laeubi added a commit to laeubi/tycho that referenced this issue Jun 8, 2024
Currently Tycho always uses the INITIAL dependency metadata to compute
the preliminary target platform. As this metadata can change once the
project is packed (e.g. headers added / removed) this can lead to
problems in plugins that depend on the changed plugin because P2 sees
the updated metadata afterwards and fails.

This now distinguish both cases and used the SEED metadata if the
project was already packed.

Fix eclipse-tycho#3824
laeubi pushed a commit that referenced this issue Jun 8, 2024
Add a minimal reproducer test-case for issue
#3824

regarding the validation failure of transitive generated
'osgi.extender=osgi.component' requirements in bundles containing DS
components of version 1.4.
laeubi added a commit that referenced this issue Jun 8, 2024
Currently Tycho always uses the INITIAL dependency metadata to compute
the preliminary target platform. As this metadata can change once the
project is packed (e.g. headers added / removed) this can lead to
problems in plugins that depend on the changed plugin because P2 sees
the updated metadata afterwards and fails.

This now distinguish both cases and used the SEED metadata if the
project was already packed.

Fix #3824
eclipse-tycho-bot pushed a commit that referenced this issue Jun 8, 2024
Add a minimal reproducer test-case for issue
#3824

regarding the validation failure of transitive generated
'osgi.extender=osgi.component' requirements in bundles containing DS
components of version 1.4.

(cherry picked from commit 6394de5)
eclipse-tycho-bot pushed a commit that referenced this issue Jun 8, 2024
Currently Tycho always uses the INITIAL dependency metadata to compute
the preliminary target platform. As this metadata can change once the
project is packed (e.g. headers added / removed) this can lead to
problems in plugins that depend on the changed plugin because P2 sees
the updated metadata afterwards and fails.

This now distinguish both cases and used the SEED metadata if the
project was already packed.

Fix #3824

(cherry picked from commit fc91332)
eclipse-tycho-bot pushed a commit that referenced this issue Jun 8, 2024
Add a minimal reproducer test-case for issue
#3824

regarding the validation failure of transitive generated
'osgi.extender=osgi.component' requirements in bundles containing DS
components of version 1.4.

(cherry picked from commit 6394de5)
eclipse-tycho-bot pushed a commit that referenced this issue Jun 8, 2024
Currently Tycho always uses the INITIAL dependency metadata to compute
the preliminary target platform. As this metadata can change once the
project is packed (e.g. headers added / removed) this can lead to
problems in plugins that depend on the changed plugin because P2 sees
the updated metadata afterwards and fails.

This now distinguish both cases and used the SEED metadata if the
project was already packed.

Fix #3824

(cherry picked from commit fc91332)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants