Can Eclipse 3.5 discover all bundles in the plugins dir?

Question

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:

1. can I just skip P2 altogether and get back to plain old, simple -dirty- discovery mechanism?
2. 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)
3. 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
4. should I call the (p2) director? "please pick my plugins up" :)
5. I'd avoid the dropin folder for this - that's more for the end-users.
6. 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.

Cohn

Just added a few sources of information regarding the p2 dropins directory, n response to your comment. – Vietcong

Answer 1

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.

Sulphathiazole

I just came to the same conclusion - which seems to work finally. My earlier trials failed on this:I got spurious NCDFEs and mysterious crashes - which lead me to believe it's not possible to "go back to the old-school way". Now that I started over from scratch(probably clearing the actual root problem of some other missing bundles),things look much better:) Anyway, thank you for confirming this! I was about to add an answer for this..However, some eclipse bundles (e.g JDT) explicitly require the simpleconfigurator(which I find a bit strange).Do you think the old school way be OK with those? – Cohn

I don't know what you mean by a bundle requiring the simpleconfigurator. As far as I know that's a function of the environment (as specified in the config.ini), not something that can be specified by a bundle. Can you elaborate on what you mean here? – Sulphathiazole

Sure. There is bundle org.eclipse.equinox.simpleconfigurator_1.0.200.v20090831.jar and another one depends on it by Require-Bundle in the MANIFEST.MF: org.eclipse.jdt.junit_3.6.0.v20091026-1200.jar. – Cohn

Oh, I understand now. That's fine because the JDT JUnit stuff must be referencing something from simpleconfigurator which is not a problem because the bundle will still be there, but that's completely independent of the process used to do the initial configuration. – Sulphathiazole

Answer 2

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.

Vietcong

Cheers for that. So basically, that's the way to implement 'watched directories' (2nd alternative in my Q). I saw this option mentioned on various blogs,but wasn't clear if it does the right thing. Can you add multiple dirs there? Can you add the plugin dirs itself? Is this documented at all? Nothing in the help system, nor on the p2 wiki (which seems to have hundreds of pages, but very little is up-to-date or concrete beyond raving about how cool the system is.. in principle:-) Anyway I'll try it - thanks a million for your hints. – Cohn

Also, why using the -D vmarg, what not adding it into config.ini? According to the guideline, eclipse.ini is for general vm settings- everything else should go into configuration/config.ini. See the 'bottom line' help.eclipse.org/galileo/index.jsp?topic=/… – Cohn

@inger: good point, but I have always modified one config file: the eclipse.ini. It is always distributed with eclipse, and I avoid having to modify several files. – Vietcong

@Vonc, thanks for the extra additions to your reply, especially the link to that bug- which basically says dropins are already deprecated (bugs.eclipse.org/bugs/show_bug.cgi?id=251561#c18). Unbelievable.. – Cohn

@Vonc, also the link to that Andrew Niefer's blog is interesting, but isn't really relevant to the question, is it? Note that I don't care about updateability, at least not before I can just run my damn product (without rewriting my build system). – Cohn

Answer 3

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.

Kellsie

Thanks for that, but that's a different use case - it's useful for sharing plugin locations using links. I would not introduce such indirections in my product out of the box. – Cohn

Yeah, I'm not an Eclipse developer but I thought I'd take a shot at it. Good luck. – Kellsie