WebStart for Java Swing Client

Labeled as Potential Idea - closing because of lack of community interest

I found out that lazy loading is also possible in OSGi. So I can see no reason for one or the other approach.

If we use p2 our client's environment will be more similar to the installed client installation. This will perhaps prevent some bugs. (+1 for osgi.)

I thought about enhancing security by using a one-time database user & password in combination with a signed jar file. But if this really works (i am not yet sure) we can do this later in the core application package. (+/- 0 for both of them)

I would propose to have a small Equinox core as a webstart app. I see no reason for a zip file. And we need a p2 repository well integrated into the iDempiere Application Server.

My problem is I am not used to OSGi and this stuff. (+1 for WebStart for me) And I am not used to the Buckminster scripts. It seems you are more experienced with this. Would you like to implement it? Or how can we do it together?

Thomas

I was thinking on the same lines as you. To create a small app, maybe even non-equinox, that downloads the initial client zip from server, creates the shortcuts etc and ends its role there. Then the install Swing Client updates itself using idempiere p2 repository.

As for the JNLP code I am attaching the JNLP file. The steps are simple:

• Create a new feature project, use swingclient.product to initialize it

• From the feature page, remove the .qualifier from the version field

• Right click at that project and do export -> Deployable feature

• Specify directory to create the webstart root

• On the Jar Signing tab, make sure that Sign the JAR.. is checked. You can use your own keystore or use the idempiere one ${workspace_log}/keystore/myKeystore (Keypass: myPassword, alias: idempiere, Password: <anything password you wan>)

• On the Java Web Start Tab specify the URL (e.g. http://10.0.0.1/idempiere). The attached .jnlp should have the same url so edit it accordingly.

• Run the export and after completion (will take some time as it signs each jar file) export the whole directory to your webserver at the url specified. Also copy the JNLP file to that url.

Then run the web-start by calling the url e.g. http://10.0.0.1/idempiere/idempiere.jnlp

All this can be scripted using ant and buckminster. But I think we should finalize the direction for deployment before investing time on this.

From the end user's viewpoint WebStart is a very easy way do deployment the software. You do not have to install anything but open it just with a click. For this reason I would appreciate to have WebStart.

From a technical viewpoint you are right that we loose the OSGi advantage if we are not careful. There are two possibilities in my mind: The first is to create a small equinox application core in webstart and let this core load the used OSGi plugins from a p2 site. The second would be to maintain the plugin directory on the server and to create a jnlp file for webstart from this automatically.

I do not yet know how this affects the load time through the possibility of lazy loading.

I like a bit more the second approach because this guarantees equal and tested packages on all clients. I think the first approach could do this too with an own p2 site, but I am not well experienced with OSGi/p2 stuff.

Both approaches allow to load more plugins if you want.

I would appreciate to see your code.

Thomas

This is easily done by adding a feature project for Webstart, generating signing key and exporting the project. However I don't think it would be a good idea to go ahead with Webstart due to lack of plugin update support with Webstart. In other words I think we should move towards creating an installer and adding p2 update support to Swing client. This would allow plugin level installation and update instead of a full download on every update via Webstart. In simple words we loose the OSGi advantage if we go with Webstart.

If however Webstart is still planned to be a part of iDempiere, I can post my Webstart code.