| Webstart and RCP Eclipse 3.1 [message #437349] |
Tue, 27 September 2005 20:40  |
Eclipse User |
|
|
|
I have looked at Ed's demo, read all of Pascal's comments, looked at the latest eclipse help page, and searched the "whole Internet", but I have not been able to deploy RCP using webstart in 3.1
Was anyone able to do this?
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Webstart and RCP Eclipse 3.1 [message #437683 is a reply to message #437682] |
Sat, 01 October 2005 17:58  |
| Eclipse User |
|
|
|
The rationale is that if you are developing a plugin that depends on (say) Xerces, and another plugin also depends on Xerces, then you only have one copy of Xerces loaded (onto disk/memory). If you bundle it inside your plugin, you load it twice, and increase disk/memory usage (the latter being more important).
Furthermore, if it's developed as a separate plugin, then if you want to ship a bugfix version (say, Xerces 2.7.1) then you don't have to re-bundle your plugin to take advantage of the new parser (and once installed, any other plugin that needs Xerces can also take advantage of it).
Lastly, this approach also allows 'deltas' to be shipped as fragments, so that you can ship the changes in 2.7.1 that are different from 2.7.0 instead of the whole lot again.
This also holds for the reverse direction; if you want to ship a new version of your app, you only need to provide updates for your app, not any of its dependent libraries. That'll make people updating your app from (say) an update site much faster, because they won't need to download the required libraries again.
Lastly, it's not even the case that for a 'normal' size app that it needs to be a single plugin. You can split out your UI and non-UI components, for example, to allow uses of your plugins to be used by other systems (or running on a headless Eclipse install, for example).
|
|
|
| Re: Webstart and RCP Eclipse 3.1 [message #437698 is a reply to message #437683] |
Sun, 02 October 2005 18:35 |
| Eclipse User |
|
|
|
ok, so i knew this - but, i am examining my own behavior with respect to
eclipse - the mother of all rcp apps - and i always,always download the
whole thing - and i would never expect to see a separate, say junit,
plugin upgrade for eclipse. how about you - do you download
fragments/plugins or do you go for the whole tarball as well? would you
look for or download a junit upgrade only?
Alex Blewitt wrote:
> The rationale is that if you are developing a plugin that depends on (say) Xerces, and another plugin also depends on Xerces, then you only have one copy of Xerces loaded (onto disk/memory). If you bundle it inside your plugin, you load it twice, and increase disk/memory usage (the latter being more important).
>
> Furthermore, if it's developed as a separate plugin, then if you want to ship a bugfix version (say, Xerces 2.7.1) then you don't have to re-bundle your plugin to take advantage of the new parser (and once installed, any other plugin that needs Xerces can also take advantage of it).
>
> Lastly, this approach also allows 'deltas' to be shipped as fragments, so that you can ship the changes in 2.7.1 that are different from 2.7.0 instead of the whole lot again.
>
> This also holds for the reverse direction; if you want to ship a new version of your app, you only need to provide updates for your app, not any of its dependent libraries. That'll make people updating your app from (say) an update site much faster, because they won't need to download the required libraries again.
>
> Lastly, it's not even the case that for a 'normal' size app that it needs to be a single plugin. You can split out your UI and non-UI components, for example, to allow uses of your plugins to be used by other systems (or running on a headless Eclipse install, for example).
|
|
|
|
| Re: Webstart and RCP Eclipse 3.1 [message #437754 is a reply to message #437698] |
Tue, 04 October 2005 06:57 |
| Eclipse User |
|
|
|
It doesn't matter so much if your only distribution mechanism is a single tarball, from a distribution perspective. However, if you're going to provide an update mechanism (and I strongly urge you to consider doing this if not using WebStart) then it makes a lot more sense having multiple plugins, because then you ship just the updated code.
In fact, there's nothing to stop you bundling the app with just a bare-bones installer and updater, and then when the user runs it for the first time run the updater to pull down the latest version.
Given that there's no benefit in putting them in a single Jar, and there are multiple benefits (that admitedly, you may not be using yet) in having seperate Jars, (and the fact that it would be a bitch to switch between the two) it makes sense to start off using the one that will give you potential benefits in the future.
|
|
|
Powered by
FUDForum. Page generated in 0.06908 seconds
Home