I have an Eclipse-based OSGi application consisting of bundles organised in features. I use a product definition to launch the application. In this definition, I can also set start-levels for my bundles.
Now imagine I want to add a feature to the running application. Is a p2.inf file the only way to specify start levels for the bundles in this feature? Re-defining and re-starting the product does not sound like an optimal solution as it's not really dynamic.
I am not aware of any real tooling support for setting start levels for bundles on the feature level. The only option you have is manual hacking with a p2.inf.
I think the reason that setting start levels is only really supported for products is that p2 can't handle the case where start levels are specified multiple times. This could easily happen if setting start levels on feature level was encouraged.
So, you can make this work on feature level, but only if you know what you do.
I have the same problem I believe: I have a feature that is both part of a packaged product and present on an update site to be installed into an Eclipse IDE. And I also want to set the start-level for some of the plug-ins to ensure a very early start-up.
I have overcome this with a p2.inf file with the following content:
instructions.configure=setStartLevel(startLevel:1);markStarted(started: true);
instructions.unconfigure=setStartLevel(startLevel:-1);markStarted(started: false);
(I don't think I need to specify the start-level in the product definition anymore though I have not tried to remove this yet.)
I originally used start-level 2, but at least for Juno packages, there are some plug-ins that are started at level 1 so I now use level 1 as well.
Related
I am developing netbeans platform application that includes Netbeans and OSGi modules also. I need to assign starting level for OSGi modules.
I could not find any solution to this in Netbeans platform. I have found things like ; OpenIDE-Module-Requires, felix.startlevel.bundle MODULE_START_LEVEL. But either they are not working or i could not find any sample to apply.
In Eclipse, it was easy to assign start level for osgi bundles via run configuration. But there is nothing something like that in Netbeans.
Is there any solution for it ?
Relying on start order in OSGi is a red herring since dependencies can come and go. A lot of people think the startlevel service serves this purpose but it does not. The purpose of the startlevel service is for special features like a splash screen or provide an optimization; sometimes you can prevent extra work if you start in a certain order.
What you seem to want to do is take a shortcut. Instead of proper handling of your dependencies (which is quite easy with Declarative Services DS) you as a developer decides that if A, B, and C are running you can start C. Though this works initially it fails when you update A, B, or C since at that moment C is still assuming its dependencies are alive.
In general trying to control start order is a disaster in the long run. It is a lot easier to just use DS and manage the dependencies. Then your code will work in all circumstances.
You cannot assign the order in which installed bundles are resolved. A resolved bundle can have a class loader and classes can then be loaded from it. You can have some control over that start order of bundles by using the startlevel package.
I know I can set start levels and auto-start flags for bundles in Eclipse using a p2.inf file or using a product definition file. Doing it in the product file gives me tooling support and puts the settings into my launch configuration. On the other hand, using the p2.inf file allows me to manage start levels on a per-feature basis which give me a nice grouping of start-level settings.
Now my questions:
What's the preferred way of defining start-levels and auto-start flags?
p2.inf seems a bit outdated but is there a way to define start-levels and auto-start flags on a per-feature basis without using p2.inf?
It really comes down to a personal preference. The product level is the ultimate final artifact most of the time. As you discovered, it has much better tooling integration. When the product is assembled by Tycho or PDE Build you'll know exactly what's in it and what needs to be started for it in order to work properly.
However, sometimes it doesn't feel right to go down to the bundle granularity level in product definitions especially when it's composed of features only. But defining start properties at the feature level or even at the bundle level can be tricky, though. For example, when someone consumes your features/bundles in another product they might have different auto-start/start-level requirements.
FWIW, the p2.inf file isn't outdated at all. It's the raw bare metal to modify/optimize/instruct p2. It's just that there isn't really good tooling for it and there probably never will be.
This is a relatively open ended question so I wouldn't just mind being pointed in the right direction.
I have a product that uses the Eclipse workbench to allow users to program in a custom language. For this product, I will also have some minor UI and internal changes for a lighter version to be exported. For example, a full version of the product contains some extra views and menus, and behaves slightly differently (like when creating a new file) where as the ligher version does not contain a lot of view and has a couple of different more simplified ones.
I do not want to make a copy of my workspace and then have 2 separate workspaces for a full version and a lighter version as that will be difficult to maintain in the long run especially when there are changes in code relevant to both. I want to be able to export both, full and light versions of a product from a common workspace.
How can I go about this? Or where can I start looking?
The product is a collection of features and uses the Eclipse workbench as its base application.
I would like to clarify that I am asking how I could hide a view for the full or light version, as an example. I know in C#, we have options like #if. I have seen a lot of questions which refer to having 2 different versions of the same code, but nothing about how they could have 2 different versions of the same code.
You want the Eclipse RCP book it really fully explains how to do this. And to do it you need a solid understanding of the concepts of Eclipse plugin, feature, product, fragment and a few other things.
Essentially you can segment your application in to multiple plugins (have a base plugin for example, and then another that provides additional functionality). Then you organize those plugins into features that are the collection of the functionality to be installed. The notion of a "product" in Eclipse has to do with the branding, so you would probably have two products, a lite and a full one. The products could have a branding plugin (where the product is actually declared).
This should get you started.
I want to use the "Web Tools Editor" that is part of the Web Tools Plattform in my own RCP-Application. I think i have got some understanding on the RCP plattform by now, but I still have no clue how to access the functionality of the pagedesigner (org.eclipse.jst.pagedesigner) after adding it as a dependency to my project. Has anyone some experience in adding components of the web tools plattform into an RCP-Application and can give me a hint or something?
There's a difficulty with these sorts of requests (I am, myself, trying to include this or that feature that I saw in the Eclipse IDE, every so often).
The trick is to try and identify the component you want to bring in, and then try and pull it into your project, without bringing in too many dependencies.
The first step used to be quite hard, but since 3.4 it is a matter of using the Plug-In Spy - hold down Alt-Shift-F1 on whilst your desired component is in focus should give you a tooltip showing you the class, the bundle, etc etc.
The second step is altogether more tricky and is where I usuaully fail to get any results:
if you are lucky then you can just include the bundle in the launch configuration/.product of your app. Once you hit Add Required Bundles, you are not left with 3000 bundles (i.e. your RCP is now Eclipse).
usually, this is not the case, because the Eclipse team haven't refactored the bit of code you're interested in out into an RCP safe bundle. If so, then you're going to have to do that yourself.
Again, if you are lucky then that will mean moving some classes out of the eclipse bundle into your own, including internal classes, and that will be the end of it - i.e. the dependencies of your desired functionality are all within the bundle.
If you're unlucky, then you need to isolate/reimplement the bit of functionality that is required, and change your version of the copied code.
It is hard laborious, and pretty difficult to upgrade. I realise that none of this is what you want to hear.
Simple usecase: assemble an Eclipse product using simple scripts, just dumping bundles into the plugins dir.
This used to work with 3.3 - with 3.5 it's broken: my application doesn't start as the app plugin is not found.
Question: what's the easiest way to fix that? This seems to be the only pain in the whole upgrade process for me.
Attempts:
I guess this is a no-no for P2: it maintains the bundles.info file instead, which is probably very smart.. a bit too smart for me.
Some ideas I had:
can I just skip P2 altogether and get back to plain old, simple -dirty- discovery mechanism?
can I set up plugins dir as a 'watched directory'
looks like I need to use the p2.reconciler for that.. oh wait, it's deprecated already :-( bug 251561.. (thanks VonC for the pointer)
can this old setting in the config.ini still work? (which is now replaced with the 'simpleconfigurator') osgi.bundles=org.eclipse.equinox.common#2:start, org.eclipse.update.configurator#3:start, org.eclipse.core.runtime#start
should I call the (p2) director?
"please pick my plugins up" :)
I'd avoid the dropin folder for this - that's more for the
end-users.
I'd avoid messing with the bundles.info if possible.
I don't care about all those smart features in my product yet- actually the users don't use the built-in update mechanism at all.
So I'd like to KISS (ie: just to start up), and add more advanced support when needed.
I've asked this on Eclipse forums, but no answer yet, so would really be grateful for some enlightenment.
Also, feel free to correct me on the assumptions - I've just read the P2 docs, which seem confusing at times.
Thanks!
Answer: actually option 3 above seems to work after all - thanks Francis for confirming this! (it didn't work originally, but that was probably caused by some missing deps).
My only issue with that now is, some Eclipse bundles actually require simpleconfigurator. So I wonder if swapping it out will cause problems down the line.
You can alter your configuration/config.ini file to not use the org.eclipse.equinox.simpleconfigurator (which does the p2-based configuration) and instead use the org.eclipse.update.configurator which is the old-school way of just configuring whatever is in the plugins directory. This should give you what you want.
Even if it does not fully answer what you are after, you can specify in an eclipse.ini (like the one I describe here):
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=C:/jv/eclipse/mydropins
That does specify to p2 to monitor any directory of your choosing to detect plugins in it.
Another source of idea could be this article: Composing and updating custom Eclipse distros
It's not hard to create a feature based product that includes these things, and do a product build to end up with something like this:
Note: the concept of reconciliation is detailed in the eclipse Wiki.
For certain installations of Eclipse, there will exist the notion of a shared installation -- this may be in the case of a Linux system where a base set of software is installed via packages (perhaps RPMs), or may be in a Maya deployment where shared profiles are defined in a central server.
In both cases, it is necessary to perform reconciliation between the shared profile and the user's current instantiation of the profile including any modifications they may have made.
Part of this mechanism is the Dropins Reconciler setting. Although, as bug 251561 illustrates, it is not advised to put too many plugins in there.
Maybe this will help you (shot in the dark)? I found this when upgrading my Eclipse installation to Galileo and trying to keep my Flex Plugin install.