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.