I have a RCP application which constitutes of a number of plugins. And now, I try to develop RAP application which uses my old plugins. My RAP has a dependency of one old plugin. I created my own target platform and I added RAP sdk and other many eclipse platform libraries. When I run my RAP application, I get this exception. Do you have any idea to solve that? Depended plugin uses "org.eclipse.ui" package.
org.osgi.framework.BundleException: The bundle could not be resolved. Reason: Missing Constraint: Require-Bundle: org.unicase.link; bundle-version="1.0.0"
at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1313)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1297)
at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:319)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:370)
at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1069)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:554)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:461)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:246)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:442)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:227)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:337)
2009-12-02 01:13:23.625::WARN: ERROR: /rap
java.lang.IllegalArgumentException: An entry point named 'hello' does not exist.
at org.eclipse.rwt.internal.lifecycle.EntryPointManager.createUI(EntryPointManager.java:77)
at org.eclipse.rwt.internal.lifecycle.RWTLifeCycle.createUI(RWTLifeCycle.java:227)
at org.eclipse.rwt.internal.lifecycle.RWTLifeCycle$UIThreadController.run(RWTLifeCycle.java:115)
at java.lang.Thread.run(Unknown Source)
at org.eclipse.rwt.internal.lifecycle.UIThread.run(UIThread.java:80)
It's failing because it can't load the org.unicase.link bundle. And the reason that it can't load that is probably a missing dependency in that bundle. So look in the manifest for that plugin and look at all of the dependent plugins and make sure they are all there. It should also have a list for the plugins that were not loaded for some reason in the log. One thing you can do is make all of the dependencies in the org.unicase.link bundle optional, which should get you further along.
Related
If I specify JavaSE-10 as minimum execution environment in my Eclipse plugin:
I get following errors when starting my plugin as Eclipse Application:
org.osgi.framework.BundleException: Could not resolve module: org.treez.core [597]
Unresolved requirement: Require-Capability: osgi.ee; filter:="(&(osgi.ee=JavaSE)(version=10))"
Unresolved requirement: Require-Bundle: org.treez.javafxd3; visibility:="reexport"
-> Bundle-SymbolicName: org.treez.javafxd3; bundle-version="1.0.0.qualifier"; singleton:="true"
org.treez.javafxd3 [586]
Unresolved requirement: Require-Capability: osgi.ee; filter:="(&(osgi.ee=JavaSE)(version=10))"
at org.eclipse.osgi.container.Module.start(Module.java:444)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1634)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1613)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1585)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1528)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
I checked that
Java10 is reverenced under Installed JREs
10 is selected as compliance level
I use Oxygen.3a Release (4.7.3a) Build id: 20180405-1200
=>Is this a bug in eclipse equinox?
=>What else can I check to resolve this issue?
If I remove JavaSE-10 from the minimum execution environment settings I am able to start the Eclipse Application and the plugin seems to work fine.
When I export the plugin I get following warning:
# 25.04.18, 12:25:40 MESZ
# Eclipse Compiler for Java(TM) v20180330-0919, 3.13.102, Copyright IBM Corp 2000, 2015. All rights reserved.
option -bootclasspath not supported at compliance level 9 and above
When I try to use the plugin after installing it from my update page, I get a ClassNotFoundException:
...
Caused by: java.lang.ClassNotFoundException: org.treez.views.tree.TreeViewPart cannot be found by org.treez.views_1.0.0.201804191641
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:484)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:395)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:387)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:499)
at org.eclipse.osgi.internal.framework.EquinoxBundle.loadClass(EquinoxBundle.java:564)
at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:174)
... 114 more
If I use Java8 everything works fine.
Related questions:
Java 8 & Missing required capability Require-Capability: osgi.ee; filter="(&(osgi.ee=JavaSE)(version=1.8))"
How to set up java 10 in Eclipse Oxygen?
How to add org.eclipse.swt (and other plugin dependencies) as an automatic Java9 module?
It looks like Eclipse OSGi does not support Java SE 10 yet. I downloaded the latest Eclipse Oxygen 4.7.3a and opened plugins/org.eclipse.osgi_3.12.100.v20180210-1608.jar. The last supported profile was JavaSE-9.
So, you have two choices here:
Wait until OSGi officially supports JavaSE-10 profile.
If you really want to write a plugin with Java 10 and you have control over the plugins folder (e.g. you develop an Eclipse RCP application), open the OSGI jar and add a new profile JavaSE-10. To do this, you can copy JavaSE-9.profile to JavaSE-10.profile and fix corresponding lines in the new file. Also, you must add a new line to profile.list.
Since OSGi 4.3, the most appropriate way to specify a minimum Java version is using the Required-Capability header, as in:
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version>=1.10))"
I have had success fixing the reported error by replacing all occurrences of Bundle-RequiredExecutionEnvironment with the above line. In PDE, you may get a warning on the manifest file, but it can be safely ignored. Product validation and product exports seems to work without issue.
The semantic of the BREE header required that an execution environnement descriptor be provided by the OSGi implementation for each specific release of the JRE. In Equinox, this used to be defined through ".profile" files; these profiles have been supported by Equinox up to JavaSE-9, but it has been announced that Equinox they would no longer provide profiles for newer releases of Java.
The Tycho community has handled this issue on their side by creating their own Java 10 profile, but it can't be used directly from PDE. The P2 community is considering copying Tycho's Java 10 profile, but this has been stalled for a long time. I'm not sure how P2 reacts at present when fed bundles that do not contains the BREE header.
What worked for me as a work around was to
Remove the required version entries from the manifest files and ignore the corresponding warnings
Activate the option "Use class files compiled in the workspace" in the export wizard:
(Therefore I assume that something goes wrong during the compilation step of the export wizard if that option is not applied.)
I used Java 11.0.1 and Eclipse SimRel 2018-09 (plus Java11 support plugin)
I've managed to get JUnit 4.12 + Hamcrest 1.3 + Mockito 2.8.47 to work in Eclipse so that when I add them as dependencies, my tests will run.
(The way I've done this is using the p2-maven-plugin to bundle the following
artifacts from Maven Central into plugins/a feature and provide them via P2:
junit 4.12
org.mockito.mockito-core 2.8.47
org.hamcrest.all 1.3.0
Adding the plugins to my test fragment as dependencies makes the tests
run in Eclipse.
However, the Tycho build of the same fragment will fail with the
following messages:
java.lang.LinkageError: loader constraint violation: loader (instance of org/eclipse/osgi/internal/loader/EquinoxClassLoader) previously initiated loading for a different type with name "org/hamcrest/Matcher"
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.defineClass(ModuleClassLoader.java:273)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.defineClass(ClasspathManager.java:632)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findClassImpl(ClasspathManager.java:586)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClassImpl(ClasspathManager.java:538)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:525)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:325)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:345)
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:423)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:372)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:364)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:161)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:12)
at org.junit.Assert.assertThat(Assert.java:956)
at org.junit.Assert.assertThat(Assert.java:923)
So it seems that some other plugin is loading the package
org.hamcrest.Matcher before my fragment does. This is probably due
to the import/export/partial import/partial export chaos surrounding the
JUnit/Hamcrest/Mockito setup.
Does anyone have an idea -- or even better: a working example -- of how to
get the three components work together both within the IDE (for quick
checks on whether tests run) and Tycho (for checks during the build)?
Seems like that the loader want the dependencies in a bundle.
But I guess you haven't put your test lib in a bundle.
You could try to add them in the dependencies of your product to see how it reacts.
Background
The root of the problem is, that org.junit already has a dependency to org.hamcrest.core. So when your test-plugins has a dependency to org.hamcrest.all (which contains everything of hamcrest-core and all other hamcrest artifacts), all classes specified in hamcrest-core exist twice. Once in the bundle of hamcrest-core and once in hamcrest-all, which is why you get the linkage error.
If you open the Manifest of org.junit in the Manifest-Editor of Eclipse and go to the 'Dependencies' tab it should show you org.hamcreast.core in the "Required Plug-ins" section and org.hamcreast.core should be re-exported. Or in the raw-manifest it should look like this:
Require-Bundle: org.hamcrest.core;bundle-version="1.3.0";visibility:=reexport
Solution 1 - add hamcrest sub-modules
Instead of adding the all hamcrest-modul containing hamcrest.all as dependency to my Eclipse test-bundle/project (via 'Require-Bundle'), I add the hamcrest sub-modules that I require, except for hamcrest-core (because it is already re-exported in my case). For me hamcrest-library was sufficient.
The available hamcrest sub-modules are (according to the org.hamcrest:hamcrest-parent pom, which can be found here: https://repo1.maven.org/maven2/org/hamcrest/hamcrest-parent/1.3/hamcrest-parent-1.3.pom):
hamcrest-core
hamcrest-library
hamcrest-generator
hamcrest-integration
Creating the p2-Repo containing the required bundles
When using Maven and the 'org.reficio:p2-maven-plugin' to build the p2-repo that contains the mentioned test-bundles, the conversion of the maven-artifacts to OSGi-bundles does not produce fully working results by default.
Converting a maven-module to a full OSGi-bundle consists mainly of configuring the MANIFEST.MF to contain proper entries. For this the p2-maven-plugin utilizes "bnd tool".
By default the Java packages provided by all maven dependencies of a maven module are added as optional Imported-package when that module is converted into a OSGi-bundle.
In my case this had the consequence that the org.hamcrest.library bundle refereed to the packages from hamcrest-core only via Import-Package in its MANIFEST.MF.
But unfortunately with only this specified, the Equinox-ClassLoader did not find the classes from hamcrest-core in the test-runtime and threw a corresponding exception. Maybe this is also caused by the fact that hamcrest-core and hamcrest-library have a package "org.hamcrest" and bnd-tools adds the exported packages of a bundle to the imported packages again.
The solution in my case was to instruct the org.reficio:p2-maven-plugin respectively bnd-tools to add org.hamcrest.core as "Require-Bundle" to the Manifest of hamcrest-library. For this, the instructions-element shown below needs to be add to the artifact-element of org.hamcrest:hamcrest-library in the execution-configuration of the 'p2-maven-plugin' in the pom.xml used to build the p2-repo:
<artifact>
<id>org.hamcrest:hamcrest-library:1.3</id>
<instructions>
<Require-Bundle>org.hamcrest.core</Require-Bundle>
</instructions>
</artifact>
If hamcrest sub-modules other than hamcrest-library are are used, the instructions need to be analogous, corresponding to the dependencies listed in their pom.
Edit
Eclipse Orbit provides org.hamcrest.library, org.hamcrest.integrator and org.hamcrest.generator bundles that have have org.hamcrest.core as required bundle (if necessary):
https://download.eclipse.org/tools/orbit/downloads/
Appendix
In the end first solution caused a SecurityException:
java.lang.SecurityException: class "org.hamcrest.Matchers"'s signer information does not match signer information of other classes in the same package
Which is a known issue. The following two solutions avoid this issue and work properly during Tycho builds and from within Eclipse.
Solution 2 - bundle hamcrest sub-module jars with a plug-in
Another approach is to download the jar of the required hamcrest sub-module and bundle it with a Eclipse plugin directly, like it is described here:
https://www.vogella.com/tutorials/Hamcrest/article.html#hamcrest_eclipse
To bundle the jar with a plug-in, include it in the project and add it to the plug-ins classpath. Go to the Runtime-Tab of the Manifest-Editor and klick Add... in the Classpath section and select the jar. This should add the jar to the .classpath, MANIFEST.MF and build.properties file properly.
Make sure the jar is included before the other plug-in dependencies (which include hamcrest-core), as stated in the mentioned tutorial.
If hamcrest should be used in multiple test-projects/fragments, add the jar to a test plug-in all other test-projects depend on.
Solution 3 - use org.hamcrest 2.x
Since hamcrest-2 there is only one org.hamcrest jar/artifact that includes everything from hamcrest. Using hamcrest 2 avoids all the issues and is my preferred solution. Except for the changed packaing of hamcrest the API did not break, so it should be sufficient to just include org.hamcrest:
https://github.com/hamcrest/JavaHamcrest/releases/tag/v2.1
In order to create a p2-repo that includes org.hamcrest-2.2 the following sippet has to be included into the configuration-artifacts element of the p2-maven-plugin execution in the pom.xml:
<artifact>
<id>org.hamcrest:hamcrest-core:2.2</id>
<instructions>
<Require-Bundle>org.hamcrest;bundle-version="2.2.0";visibility:=reexport</Require-Bundle>
</instructions>
</artifact>
<artifact>
<id>org.hamcrest:hamcrest:2.2</id>
</artifact>
The IUs org.hamcrest.core 2.2 and org.hamcrest have to be included in the target-platform to make them available for plug-ins in Eclipse and during. All plug-ins which depend on org.junit now have org.hamcrest also available.
This aproach works because org.hamcrest.core still exists in version 2 stream, even tough it is deprected and empty. Its only purpose is to redirect build-systems to the new org.hamcrest-2.x jar/artifact. Therefore org.hamcrest.core-2.2 specifies a compile dependency to
org.hamcrest-2.2 in its pom.xml. Unfortunately the p2-maven-plugin dosn't translate it directly into a bundle-requirement for org.hamcrest in the manifest, but with the sippet above enforces that.
Because org.junit requires the bundle org.hamcrest.core with a minimal version of 1.3 (but without upper-bound) it uses the present org.hamcrest.core-2.2 . org.hamcrest.core-2.2 again requires org.hamcrest-2.2 and re-exports it. This makes org.junit use org.hamcrest-2.2 in the end and because org.junit re-exports hamcrest-core it also provides org.hamcrest-2.2 immediately to all depended plug-ins.
Note
If you want to play around with different variants of a jar, don't forget to clear (means delete on the drive) the bundle pools of Maven (in <your-home>/.m2/repository/p2/osgi/bundle/ and Eclipse PDE (in <your-workspace>/.metadata/.plugins/org.eclipse.pde.core/.bundle_pool/) in between. Otherwise you will always use the first one, because jar's with the same version are not updated.
We have a large OSGi project with some own bundles and hundreds of third parties bundles.
After some tweaking of dependencies, we were able to produce a valid Launch Configuration that runs correctly and a product/feature configuration that builds correctly (via IDE of Eclipse Luna) and generates a valid executable.
So far so good with IDE PDE build.
Now we want to run the build in the headless way. We have followed the tutorial for Eclipse Luna (http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Ftasks%2Fpde_feature_build.htm) and set-up a headless build environment. We use the same product/feature files as before but now we got unresolved uses directives and the build fails.
The environment looks sane, since we can build headless other (smaller) applications with no problems.
Digging in some of the problems, we have seen that some of them refers to OPTIONAL imports not resolved... To my understanding they should not complain.
Example:
[java] C:\Program Files\eclipse_Luna\plugins\org.eclipse.pde.build_3.9.0.v20140415-2029\scripts\genericTargets.xml:
111: Processing inclusion from feature snapp.feature: Bundle org.apache.servicemix.bundles.jaxb-impl_2.2.1.1_2 failed to
resolve.:
[java] Package uses conflict: Import-Package: javax.xml.bind; version="[2.2.0,3.0.0)"
[java] Package uses conflict: Import-Package: javax.xml.bind.attachment; version="[2.2.0,3.0.0)"
[java] Package uses conflict: Import-Package: javax.xml.bind.helpers; version="[2.2.0,3.0.0)"
[java] Unsatisfied import package org.jvnet.staxex_0.0.0.
Since we have thousands of third parties uses directives, of course we are not going to hack the manifest of all the involved bundles...
Why does the headless build is so picky about the uses directives? Is there any way to instruct headless PDE to skip this kind of checks?
Thank you in advance!
I am getting NPE exception for p2.console while accessing it.
osgi> provaddrepo http://localhost:8080/Site
gogo: NullPointerException: null
osgi> provaddmetadatarepo http://localhost:8080/Site
gogo: NullPointerException: null
osgi> provinstall org.eclipse.egit.feature.group 0.8.4
gogo: NullPointerException: null
osgi>
I am also getting same exception from my custom mail application.
java.lang.NullPointerException at
org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadIndexFile(AbstractRepositoryManager.java:721)
I didnot understand the meaning of "no transport available"
Or how to check transport bundles. I checked ecf bundles which were installed on my equinox.
I am using eclipse juno
Do anyone has any solution, tutorial for p2.console etc ?
You need to have a bundle in your Equinox runtime that provides the transport service for p2. AFAIK, p2 only provides one implementation of that service, which is in the bundle org.eclipse.equinox.p2.transport.ecf.
For a full list of bundles needed to make p2 work, you can for example consult this product definition in the Tycho project sources.
I have created one workbench application plugin not eclipse rcp application. I have not created any plugin template for that workbench application.
Now When I run the workbench application Activator is not calling. I put System.out.println("Insided start()") inside the start method of the
Activator.java. But it is not calling the start method. How I make call the start method? But when I make the option,Autostart=true in the runconfiguration,plug-ins,
It is starting the activator. But the problem is When I call IWorkbenchWindow window = Workbench.getInstance().getActiveWorkbenchWindow();
It is giving the error message saying could not create the workbench window. This error message is giving only when I make this plugin as AutoStart=true. What couldbe the problem?
Following are the error message I get..When I use
IWorkbenchWindow window = PlatformUI.getWorkbench().getActiveWorkbenchWindow();
java.lang.IllegalStateException: Workbench has not been created yet.
at org.eclipse.ui.PlatformUI.getWorkbench(PlatformUI.java:92) at
myworkbenchplugin.Activator.custom(Activator.java:43) at
myworkbenchplugin.Activator.start(Activator.java:36) at
org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783)
at java.security.AccessController.doPrivileged(Native Method) at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774)
at
org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:755)
at
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:370)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:374)
at
org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1067)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:561)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:546)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:459)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243)
at
org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:440)
at
org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:227)
at
org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:337)
As you already saw, you need to manage your OSGi bundle manifest to specify the right activation policy. Note though that:
The Eclipse-AutoStart and Eclipse-LazyStart headers have been deprecated in Eclipse 3.4.
As of the OSGi R4.1 specification the lazy activation policy has been adopted by the OSGi specification. The new OSGi bundle manifest header Bundle-ActivationPolicy can be used to specify a lazy activation policy.
The Equinox Framework version 3.4 or later will continue to support the deprecated Eclipse-LazyStart and Eclipse-AutoStart headers.
Bundle developers that want their bundles to work across other OSGi Framework implementations should add the Bundle-ActivationPolicy header to their manifest. In most cases you can simply add the following header:
Bundle-ActivationPolicy: lazy
See OSGi LazyStart design.
In your case, you can try Bundle-ActivationPolicy: lazy;exclude:="yourPluginId" if you want to be sure your plugin starts no matter what.
For getting the Active WorkbenchWindow, you can use PlatformUI.getWorkbench().getActiveWorkbenchWindow() as detailed in How to get the project name in eclipse?.
If you start your plugin when Eclipse starts, the Activator.start() will be called before the workbench is fully started. You need to push the code inside a UIJob/WorkbenchJob in the Activator, so that it will be called after the workbench windows are ready.