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.
Related
I'm wondering: What is the best way of adding a bundle to a p2 based target platform?
I don't want to use local directories, I want to have a target platform that works 'out of
the box' for all our team members.
Right now I manage, but I have a feeling I'm missing a more straightforward way of
doing this.
My situation is as follows:
My target platform has a bunch of p2 locations, hosted at our on-site server.
Most are mirrored repositories, but I have one I use for 'miscellaneous' bundles.
This is how I add a bundle to the target platform.
I switch to another workspace, which does use a bundle directory with jars.
I add the bundle jar to that directory.
I add the bundle to my 'third party' feature
I export the feature, and upload it to our server, deleting the old one
I switch back to my normal workspace, and reload the target platform link.
Sometimes eclipse gets a bit confused and keeps using a cached version, but in
general this approach works.
My question:
Is there a easier way?
Is there a more 'incremental' way? I rebuild the p2 repository, instead of adding
a feature with a new version.
You should have a look at p2's publisher and mirror tools. The publisher creates p2 metadata, and with the mirroring, you can copy artifacts into an existing p2 repository (given you have file system access).
There is also a Maven front-end to these tools provided by the Tycho project.
I'm using some 3rd party libraries to create my RCP application. These libraries are available as update site / p2 repository, and they are provided by eclipse (e.g., the RCP target, EMF) or by a third-party repository. Accordingly, I've created a target file to describe what I'm using to build my application.
Due to a recent outage of one of these repositories, I want to have a local mirror of all the stuff I'm using to build my application. Somebody told be to look at b3, but I need some additional help. Following the tutorial, I've copied from my target file the p2 repositories and created some validation rules (according to the feature I use).
However, when I start the build, it mirrors huge parts of the eclipse's indigo repository (including, for example, the JDT, WTP, and linuxTools, which are NOT required directly or indirectly by my RCP app).
Is it possible to limit the mirror to the features listed in my target file?
I have only the Helios version of b3 installed (not sure how it works in a newer one, but probably its similar), there I can add some child items to the Mapped repository elements to add an exclusion rule to remove some items, or add some specific features or plugins.
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 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.)
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.