Netbeans RCP module options. Felix, equinox or standard Netbenas module? - netbeans

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.

Related

How do I "install" a log4j bundle?

I've downloaded the code for an Eclipse plugin. The code uses log4j, but it doesn't just use it as a library (referred jar), but as a "bundle". So it doesn't compile because of the following reason:
Bundle 'org.apache.log4j' cannot be resolved
I'm not really sure what's the correct approach to solve this. I know how to add jars to a project, but how do I add "bundles"? Is it something I need to add to the entire Eclipse host?
I "solved" this by creating a new plugin project with no code but with the log4j jar included... but that doesn't feel like the right solution.
I've also found some places where "log4j bundles" are published, e.g.:
http://ebr.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.log4j&version=1.2.16
http://download.eclipse.org/tools/orbit/downloads/drops/R20110523182458/
But I'm not sure if that's what I need, if it matters where I get it from, and how to "install" it.
I assume you are using the Eclipse Plugin Development Environment (PDE). In this case, the log4j bundle needs to be imported into the "Target Platform".
The Target Platform is like a repository of bundles (i.e. plug-ins) that replaces the "classpath" in traditional Java development. You can find the location of the target platform and modify it by going to Preferences -> Plug-in Development -> Target Platform.
HOWEVER before doing this I strongly recommend you take some time to learn a bit about what you are working on! If you want to develop an Eclipse Plug-in you should at least learn what a plug-in is, and how its dependencies work. If you read a bit about the subject you should not have to ask such an extremely basic question on Stack Overflow... it is covered in all the introductory tutorials and FAQs.

Installing Java libraries

As I'm quite new to Java, I would like to know the proper procedure of installing new libraries (those that are no available in my linux dist repositories).
Where should I place them? and how to install them?
For instance, I downloaded openCsv (http://opencsv.sourceforge.net/), and I have no idea how to install it.
Java libraries don't really need to be 'installed' like other applications. All you need to do is put the jar file in a specific location, and add the jar file to your classpath. How you do that depends on the linux distro you are using. If you are making a web application in eclipse, you can drop the .jar file in the WebRoot/web-inf/lib folder, and it will be bundled in with your project.
Be sure that the path, which you place the libaries at, is set in the $CLASSPATH Environment Variable.
For Eclipse: Project -> Properties -> Java Build Path -> Add JARs...
It's up to you really - I use /opt/javalib, but you might consider a directory in /usr/local as well.
You can store them wherever you wish. You can store them within the JRE distribution directories, but I wouldn't recommend that.
Instead I would store them per-project (so you can have different versions for each project easily - some libraries have different names for each version, some don't) and adopt a standard such as a lib/ directory. That way you can have standard build scripts (Ant etc.) that can operate in the same way (if you're using Maven, then there's a standard place per-project - src/main/resources)
You could use Maven to manage any dependencies to those libraries.
Maven will automatically download all needed JAR files and put them in a local repository (the location is configurable).
This makes upgrading to new versions of various libraries very easy as you just declare the version you want and Maven does the rest.
Beware: Maven is something to get used to and the initial learning curve is steep.
The rewards come if you have everything set up properly and maven takes care of compiling, packaging, distribution, site creation, release management etc. etc. etc.

Can I update an Eclipse plugin project, which is simply a wrapper around a jar?

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.)

How to simply add jar files, as libraries in a Netbeans module suite?

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....

Programatically installing an Eclipse plugin from within Eclipse?

I want to create an automated installer for an Eclipse plugin (i.e. not through the "Update Manager"). My scenario is simple: the user closes Eclipse, drops a downloaded JAR into the dropins folder, starts Eclipse and the rest of the process is automated.
In older Eclipse versions, before the era of P2, Eclipse had (still has) a class called InstallCommand which could be used to install pluings into the currently running platform.
While this still works in Eclipse 3.4 & 3.5, it is not behaving properly: most noticeably, plugins installed that way cannot be automatically uninstalled (it is dimmed).
The JavaDoc claims the InstallCommand is deprecated and should be replaced by a P2 alternative. However, I couldn't find the right tool for the job. There is the P2 director, but it is built for running as a separate application from the command line. It is possible to invoke it from within Eclipse but it is really not cut out for that. For example, progress monitoring and error reporting are not working well.
Does anybody know of a good alternative for that?
Thanks,
Zviki
Dropins seems very close to what you want, especially if they are just downloading jars without the associated metadata (ie the metadata will need to be auto-generated).
You could consider defining a second dropins area to manage yourself. Take a look at ProfileSynchronizer in org.eclipse.equinox.p2.reconciler.dropins, in particular the method createProfileChangeRequest. I expect the uninstall behaviour you don't like is a result of the IInstallableUnit.PROP_PROFILE_LOCKED_IU property being added.
The dropins are reconciled at startup, see the p2.reconciler.dropins Activator.watchDropins(), you can likely do the same from your own bundle to watch another folder.
I suggest to deploy your plugin as an executable JAR. The installer in the JAR should ask for the Eclipse install directory and unpack the plugin in the right place (plus some more checks as needed).
Optionally include a little "watchdog" plugin which doesn't depend on much and just checks that your main plugin loads correctly and displays a useful error message which the user can email to you for support.
According to information in bug 311590 1 which is referenced in the deprecation comment of InstallCommand an alternative is possibly to use P2 operations 2, 3.