Community
Participate
Working Groups
[See related bugs: bug 58040, bug 59422, bug 60306, bug 62316, bug 64290, bug 65722] RCP developers are confused by the configurator not being included in the base RCP so I believe it should be included. The arguments that I've seen so far against including it and my counter-arguments are below. Argument 1: You can have an RCP application without a configurator (by listing all the plug-ins manually), and the RCP package is supposed to be the bare minimum. Answer: Listing plug-ins manually is a tedious and error-prone process, and it breaks the powerful and intuitive idea of being able to add a plug-in or set of plug-ins to an existing application and have Eclipse discover the addition. Argument 2: An RCP application may want to provide their own configurator. Answer: They might but it's unlikely. The regular Eclipse one is fine for 99% of the cases. Argument 3: It would add to the download size. Answer: Ok, but we're only talking about 100K or less in a 5M download. Argument 4: You can get around the PDE Self-hosting launch error about the missing configurator by making a change to the target workspace options. Answer: Yes but that's completely non-obvious. I didn't know about it until I found a bug report where the method was explained. I think the pros and cons come down to a purist view vs. a practical one. It's true that the update configurator was not originally intended to be part of the base RCP and strictly speaking it is optional. But it's so darned useful that we should recommend every RCP application include it and make that the easiest and best supported use case. Besides if it is not included, as you can see already you're asking for a steady stream of questions about why plug-ins don't work they way people are used to in the full Eclipse.
Jeff, can you comment? The lack of update.configurator in the RCP build, combined with the lack of a PDE wizard for generating the app, does really complicate things for RCP developers trying to get off the ground.
To consider providing a default configurator in Runtime, not tied to Update component.
Nick, the current update configurator works without the rest of the update code and it is about 80K. For an even simpler configurator, that doesn't know about features and such, the configurator would be much simpler (and smaller as well).
That's the intent here. update.configurator does work currently for the common cases, even if the app is not using the update manager. But we'd like to have support for plugin discovery (for at least the single plug-in directory case) in the runtime itself.
Dorian, can you assess the work required to carve out (copy) and simplify the configurator code to provide the simplified function? We can include that somewhere down low if it is reasonably small. Otherwise we might just go and include update.configurator in the RCP SDK.
The work should befairly straightforward, (way) less than a week. I assume this configurator will not be shipped along with the update configurator. If both configurators were to coexists (say, someone picks the RCP package, adds the update plugins, etc.), then I would think the problem is a bit harder.
Even if they were to coexists, only one would have to be specified on the osgi.bundles list.
Regarding comment #7, I thought the whole purpose here was to not have to specify osgi.bundles. If I have to specify osgi.bundles then I don't need platform.xml nor the links directory.
Pascal, if both configurators exists, they will likely both be running, as the first configurator will install the second one. At this point, at least in theory, the second configurator may perform actions (bundle install/uninstall) that may conflict with the first configurator.
Correct, I forgot the discovery part... but who would start the second one anyway. And in the worst case, if the second one was starting it would detect that the plugins it is trying to install are already installed and do nothing. Is it not somehow the same model than running with update configurator and a list of bundles in the osgi.bundles list. Jim, I referred to the osgi.bundles list to indicate the installer to run (like it is done today).
Sorry. I think I got my bugs mixed up. I thought this comment was on a different one.
one thought here is that the configurator I am talking about would in effect be an enhanced version of the current osgi.bundles support. It would simply discover and install all the plugins it could find. Think of it as osgi.bundles=@auto or some such. It would be mutually exclusive with the other configurators. I'm not saying it has to be but this would be a simplifying assumption that seems reasonable.
We need to make a decision here for M7. Seems like the real question is "should update.configurator be included in the RCP base?" Pros: - gives users auto install function and so simplifies their lives (no more osgi.bundles list hacking) - avoids users having to go and find the plugin should they want it (this assumes that alot/most RCP developers want it) - users get the link dir function - reuse existing function rather than reimplementing Cons: - bigger (86K jar) Note that if we wrote our own simple configurator we'd use some of that space anyway - muddies the water a little as developers see "update" and think they have the update function. Also adds Features to the base. Can be confusing for people using other grouping technology. Questions: - would we add it back on the osgi.bundles list for the RCP drops? - how does this conflict in any way with JNLP support? (I believe not as we ran this but its worth confimation) Not to bias anything but my vote is +1 for adding update.configurator. It works, its not that big and there seems to be no compelling reason for us to to more work to get equivalent function.
I would also add: Cons: - may add extra complexity in the lookup mechanism, which makes it harder to debug Pros: - as the interaction between osgi and higher level eclipse evolves, it avoids dual maintenance of two plugins - easier to drop the update function on top later, without having conflicting configurators I would also give it a +1. A secondary reason I'd give it this vote is that a wider use of the configurator can iron out various issues and helps it become more robust, and hopefully, nimble.
I certainly depend upon it for my RCP installs. I use the feature install capability (using platform.xml) so that my apps are separated from the base RCP plugins. +1
let's make it so.
Moving to platform / releng. Please add org.eclipse.update.configurator to the rcp feature so that it is available in all rcp binary and rcp sdk downloads.
It's been added.
note that if the platform features are nested on top of the RCP feature then you should consider removing the update.configurator from them.
We'll keep this in mind if the decision is made to nest them in the future :-)
