Home » Eclipse Projects » Rich Client Platform (RCP) » Webstart and RCP Eclipse 3.1
|
Re: Webstart and RCP Eclipse 3.1 [message #437352 is a reply to message #437349] |
Wed, 28 September 2005 06:35 |
Eclipse User |
|
|
|
Originally posted by: stefan.renz.web.de
Ivan B wrote:
> 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?
Hi Ivan,
I have deployed my RCP-Application successfully. Following is the
resources section of my jnlp-file. If you packed your plugin as a
jar-file, it should work the same way.
<resources>
<!-- the demanded jdk version -->
<j2se version="1.4*" max-heap-size="256000000"/> <!-- 1.4.1+ -->
<!-- contains eclipse webstart launcher -->
<jar href="webstartup.jar" main="true"/>
<!-- the application plug-in -->
<jar href="MyApplicationPlugin_1.0.0.jar" />
<!-- following the plugins of the eclipse framework -->
<jar href="org.eclipse.core.commands_3.1.0.jar" />
<jar href="org.eclipse.core.expressions_3.1.0.jar" />
<jar href="org.eclipse.core.runtime_3.1.0.jar" />
<jar href="org.eclipse.help_3.1.0.jar" />
<jar href="org.eclipse.jface_3.1.0.jar" />
<jar href="org.eclipse.osgi_3.1.0.jar" />
<jar href="org.eclipse.swt.win32_3.1.0.jar" />
<jar href="org.eclipse.swt_3.1.0.jar" />
<jar href="org.eclipse.ui.workbench_3.1.0.jar" />
<jar href="org.eclipse.ui_3.1.0.jar" />
<jar href="org.eclipse.update.configurator_3.1.0.jar" />
<!--jar href="org.eclipse.update.core.win32_3.1.0.jar" /-->
<jar href="org.eclipse.update.core_3.1.0.jar" />
<jar href="org.eclipse.core.variables_3.1.0.jar" />
<jar href="org.eclipse.ui.forms_3.1.0.jar" />
<!-- system properties -->
<property name="eclipse.application" value="MyPlugin.MyApp" />
<property name="eclipse.product" value="MyApp.product" />
<property name="eclipse.consoleLog" value="true" />
</resources>
|
|
| | | | | | | | | |
Re: Webstart and RCP Eclipse 3.1 [message #437683 is a reply to message #437682] |
Sat, 01 October 2005 21:58 |
Alex Blewitt Messages: 946 Registered: July 2009 |
Senior Member |
|
|
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 22:35 |
David Scott Messages: 19 Registered: July 2009 |
Junior Member |
|
|
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).
|
|
| | |
Goto Forum:
Current Time: Sun Dec 08 16:30:36 GMT 2024
Powered by FUDForum. Page generated in 0.04448 seconds
|