I have a plugin which at present doesn't have any extension points (neither does it extend any other plugin). To resolve a certain issue I have to create an extension-point for this plugin and an appropriate extension somewhere else.
When doing this eclipse forced me to set singleton:=true in the Manifest file. I know the reason why this parameter has to be set, but I wanted to know if there are any implications on the functioning of the plugin within the product by introducing this parameter.
Thank you.
"singleton:=true" means that bundle only have one version could exist in the OSGi runtime.
Eclipse automatically adds the flag due to you provide an extension point in your bundle. If there are two version of your bundles providing the same extension point(have the same identity, might different attributes or elements) would make things mess.
From the Book Eclipse plugin Development by Dr Alex Blewitt:
The clause
singleton:=true
is an OSGi directive, which means that only one version of this plug-in can be installed in Eclipse at one time.
For plug-ins which add dependencies to the UI, there is a restriction that they must be singletons. (This constraint is one of the main reasons why installing a new plug-requires the IDE to restart.)
Related
I have this problem:
I have two Liferay projects, one with the 1.6 plugin and one with the 2.2 plugin. When I deploy My project called IPF-Hook in the 1.6, it deploys with the name IPF-Hook.
The problem is when I deploy my project with the 2.2. It deploys with the name: IPF-Hook-portlet (it adds portlet).
Anyone knows something about that? thank you so much!
Despite the comments (I still have no clue what versions you're talking about), now I'm seeing something that I've missed in the comments
Liferay uses a heuristic to detect the type of plugin that's deployed. This can be helped by naming a plugin *-hook, *-portlet, *-theme etc. . Typically you rather want to help Liferay than depend on the heuristic, thus the development environment tries its best to enforce this naming best practice.
Your hook seems to be named *-Hook (note the capital H) - rename it to have a lower case extension (-hook) and try again. Then it shouldn't be renamed any more.
If you're using the plugins sdk, check that this hook is indeed in the hook folder, not in the portlets folder.
I've created an feature-based Eclipse product where all dependencies respectively external plugins are specified in a dependencies feature project. Some dependencies need different versions of the same plugin. How can I specify several versions of a plugin in a feature.xml? Eclipse seems to always use the current version of a plugin. I've tried to add a dependency with a strict version interval, e.g. [1.6.0.v201011041432,1.6.0.v201011041432], in the feature.xml but Eclipse doesn't accept this format.
I had a similar problem when running a feature based product within Eclipse (Kepler) where multiple versions of the same bundle were involved.
In the end I used a workaround - I changed the symbolic names of the bundles, so they all have different names. If you consequently use Import-Package instead of Require-Bundle this will make no difference in the dependencies you define for bundles or in the OSGi runtime, only in your Feature definition.
This solution is not pretty, but at least it's rather easy to do.
Thinking about that OSGi is intended to target exactly this kind of use case where you have multiple versions of the same dependency/bundle it's rather strange how bad the support in Eclipse is, if you actually have this kind of use case.
I'd like to force p2 so set singleton='false' to some of my bundle that are defined as singleton in their manifest.
I know that multiple singleton plugins cannot be activated at the same time in an Eclipse runtime, but I would like them to be installed (no in the OSGI sense), meaning present on the disc. I have implemented my own configurator to activate the required bundle according to some license file.
I have tried to modify the content.xml manually to add the singleton='false' attribute to all my bundle IUs and it works fine. But I'd like to know if there is a way using a p2.inf file ?
Thanks for any lead.
The standard publishers that come with p2 cater for the standard Eclipse installation use case. The aim is to create an installation that will run, and fail the installation if it would fail at runtime. Therefore, I'd be surprised to see support for your use case in the standard p2 publishers.
Note however that you are free to write your own publishers. p2 (i.e. the entire project, not just the p2 publishers) aims to support all kinds of different installation scenarios and not only OSGi/Eclipse installations.
Greetings,
I have a java project which I export as a jar. This java project also uses JNI.
So far, the only method I could find to use this jar in an Eclipse plugin is to wrap it in an other eclipse plugin project, and add this jar wrapper plugin to dependencies of my actual plugin.
I've wrestled with Eclipse's paths and dependency settings for days, and this method is the only one that works for me at the moment.
However, it is not very practical, since when I change my JNI based java code, I can simply create a new jar, but to connect that jar to my actual plugin, I have to re-create the jar wrapper plugin every time.
That is, I delete the jar wrapper plugin project, with everything on the disk, and re create it with the same name, pointing to the updated jar. I also have to drop the reference to this project from the actual plugin project and add again (maybe this has gotten smarter recently, but I did not test it)
This is time consuming, and I can't add this wrapper plugin project to svn either, since it is being created from scratch every time.
If I could simply update a jar wrapping eclipse plugin project by pointing at the new version of jar, that would solve my problem, and I could commit the project to svn after each update.
Is there any method you can think of which may help me run this process smoothly?
Best Regards
Seref
An Equinox-only (i.e. non-standard OSGi) method of using external libraries in an OSGi bundle without physically wrapping them is bundling by reference: you still need a wrapper plugin, but it does not contain the wrapped library itself but a reference in the bundle manifest's Bundle-Classpath header with a syntax like this:
Bundle-Classpath: external:/path/to/your/lib.jar
During development time, this is quite convenient and saves the effort of having to recreate the wrapper plugin whenever the wrapped library is updated. During deployment time, you'll either have to install the library along with the product or use a traditional wrapper plugin (one containing the actual library). You can also use the same wrapper plugin for bith use cases, but change the Bundle-Classpath from external:/stuff/lib.jar to libs/lib.jar dependent on whether you want to use the wrapped or the external library.
(Most of this comes from the book OSGi and Equinox - Creating Highly Modular Java Systems, which I don't really like, but which nevertheless contains useful stuff about Equinox (Eclipse's OSGi implementation) and the PDE build system.)
I have a serious probleam with my Eclipse Plugin..
My plugin depends on another two plugins. All of theese plugins (including my plugin) use Mozilla Rhino engine - two of them use js.jar (version 1.4). But my plugin uses new version, which is not released yet and is packed in MyRhino.jar.
While developing, everything goes fine - code completion offers me classes and methods from my special version of rhino, no errors etc.
But when I run my plugin, a different version of Rhino is used and I get runtime exceptions like ClassNotFoundException and so on.
How am I supposed to tell eclipse to use the same jar in runtime as in development time?
When I was developing plugins on NetBeans, the solution was simple - wrapping the jar in a separate module, set which packages to export and declare dependency on this new module..
I found simmilar solution in Eclipse, however it did not work for me - although I declared a dependency on the wrapper plugin, the packages and classes were not available even in development time.
I've spent hours with this probleam and not solved it, so and help is appreciated. Thanks everyone.
Make sure your dependencies are correct. If your code depends on new version of library, then you need to indicate that in your MANIFEST.MF. E.g. if you require bundle org.mozilla.rhino, specify minimum version you need:
Require-Bundle: org.mozilla.rhino;bundle-version="1.5.0"
Your MyRhino.jar will need to specify correct version (e.g. 1.5.0), even though it is not released yet:
Bundle-Version: 1.5.0.qualifier
(If MyRhino.jar isn't converted to plugin yet, you need to do that manually: you can simply craete new plugin project using existing JAR in Eclipse)
Alternativaly, you can wrap MyRhino.jar into your plugin, and remove dependencies on other plugins. To do this, use Bundle-ClassPath (see http://www.aqute.biz/Blog/2007-02-19 for details). If you put your MyRhino.jar directly into your plugin, then Bundle-ClassPath should be:
Bundle-ClassPath: .,MyRhino.jar
Finally I've solved it..
It's simple to create the wrapper plugin form existing jar by the new project wizard in eclipse.. But the catch is that the wizard does not include the jar in bundle classpath (as I expected). Prety confusing (at least for me) that the wizard does only half of the job for you :/
After inserting the jar in the wrapper plugin bundle classpath, everytning works.
Thanks Peter for your answear anyway :)