Community
Participate
Working Groups
Hi, I am trying to deploy a couple of OSGI bundles into the Orion server. Placing the bundles into the plugins folder does not help since the Orion application only loads the bundles defined in the eclipse\configuration\org.eclipse.equinox.simpleconfigurator\bundles.info file. I have created a dropins folder within the eclipse directory and added the line -Dorg.eclipse.equinox.p2.reconciler.dropins.directory=/path_to_dropins to the orion.ini file. But the bundles in the dropins folder are just ignored. I don't want to manually install my plugins. For the time being, I have modified the bundles.info file to include my bundles as well. But is this an acceptable approach? Thanks and Regards, Pradyut.
The same story with language packs. We have to modify bundles.info to add them. We should address it in .5.
(In reply to comment #1) > The same story with language packs. We have to modify bundles.info to add them. > We should address it in .5. I just got off from ST with Kit Lo (from globalization), he said that we should have a simpler scenario for installing language packs. I have to say that at first we'll be translated to 14 languages, having 4 bundles each, gives 56 bundles to be added to bundle.info, if administrator wants to add all of them.
I talked to Simon about dropins folder and p2 support. It seems that for Orion a better way would be a mechanism that configures Orion packs on download time. It could work like this: - the user opens the download page - sets what he wants in the Orion pack (ssl, supported OpenID providers etc.) - the download site prepares the pack for him - the user downloads it and does not have to configure anything else It would be like our Eclipse SDK download site where we already have packs for EE, Java Dev or C Dev. The idea for Orion is to make this mechanism more dynamic. So if the user chooses to have Polish support, this mechanism would prepare and publish an Orion pack with Polish language packs and bundles.info updated.
We changed the installation of language pack plugins to client-site. In this case "dropins" folder is no longer critical for the globalization. It is however still needed for the other mentioned use cases.
I'm incredibly reluctant to support dropins in a server environment for the out of the box Orion server however a custom implementation is free to do what it likes.