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.)
Related
I'm creating a Java project which includes a few libraries written by myself. However these libraries are not finished and sometimes require some edits. Because I'm working by myself, I find this more efficient than finishing all libraries perfectly before using them in my project.
My question is: is it possible to automatically rebuild a modified library when building the project which uses it?
Subquestion: what is the optimal configuration for my purposes? Should I export libraries as jar and copy them into the final project or should I configure buildpaths of my project to retrieve them in their respective folders?
Subsubquestion: is it correct to use .jar libraries in the same way that one uses dynamic libraries in c++?
If you have Eclipse set to "build automatically", it'll take care of rebuilding the library projects whenever you make changes, as you go along. You should set your client program to depend on either the Eclipse projects (if doing everything inside Eclipse) or the Maven artifacts (if using m2e). I strongly prefer using Maven for all my Java builds, but it might be overkill for something small. Whatever you do, don't manually export and reimport the libraries.
All libraries in Java are dynamic, and a C++ .so or .dll is the basic equivalent.
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.
I'm a bit confused with NetBeans (versions 6.5 and 6.7). I have a NetBeans Module Suite application, which consists of several NetBeans Modules. I need to add some code in one of the modules. The new code is using a library, distributed as several jar files.
The problem is, that NetBeans does not allow me to add this library jars directly to the classpath. It wants to wrap all the jars in a new Library Wrapper Module, which is then added to the project and used from there. The effect is that all the original jars are combined into a single new jar automatically by NetBeans. This is a problem, because I can't just replace the jars later, without rebuilding this "Library Wrapper Module" and the original library is updated nightly.
I read some NetBeans forums, but I found nothing... I tried with simple java application, where it is possible to simply add jar(s) to the classpath using Project Properties -> Libraries -> Add JAR/Folder. If you use a NetBeans module instead of a simple application, the Libraries dialog looks different and does not have the "Add JAR/Folder" button.
Is it possible to add a plain normal jar in a NetBeans module and how?
It looks like the way a user can wrap a jar has changed in NetBeans 6.8.
Since this has been integrated into a property dialog of a project, the build process might be smarter, too. And it seems like that was your primary concern....
example:
For logging, my code uses log4j. but other jars my code is dependent upon, uses slf4j instead. So both jars must be in the build path. Unfortunately, its possible for my code to directly use (depend on) slf4j now, either by context-assist, or some other developers changes. I would like any use of slf4j to show up as an error, but my application (and tests) will still need it in the classpath when running.
explanation:
I'd like to find out if this is possible in eclipse. This scenario happens often for me. I'll have a large project, that uses alot of 3rd party libraries. And of course those 3rd party jars have their own dependencies as well. So I have to include all dependencies in the classpath ("build path" in eclipse) for the application and its tests to compile and run (from within eclipse).
But I don't want my code to use all of those jars, just the few direct dependencies I've decided upon myself. So if my code accidentally uses a dependency of a dependency, I want it to show up as a compilation error. Ideally, as class not found, but any error would do.
I know I can manually configure the classpath when running outside of eclipse, and even within eclipse I can modify the classpath for a specific class I'm running (in the run configurations), but thats not manageable if you run alot of individual test cases, or have alot of main() classes.
It sounds like your project has enough dependency relationships that you might consider structuring it with OSGi bundles (plug-ins). Each bundle gets its own classloader and gets to specify what bundles (and optionally what version ranges, etc.) it depends on, what packages it exports, whether it re-exports stuff from its dependencies, etc.
Eclipse itself is structured out of Eclipse plug-ins and fragments, which are just OSGi bundles with an optional tiny bit of additional Eclipse wiring (plugin.xml, which is used to declare Eclipse "extension points" and "extensions") attached. Eclipse thus has fairly good tooling for creating and managing bundles built-in (via the Plug-in Development Environment). Much of what you find out there may lead you to conflate "OSGi bundle" with "plug-in that extends the Eclipse IDE", but the two concepts are quite separable.
The Eclipse tooling does distinguish rather clearly (and sometimes annoyingly, but in the "helpful medicine" way) between the bundles in your build environment vs. the bundles that a particular run configuration includes.
After a few years of living in OSGi land, the default Java "flat classpath" feels weird and even kind of broken to me, largely because (as you've experienced) it throws all JARs into one giant arena and hopes they can sort of work things out. The OSGi environment gives me a lot more control over dependency relationships, and as a "side effect" also naturally demands clarification of those relationships. Between these clear declarations and the tooling's enforcement of them, the project's structure is more obvious to everyone on the team.
if my code accidentally uses a dependency of a dependency, I want it to show up as a compilation error. Ideally, as class not found, but any error would do.
Put your code in one plug-in, your direct dependencies in other plug-ins, their dependencies in other plug-ins, etc. and declare each plug-in's dependencies. Eclipse will immediately do exactly what you want. You won't be offered dependencies' dependencies' contents in autocompletes; you'll get red squiggles and build errors; etc.
Why not use access rules to keep your code clean?
It looks like it would better be managed with maven, integrated in eclipse with m2eclipse.
That way, you can only execute part of the maven build lifecycle, and you can manage separate set of dependencies per build steps.
In my experience it helps to be more resrictive, I made the team filling out (paper) forms why this jar is needed and what license...
and they did rather type in a few lines of code instead of drag along 20 jars to open a file using only one line of code, or another fancy 'feature'.
Using maven could help for a while, but when you first spot jars having names like nightly-build or snapshot, you will know you're in jar-hell.
conclusion: Choose dependencies well
Would using the slf4j-over-log4j jar be useful? That allows using slf4j with actual logging going to log4j.
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 :)