Community
Participate
Working Groups
I'm getting compile errors in a fragment project since the classes from a plugin which is declared as optional in the host plugin cannot be resolved. In eclipse this is not a problem. All dependencies, also the optional, are available in the fragments without explicit declaring in the manifest of the fragment. So the tycho behavior is deviant to the eclipse behavior. In my opinion it is not clear that I have to declare this twice. Once in the host and once in the fragements plugin.
There is also a little discussion: http://stackoverflow.com/questions/12670049/optional-dependency-of-host-is-not-available-in-fragment
For optional runtime dependencies declared in a bundle or fragment, we assume that by default these dependencies are needed at compile time (because this is the most common use case). The same reasoning could also apply to fragments: We could say that optional runtime dependencies of the host are probably needed as compile time dependencies of the fragment. I don't have the use case myself, so I am unsure if we really want this. @Michael: What is the concrete optional dependency from the host that you also need in the fragment?
I wrote an application using Single-Sourcing with RCP and RAP. Therefore I have code fragments which rely on RAP-target-platform for the RAP-Application and also code fragments which rely on RCP-target-platform. In my host plugin I must declare both of them and I must declare it as optional, e. g. org.eclipse.ui and org.eclipse.rap.ui. Depending on the selected target platform eclipse use the correct dependency.
(In reply to comment #3) > I wrote an application using Single-Sourcing with RCP and RAP. Therefore I > have code fragments which rely on RAP-target-platform for the > RAP-Application and also code fragments which rely on RCP-target-platform. > In my host plugin I must declare both of them and I must declare it as > optional, e. g. org.eclipse.ui and org.eclipse.rap.ui. Depending on the > selected target platform eclipse use the correct dependency. There is no way for Tycho to know if it should use org.eclipse.ui or org.eclipse.rap.ui during the build. You need to select which ui framework to use during the build using something like this (going from memory, check ITs for exact syntax) <plugin> <groupId>org.eclipse.tycho</groupId> <artifactId>target-platform-configuration</artifactId> <version>${tycho-version}</version> <configuration> <dependency-resolution> <optionalDependencies>ignore</optionalDependencies> <extraRequirements> <requirement> <type>eclipse-plugin</type> <id>org.eclipse.ui</id> <versionRange>0.0.0</versionRange> </requirement> </extraRequirements> </dependency-resolution> </configuration> </plugin>
(In reply to Tobias Oberlies from comment #2) > For optional runtime dependencies declared in a bundle or fragment, we > assume that by default these dependencies are needed at compile time > (because this is the most common use case). The same reasoning could also > apply to fragments: We could say that optional runtime dependencies of the > host are probably needed as compile time dependencies of the fragment. This reasoning sounds correct. > I don't have the use case myself, so I am unsure if we really want this. Here's a use case: Your host bundle uses @Nullable and friends from org.eclipse.jdt.annotations. As these annotations have RetentionPolicy.CLASS, they are not needed at runtime. Hence Require-Bundle: org.eclipse.jdt.annotation;resolution:=optional seems reasonable in the host bundle. Alas, using annotations from org.eclipse.jdt.annotations in the fragment leads to compile errors: [ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:0.24.0:compile (default-compile) on project org.example.tests: Compilation failure: Compilation failure: [ERROR] /tmp/org.example.tests/src/org/example/package-info.java:[1] [ERROR] /** [ERROR] ^ [ERROR] The type org.eclipse.jdt.annotation.NonNullByDefault cannot be resolved. It is indirectly referenced from required .class files
(In reply to Andreas Sewe from comment #5) > Alas, using annotations from > org.eclipse.jdt.annotations in the fragment leads to compile errors: > > [ERROR] Failed to execute goal > org.eclipse.tycho:tycho-compiler-plugin:0.24.0:compile (default-compile) on > project org.example.tests: Compilation failure: Compilation failure: > [ERROR] /tmp/org.example.tests/src/org/example/package-info.java:[1] > [ERROR] /** > [ERROR] ^ > [ERROR] The type org.eclipse.jdt.annotation.NonNullByDefault cannot be > resolved. It is indirectly referenced from required .class files Of course, you can get rid of these compile errors my placing a *redundant* requirement on org.eclipse.jdt.annotations on the fragment -- but you have to do it *manually* in a text editor, as PDE's manifest editor refuses to add a dependency to a fragment when it is already present in the host.
Eclipse Tycho is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse/tycho/issues/ instead. If this issue is relevant to you, your action is required. 0. Verify this issue is still happening with latest Tycho 2.4.0-SNAPSHOT if issue has disappeared, please change status of this issue to "CLOSED WORKFORME" with some details about your testing environment and how you did verify the issue; and you're done if issue is still present when latest release: * Create a new issue at https://github.com/eclipse/tycho/issues/ ** Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience) ** In the GitHub description, start with a link to this bugzilla ticket ** Optionally add new content to the description if it can helps towards resolution ** Submit GitHub issue * Update bugzilla ticket ** Add to "See also" property (up right column) the link to the newly created GitHub issue ** Add a comment "Migrated to <link-to-newly-created-GitHub-issue>" ** Set status as CLOSED MOVED ** Submit All issues that remain open will be automatically closed next week or so. Then the Bugzilla component for Tycho will be archived and made read-only.
