Issues with deploying a netbeans rcp app with jnlp

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Issues with deploying a netbeans rcp app with jnlp

Adrian Maier-2
Hello ,

I have a Netbeans RCP application that I want to deploy using JNLP.  It was written a few years ago and now i am 'reviving' it.  The deployment used to work at that time (3-4 years ago)  so my assumption is that the problems are related to some changes caused by the newer versions of Netbeans (8.2) and/or JDK (1.8 ).

*  First of all  : build jnlp (building the war file) takes a lot of time , aprox 10 minutes.  In comparision : clean+build the same application takes 9 seconds  .  Is this normal ?   Is there anything that can be done to speed up the build jnlp ?  
It seems to be processing all the jars of the platform each time when doing jnlp build  , again and again   - even if obviously the changes are only in my own modules (i am not touching anything in the platform)    .

*  During 'build jnlp'  i am getting a lot of warnings about missing a timestamp when signing jars. I've found on the Internet some suggestion  about going to project properties and the 'web start' tab and configure the signing there .   But I haven't been able to find that tab.  Did it exist in older NB versions and was ... removed ?

* After building the war file and deploying it into glassfish ,    when accessing the jnlp from browser there is an error about codebase having a wrong value $$codebase .


Thanks for any tip or suggestion ,
Adrian




Reply | Threaded
Open this post in threaded view
|

Re: Issues with deploying a netbeans rcp app with jnlp

Peter Hansson-2
Re build performance: I'm guessing you can build your application
without signing in a couple of seconds. So if you turn off the signing
how long does it then take to build your application?. Signing is slow
from the outset and if I remember correctly there's been some reports
that have suggested that the signing process for NB RCP apps could be
made more effective. But you only need to sign when you release your
application, so maybe not a big deal?

On Wed, Sep 13, 2017 at 11:08 PM, syraxes <[hidden email]> wrote:

> Hello ,
>
> I have a Netbeans RCP application that I want to deploy using JNLP.  It was written a few years ago and now i am 'reviving' it.  The deployment used to work at that time (3-4 years ago)  so my assumption is that the problems are related to some changes caused by the newer versions of Netbeans (8.2) and/or JDK (1.8 ).
>
> *  First of all  : build jnlp (building the war file) takes a lot of time , aprox 10 minutes.  In comparision : clean+build the same application takes 9 seconds  .  Is this normal ?   Is there anything that can be done to speed up the build jnlp ?
> It seems to be processing all the jars of the platform each time when doing jnlp build  , again and again   - even if obviously the changes are only in my own modules (i am not touching anything in the platform)    .
>
> *  During 'build jnlp'  i am getting a lot of warnings about missing a timestamp when signing jars. I've found on the Internet some suggestion  about going to project properties and the 'web start' tab and configure the signing there .   But I haven't been able to find that tab.  Did it exist in older NB versions and was ... removed ?
>
> * After building the war file and deploying it into glassfish ,    when accessing the jnlp from browser there is an error about codebase having a wrong value $$codebase .
>
>
> Thanks for any tip or suggestion ,
> Adrian
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Issues with deploying a netbeans rcp app with jnlp

kpenrose
In reply to this post by Adrian Maier-2
Are you using a maven build?  Signing jars takes a lot of time, and I mean a lot!  My RCP project takes about 30 minutes to build a jnlp deploy.  I don't worry about that anymore as browsers are killing jnlp startup support.  Chrome doesn't allow it, and now that firefox is moving to a sandboxed architecture, I wouldn't be surprised if it is close behind.