How to convert plugin.xml file to manifest.mf file as some tags like:
<runtime>
<library name="aaa.jar">
<export name="*"/>
</library>
<runtime>
are seems to be ignored.
Here is some correspondence in the next document, but far from complete reference.
http://www.eclipse.org/eclipse/platform-core/runtime/adoption.html
Open the file in the plugin.xml editor. On the Overview Tab>Plug-in Content section there should be a link, "..., create an OSGi manifest"
The OSGi manifest is a set of headers describing the bundle, the bundles or packages that are dependencies, and the packages this bundle exports. ex:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Eclipse UI Tests
Bundle-SymbolicName: org.eclipse.ui.tests; singleton:=true
Bundle-Version: 3.6.0.qualifier
Bundle-ClassPath: uitests.jar
Bundle-Activator: org.eclipse.core.internal.compatibility.PluginActivator
Bundle-Vendor: Eclipse.org
Require-Bundle: org.eclipse.core.runtime.compatibility,
org.eclipse.core.resources,
org.eclipse.core.expressions,
org.eclipse.ui,
...
Eclipse-AutoStart: true
Export-Package: org.eclipse.ui.tests.api,
org.eclipse.ui.tests.helpers,
org.eclipse.ui.tests.menus
Bundle-RequiredExecutionEnvironment: J2SE-1.4
Related
I have two OSGI bundles(base, dependent), dependent bundle accessing some API of base bundle. When I undeploy base bundle and redeploy it I am getting "Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.module.spec.service."deployment.base-1.0.jar".main is already registered", however undeployment of base bundle was successful.
I want to understand how undeployment of osgi bundle works when there are couple of bundles dependent on it.
Base Bundle Manifest
Manifest-Version: 1.0
Bundle-Activator: com.learning.base.BaseBundleActivator
Bundle-Category: osgi
Bundle-ManifestVersion: 2
Bundle-Name: base
Bundle-SymbolicName: OSGI.base
Bundle-Version: 1.0.0
Created-By: Apache Maven Bundle Plugin
Export-Package: org.osgi.framework;version="1.7",com.learning.base.model;version="1.0.0",com.learning.base.service;version="1.0.0";uses:="com.learning.base.model"
Import-Package: com.learning.base.model;version="[1.0,2)",com.learning.base.service;version="[1.0,2)",javax.security.auth.x500,org.osgi.framework;version="[1.7,2)"
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
Tool: Bnd-3.2.0.201605172007
Dependent Bundle Manifest
Manifest-Version: 1.0
Bundle-Activator: com.learning.dependent.DependentBundleActivator
Bundle-Category: osgi
Bundle-Name: dependent
Bundle-SymbolicName: OSGI.dependent
Bundle-Version: 1.0.0
Created-By: Apache Maven Bundle Plugin
Export-Package: com.learning.dependent.model;version="1.0.0";uses:="com.learning.base.model",com.learning.dependent.service;version="1.0.0";uses:="com.learning.dependent.model,org.osgi.framework"
Import-Package: org.osgi.framework;version="[1.7,2)",com.learning.base.model;version="[1.0,2)",com.learning.base.service;version="[1.0,2)"
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
Tool: Bnd-3.2.0.201605172007
It is known that any dependent plugin in a plugin gets loaded only when referenced portion (of dependent plugin) gets called up due to lazy loading concept . In that case, I have a doubt how does the dependencies in a plugin gets resolved. Is it via the name check in plugin registry ?
Platform plug-in loader checks the plug-in dependencies in MANIFEST.MF file. The content of typical MANIFEST.MF file looks like:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: %Bundle-Name
Bundle-SymbolicName: XXX;singleton:=true
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: XXX
Bundle-Vendor: %Bundle-Vendor
Bundle-Localization: plugin
Eclipse-BundleShape: dir
Require-Bundle: Plugin id 1,
Plugin id 2,
Plugin id 3,
Plugin id 4
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Bundle-ActivationPolicy: lazy
Here Require-Bundle property lists all dependent plug-ins.
Read more about this here
Use this plugin to check dependencies.
im not sure whether its an issue with the plugin or eclipse.Recently im working on this plugin and i was using Indigo /JavaSE7 .When i launch it as an eclipse application im getting my plugin on top. I also exported it as a plugin(export>deployable plugins...) and put in the plugins folder, it is visible and working fine.I tried putting it in Eclipse/Galileo in my machine and it works fine.The problem is When my colleague puts this jar in Eclipse /Indigo Plugins folder(Any other system apart from mine) it is not visible and not even any signs of it.
i'm not sure if it has some thing to do with the JRE/SDK,please help me out.
Im attaching the manifest file if anything missing:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: XTechnologySolutions
Bundle-SymbolicName: com.xquery.review.plugin; singleton:=true
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: com.xquery.review.plugin.Activator
Bundle-Vendor: CognizantTechnologySolutions
Require-Bundle: org.eclipse.ui,
org.eclipse.core.runtime,
org.eclipse.core.resources;bundle-version="3.7.101",
org.eclipse.ui.ide
Bundle-ActivationPolicy: lazy
Bundle-ClassPath: src/lib/log4j-1.2.17.jar,
.,
src/lib/XQueryReview.jar
Import-Package: org.eclipse.jface.text
Bundle-RequiredExecutionEnvironment: JavaSE-1.7
thanks in advance ...
Take a look at the answers from this Stackoverflow post... has good information on how to debug plugin loading issues
Eclipse doesn't load plugins in the dropins folder
I am developing plugin that need to use JDBC driver (mysql-connector-java-5.1.19-bin.jar). When I define path to this jar file in plugin manifest like this:
Bundle-ClassPath: lib/mysql-connector-java-5.1.19-bin.jar
plugin stops to recognize my view and i get this exception:
java.lang.ClassNotFoundException: diplomaproject.views.SampleView
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:494)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:398)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105)
at java.lang.ClassLoader.loadClass(Unknown Source)
at org.eclipse.osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:326)
at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:231)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1193)
...
When i delete line:
Bundle-ClassPath: lib/mysql-connector-java-5.1.19-bin.jar
from manifest, view is working but JDBC connector does not work.
My whole manifest file:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: DiplomaProject
Bundle-SymbolicName: diplomaProject; singleton:=true
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: diplomaproject.Activator
Bundle-Vendor: MYDIPLOMA
Require-Bundle: org.eclipse.ui,
org.eclipse.core.runtime
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Bundle-ActivationPolicy: lazy
Bundle-ClassPath: lib/mysql-connector-java-5.1.19-bin.jar
You have to add a dot ('.') to the bundle class path. This adds all classes compiled from the sources contained in your plug-in to the class path.
The correct property in the manifest should be:
Bundle-ClassPath: lib/mysql-connector-java-5.1.19-bin.jar,
.
You need to add the bundle to the classpath as well. Try this:
Bundle-ClassPath: .,lib/mysql-connector-java-5.1.19-bin.jar
I was facing the same problem.
My build.properties file was changed because of some changes.
I replaced the content from the similler project and it worked.
In my Eclipse runtime, I have the following three plug-ins (file names simplified for better readability):
javax.wsdl.1.4.0.jar
javax.wsdl.1.5.1.jar
eclipse.wsdl.jar, which has a version restriction on the dependency: [1.4.0, 1.5.0)
The dependencies of my own plugin look like this:
eclipse.wsdl
javax.wsdl : "1.4.0"
When my own plugin tries to use the class WSDLFactory, an error would be thrown:
java.lang.LinkageError: loading constraint violation: loader "org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader#a7b0a7b" previously initiated loading for a different type with name "javax/wsdl/factory/WSDLFactory" defined by loader "org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader#7c647c64"
Apparently, my own plug-in loads the 1.5.1 version of WSDLFactory, while eclipse.wsdl loads the 1.4.0 version of WSDLFactory, and this cause the conflict. If I change the version restriction of my plugin to be [1.4.0, 1.5.1), the code would work just fine. However, this is unacceptable since my code needs to support Eclipse 3.5 which forces to use javax.wsdl.1.5.1 intead of 1.4.0.
Are there any way to force my code to use the WSDLFactory loaded by eclipse.wsdl instead of trying to load its own?
And if possible at all, is there a way to force loading the lowest version (instead of highest) bundle?
Update: I tried both Require-Bundle and Import-Package and got different results in dev and release environment. Require-Bundle doesn't work for either one. Import-Package works in the dev environment but not in the release environment.
My question is, while Require-Bundle would try to load classes that are in the highest version of the plugin, does Import-Package NOT behave like that?
The following are corresponding MANIFEST.MF's:
Require-Bundle:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Test
Bundle-SymbolicName: wsdl.classloading.test; singleton:=true
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: wsdl.classloading.test.Activator
Require-Bundle: org.eclipse.ui,
org.eclipse.core.runtime,
org.eclipse.wst.wsdl;bundle-version="1.1.202",
javax.wsdl;bundle-version="1.4.0"
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Bundle-ActivationPolicy: lazy
Import-Package:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Test
Bundle-SymbolicName: wsdl.classloading.test; singleton:=true
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: wsdl.classloading.test.Activator
Require-Bundle: org.eclipse.ui,
org.eclipse.core.runtime,
org.eclipse.wst.wsdl;bundle-version="1.1.202"
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Bundle-ActivationPolicy: lazy
Import-Package: javax.wsdl,
javax.wsdl.factory,
javax.wsdl.xml