I created an eclipse run configuration for a number of bundles. One of the bundles has a dependency to the following packages:
com.sun.mirror.apt,
com.sun.mirror.declaration,
com.sun.mirror.type,
com.sun.mirror.util
I believe these are part of the Sun Java JVM. When I add these packages as system packages to a Felix container, the bundle is loaded fine by that container.
However, I was unable so far to find out, how I can configure these packages as additional system packages for a run configuration in eclipse (I found how eclipse as a whole can be made aware by changing the config.ini).
EDIT: It seems that these classes are in the system library tools.jar. Or in my case, as I am using Mac OS X, they could be in classes.jar?
The OSGi specification defines a property called "org.osgi.framework.system.packages.extra" (explained in paragraph 4.2.2 that deals with launching properties) that allows you to specify extra packages that should be exported by the framework. Add your packages to that property in your run configuration and it should work.
Related
I am developing a eclipse plugin which uses 3 native libraries, lets call them lib1.so, lib2.so and lib3.so. Dependency among these libraries goes like this lib1.so --> lib2.so --> lib3.so.
I can load lib1.so library using System.loadLibrary() API, but I am getting unsatisfied linker error for lib2.so and lib3.so. I resolved this issue by setting LD_LIBRARY_PATH environment variable to path where I kept all these 3 libraries.
I am not happy with this fix as I have to set LD_LIBRARY_PATH every time when I am importing these plugin projects in other machines :(
Is there any other way such that lib1.so can load lib2.so and lib2.so can lib3.so automatically. And these libraries always be kept together in single folder.
In Dependencies tab, I have a choice between plug-ins and packages.
What's the difference between them? For org.eclipse.compare, I have it in imported package and also in plug-ins.
I find the jar file in plugins directory, but I don't know where the package file of org.eclipse.compare is located.
In the export menu, it seems like that there seems to be only exporting to jar, not exporting a plugin or packages. How can I export packages?
ADDED
Based on this post - How to import a package from Eclipse? and shiplu's answer. This is what I came to understand. Please correct me if I'm wrong.
In eclipse, when I use come external class, I can use Quick-Assistant or Organize imports (Ctrl-Shift-O) to resolve the reference. Eclipse adds the package that contains the class in Imported Packages for the project that I'm working on. A package can contain multiple classes (types). Eclipse understands what plugin contains the package, and resolve the reference issues.
A plug-in (jar file) can contain multiple packages. By specifying a required plug-ins in the dependencies tab, we can reference all the packages (and classes in the packages) for all the java projects in the eclipse IDE.
And from my experience, I had to add all the dependencies in order to make headless RCP standalone (http://prosseek.blogspot.com/2012/12/headless-rcp-standalone.html).
An Eclipse plug-in is basically an OSGi bundle with additional plugin.xml file which Eclipse IDE understands and interprets.
So the answer to your question lies in the OSGi specification and the OSGi programming model, since, very simply put, Eclipse is an Application running on implementation of OSGi called Equinox.
OSGi is all about having modular applications and so it defines several levels of modularity.
One such level is a bundle-level (module-level) modularity and more fine grained level is the package level modularity.
So you can have your OSGi application (a set of bundles; eclipse is just that) which consists of db-bundle (which provides data store services), app-domain-bundle (which provides your application domain services) and remote-bundle (which exposes to the web your application via REST for example).
And then you say remote-bundle depends on domain-bundle which depends on db-bundle.
Which is all good, but cripples the inherent modularity OSGi provides, because you are basically restricting your application to specific implementations of db-bundle and remote-bundle i.e. to specific implementations of the services they provide.
Instead, you can establish the above dependencies not between bundles but between packages i.e. establish a service-level dependencies.
Then you say domain-bundle requires dbstore.service package to run, it doesn't care which bundle provides it it just needs an instance of this service to be able to work. So you can have multiple bundles providing implementations of the dbstore.service, and the domain-bundle can pick and choose at runtime what service to use.
It is really hard to explain OSGi concepts in just a several sentences, I'd really suggest you dig around the web on this and maybe even have a look at the OSGi specification.
Another way to explain it is to say that bundle/plug-in is a jar file with specific structure and metadata descriptors (MANIFEST.MF and plugin.xml), which describe its contents in Java language concepts - which java packages and services this specific jar contains and will expose to the OSGi runtime so that they can be consumed by other bundles. I.e. the bundle is the physical deployable entity while the descriptors are metadata about what actually is being deployed.
EDIT:
Package or Service-level dependencies also have some drawbacks, as Lii points out in the comments below, the main one being that it adds complexity and dynamics to the dependency model. Have a look at her or his comment below - it is worth reading!
You use Imported Packages when you want to use a specific package but do not care which plugin provides it. OSGI will choose one for you.
Eclipse plugins is something like extension to the IDE itself. But imported packages are actually packages that you'll use in your current project.
One is for development IDE another is for the project you are coding.
There are a few options for developing modules for Netbeans 7.0.1 RCP. I haven't found any clear comparison of them.
So I would like to know which of them is the easiest to:
develop
install by user (e.g. user could choose proper jar with module
from a repository )
Which makes to write less non-reusable code (e.g. when you want to make web application of used classes later)?
Which is the most popular?
The easiest way is to use the traditional Netbeans way - build nbm's. This is well tested and good feature. After building module you will get the "nbm" file with all needed info inside (additional jars, settings, etc.)
You can use "Module Update" features from Netbeans.
The other way is to build modules as osgi bundles.
This feature was introduced in 6.7 version and up to now it has some problems.
First of all, bundle in normal understanding is one jar. If your bundle depends on other jar (f.e. apache-commons:beanutils), you will need to pack this jar into your bundle jar (using maven-bundle-plugin) or to install "beanutils" as independent bundle. The first solution is not the best, because if in the future another bundle wants to use "beanutils" you will need to link new bundle with old one, even if they don't need this. This cause high cohesion between modules. Or you can pack "beanutils" into your new bundle, but this can cause classloading issues in osgi-framework.
So, if you need to install netbeans module, you just install one nbm file and that's all.
If you need to install bundle, you need to install all dependent bundles separately beside yours bundle.
Another things are, for now you can't configure osgi-framework, which embedded in netbeans and process of loading bundles has some differences from loading standard netbeans modules which can cause some "strange" issues.
I'm sure that guys from netbeans will fix this issues and they are moving in right direction, but for now, if you don't need bundles, don't use it.
One of our plugins requires an installed JDK, not just an JRE. We need com.sun.javadoc and friends from tools.jar. I do not think Sun's license will allow redistributing tools.jar (which is not necessary if you already have a JDK anyway).
It also seems there is no way in Eclipse to specify a JDK as a dependency. All answers in the Eclipse newsgroups suggest that end users will have to configure their Eclipse properly first.
Do you know any workaround that will make this dependency obvious to users of our plugin, just by using Eclipse's on-board mechanisms for dependencies? It seems this package is not even valid for Import-Package in the manifest, unlike e.g. com.sun.jdi.
(As a work-around, currently we can only warn on plugin activation that this library is missing.)
Since eclipse offers an OSGi environment, you could refer to the article "Exposing the boot classpath in OSGi", and try using:
a System Packages declaration
a Extension Bundles (Fragment) declaration
or boot delegation
By specifying the JDK packages you need, the OSGI framework will attempt to load them (and fail if there are not here).
By specifying one specific to JDK5 or JDK6, you could even ensure the right version of the JDK.
The OSGi spec allows the Framework (through its system bundle) to export any relevant packages from its parent class loader as system packages using the org.osgi.framework.system.packages property.
As repacking the hosting JDK as a bundle isn't a viable option, one can use this setting to have the system bundle (or the bundle with id 0) export these packages itself.
Most of the OSGi implementations already use this property to export all the public JDK packages (based on the detected JDK version). Below is a snippet from an Equinox configuration file for Java 1.6:
org.osgi.framework.system.packages = \
javax.accessibility,\
javax.activity,\
javax.crypto,\
javax.crypto.interfaces,\
…
org.xml.sax.helpers
Using this property, one can add extra packages that will be loaded and provided by the framework and that can be wired to other bundles.
org.osgi.framework.system.packages = \
javax.accessibility,\
javax.activity,\
…
org.xml.sax.helpers, \
special.parent.package
Note: the simpler solution of specifying Bundle-RequiredExecutionEnvironment is only for the JRE, not the JDK...
That kind of configuration need to be part of the config.ini of the Equinox framework (see this example for Jetty and its config.ini).
In your case, it would be declared in the config.ini of your fragment.
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 :)