Re: Packaging JRE in RCP installer
Hi all, very thanks to figure it out and solve this old problem. best regards Oliver > Christian, the bitness of cleaner.exe makes absolutely no difference > to your aim of enforcing 64Bit. I do not plan to change anything > buildwise, only the C code, meaning it will still be a 32 bit > executable. In fact I dread if I would have to look into the build > system in Apache NetBeans of this thing. :-) > > On Fri, Sep 13, 2019 at 6:41 AM Emilian Bold wrote: > > > @Emilian Bold: Where would I document? Please point me in right > > > > direction. Thanks. > > > > I see these pages https://netbeans.apache.org/wiki/index.asciidoc are > > on GitHub here > > https://github.com/apache/netbeans-website/tree/master/netbeans.apache.or > > g/src/content/wiki > > > > So you could make a PR against GitHub. > > > > > not that there should be any reason to be running a > > > > 32bit version of Windows in 2019 > > > > I thought the same, but the brand new laptop I bought for codesigning > > CoolBeans came with a 32-bit Windows although it had a 64bit > > processor. I also had some vocal user complain about the lack of 32bit > > builds. > > > > There are very few downloads though... only 3% of the total. > > > > --emi > > > > On Fri, Sep 13, 2019 at 3:11 AM Christian Oyarzun wrote: > > > Lars, > > > > > > Is the plan to continue to keep the cleaner as a 32bit exe? > > > > > > $ file cleaner.exe > > > cleaner.exe: PE32 executable (GUI) Intel 80386, for MS Windows > > > > > > The nlw.exe executable was built as a 64bit exe, which used to be 32bit > > > in > > > previous NetBeans releases. This would prevent using the NBI to create a > > > package that > > > runs on 32bit Windows (not that there should be any reason to be running > > > a > > > 32bit version of Windows in 2019). > > > > > > $ file nlw.exe > > > nlw.exe: PE32+ executable (GUI) x86-64 (stripped to external PDB), for > > > MS > > > Windows > > > > > > This is actually what lead me down the path of embedding the JVM in the > > > installer since 64bit installer will not find a JRE if there is only a > > > 32bit JVM installed on Windows. > > > It could be worked around by using the --javahome command line option, > > > but > > > embedding it provides a better user experience. > > > > > > --Christian > > > > > > > > > > > > On Thu, Sep 12, 2019 at 4:05 PM Lars Bruun-Hansen > > > > > > > > > wrote: > > > > I've filed a Jira ticket : > > > > https://issues.apache.org/jira/browse/NETBEANS-3094 > > > > with the aim to change the C code for the cleaner.exe to be able to > > > > delete read-only files too. It is rather trivial. I've assigned it to
Re: Packaging JRE in RCP installer
Christian, the bitness of cleaner.exe makes absolutely no difference
to your aim of enforcing 64Bit. I do not plan to change anything
buildwise, only the C code, meaning it will still be a 32 bit
executable. In fact I dread if I would have to look into the build
system in Apache NetBeans of this thing. :-)
On Fri, Sep 13, 2019 at 6:41 AM Emilian Bold wrote:
>
> > @Emilian Bold: Where would I document? Please point me in right
> direction. Thanks.
>
> I see these pages https://netbeans.apache.org/wiki/index.asciidoc are
> on GitHub here
> https://github.com/apache/netbeans-website/tree/master/netbeans.apache.org/src/content/wiki
>
> So you could make a PR against GitHub.
>
> > not that there should be any reason to be running a
> 32bit version of Windows in 2019
>
> I thought the same, but the brand new laptop I bought for codesigning
> CoolBeans came with a 32-bit Windows although it had a 64bit
> processor. I also had some vocal user complain about the lack of 32bit
> builds.
>
> There are very few downloads though... only 3% of the total.
>
> --emi
>
> On Fri, Sep 13, 2019 at 3:11 AM Christian Oyarzun wrote:
> >
> > Lars,
> >
> > Is the plan to continue to keep the cleaner as a 32bit exe?
> >
> > $ file cleaner.exe
> > cleaner.exe: PE32 executable (GUI) Intel 80386, for MS Windows
> >
> > The nlw.exe executable was built as a 64bit exe, which used to be 32bit in
> > previous NetBeans releases. This would prevent using the NBI to create a
> > package that
> > runs on 32bit Windows (not that there should be any reason to be running a
> > 32bit version of Windows in 2019).
> >
> > $ file nlw.exe
> > nlw.exe: PE32+ executable (GUI) x86-64 (stripped to external PDB), for MS
> > Windows
> >
> > This is actually what lead me down the path of embedding the JVM in the
> > installer since 64bit installer will not find a JRE if there is only a
> > 32bit JVM installed on Windows.
> > It could be worked around by using the --javahome command line option, but
> > embedding it provides a better user experience.
> >
> > --Christian
> >
> >
> >
> > On Thu, Sep 12, 2019 at 4:05 PM Lars Bruun-Hansen
> > wrote:
> >
> > > I've filed a Jira ticket :
> > > https://issues.apache.org/jira/browse/NETBEANS-3094
> > > with the aim to change the C code for the cleaner.exe to be able to
> > > delete read-only files too. It is rather trivial. I've assigned it to
> > > myself.
> > >
> > > @Emilian Bold: Where would I document? Please point me in right
> > > direction. Thanks.
> > >
> > > On Thu, Sep 12, 2019 at 9:46 PM Christian Oyarzun
> > > wrote:
> > > >
> > > > Oliver, it is just a question of changing the permissions on the files
> > > > before zipping the JRE.
> > > >
> > > > I'm using a modified version (JRE instead of JDK) of
> > > > jMonkeyEngine's script to create the JRE unzipsfx files.
> > > >
> > > > It's a question of adding the following to
> > > >
> > > https://github.com/jMonkeyEngine/sdk/blob/d72264096f8c75fdf558bbb157dd573664ccf9bb/jdks/download-jdks.sh#L146
> > > >
> > > > find . -exec chmod u+w {} \; # Make all file writable to allow
> > > > uninstaller's cleaner to remove file
> > > >
> > > > I'll send them a PR.
> > > >
> > > > --Christian
> > > >
> > > >
> > > > On Thu, Sep 12, 2019 at 3:17 PM Oliver Rettig
> > > wrote:
> > > >
> > > > > Hi,
> > > > > I remember on such problems also with Netbeans 8.2. It had todo with
> > > > > access rights. I am
> > > > > interested in if you can figure it out.
> > > > > best regards
> > > > > Oliver
> > > > > > Is anyone packaging the JRE in a RCP installer using Netbeans 11.1
> > > > > > following these instructions?
> > > > > > https://dzone.com/articles/including-jre-in-nbi
> > > > > >
> > > > > > While this works fine under Linux , the Windows uninstaller does not
> > > > > delete
> > > > > > some of the JRE files.
> > > > > >
> > > > > > C:\Program Files\rcpapp>dir /s /b
> > > > > > C:\Program Files\rcpapp\jre
> > > > > > C:\Program Files\rcpapp\jre\ASSEMBLY_EXCEPTION
> > > > > > C:\Program Files\rcpapp\jre\lib
> > > > > > C:\Program Files\rcpapp\jre\LICENSE
> > > > > > C:\Program Files\rcpapp\jre\THIRD_PARTY_README
> > > > > > C:\Program Files\rcpapp\jre\lib\cmm
> > > > > > C:\Program Files\rcpapp\jre\lib\currency.data
> > > > > > C:\Program Files\rcpapp\jre\lib\fontconfig.bfc
> > > > > > C:\Program Files\rcpapp\jre\lib\management
> > > > > > C:\Program Files\rcpapp\jre\lib\cmm\CIEXYZ.pf
> > > > > > C:\Program Files\rcpapp\jre\lib\cmm\GRAY.pf
> > > > > > C:\Program Files\rcpapp\jre\lib\cmm\LINEAR_RGB.pf
> > > > > > C:\Program Files\rcpapp\jre\lib\cmm\PYCC.pf
> > > > > > C:\Program Files\rcpapp\jre\lib\cmm\sRGB.pf
> > > > > > C:\Program
> > > Files\rcpapp\jre\lib\management\jmxremote.password.template
> > > > > > C:\Program Files\rcpapp\jre\lib\management\snmp.acl.template
> > > > > >
> > > > > > Any ideas on why these files are not deleted? Could it be the
> > > > > INITIAL_DELAY
> > > > > > is too short in the cleaner.exe?
> > > > > >
> > > > > >
> > > > >
Re: Packaging JRE in RCP installer
> @Emilian Bold: Where would I document? Please point me in right
direction. Thanks.
I see these pages https://netbeans.apache.org/wiki/index.asciidoc are
on GitHub here
https://github.com/apache/netbeans-website/tree/master/netbeans.apache.org/src/content/wiki
So you could make a PR against GitHub.
> not that there should be any reason to be running a
32bit version of Windows in 2019
I thought the same, but the brand new laptop I bought for codesigning
CoolBeans came with a 32-bit Windows although it had a 64bit
processor. I also had some vocal user complain about the lack of 32bit
builds.
There are very few downloads though... only 3% of the total.
--emi
On Fri, Sep 13, 2019 at 3:11 AM Christian Oyarzun wrote:
>
> Lars,
>
> Is the plan to continue to keep the cleaner as a 32bit exe?
>
> $ file cleaner.exe
> cleaner.exe: PE32 executable (GUI) Intel 80386, for MS Windows
>
> The nlw.exe executable was built as a 64bit exe, which used to be 32bit in
> previous NetBeans releases. This would prevent using the NBI to create a
> package that
> runs on 32bit Windows (not that there should be any reason to be running a
> 32bit version of Windows in 2019).
>
> $ file nlw.exe
> nlw.exe: PE32+ executable (GUI) x86-64 (stripped to external PDB), for MS
> Windows
>
> This is actually what lead me down the path of embedding the JVM in the
> installer since 64bit installer will not find a JRE if there is only a
> 32bit JVM installed on Windows.
> It could be worked around by using the --javahome command line option, but
> embedding it provides a better user experience.
>
> --Christian
>
>
>
> On Thu, Sep 12, 2019 at 4:05 PM Lars Bruun-Hansen
> wrote:
>
> > I've filed a Jira ticket :
> > https://issues.apache.org/jira/browse/NETBEANS-3094
> > with the aim to change the C code for the cleaner.exe to be able to
> > delete read-only files too. It is rather trivial. I've assigned it to
> > myself.
> >
> > @Emilian Bold: Where would I document? Please point me in right
> > direction. Thanks.
> >
> > On Thu, Sep 12, 2019 at 9:46 PM Christian Oyarzun wrote:
> > >
> > > Oliver, it is just a question of changing the permissions on the files
> > > before zipping the JRE.
> > >
> > > I'm using a modified version (JRE instead of JDK) of
> > > jMonkeyEngine's script to create the JRE unzipsfx files.
> > >
> > > It's a question of adding the following to
> > >
> > https://github.com/jMonkeyEngine/sdk/blob/d72264096f8c75fdf558bbb157dd573664ccf9bb/jdks/download-jdks.sh#L146
> > >
> > > find . -exec chmod u+w {} \; # Make all file writable to allow
> > > uninstaller's cleaner to remove file
> > >
> > > I'll send them a PR.
> > >
> > > --Christian
> > >
> > >
> > > On Thu, Sep 12, 2019 at 3:17 PM Oliver Rettig
> > wrote:
> > >
> > > > Hi,
> > > > I remember on such problems also with Netbeans 8.2. It had todo with
> > > > access rights. I am
> > > > interested in if you can figure it out.
> > > > best regards
> > > > Oliver
> > > > > Is anyone packaging the JRE in a RCP installer using Netbeans 11.1
> > > > > following these instructions?
> > > > > https://dzone.com/articles/including-jre-in-nbi
> > > > >
> > > > > While this works fine under Linux , the Windows uninstaller does not
> > > > delete
> > > > > some of the JRE files.
> > > > >
> > > > > C:\Program Files\rcpapp>dir /s /b
> > > > > C:\Program Files\rcpapp\jre
> > > > > C:\Program Files\rcpapp\jre\ASSEMBLY_EXCEPTION
> > > > > C:\Program Files\rcpapp\jre\lib
> > > > > C:\Program Files\rcpapp\jre\LICENSE
> > > > > C:\Program Files\rcpapp\jre\THIRD_PARTY_README
> > > > > C:\Program Files\rcpapp\jre\lib\cmm
> > > > > C:\Program Files\rcpapp\jre\lib\currency.data
> > > > > C:\Program Files\rcpapp\jre\lib\fontconfig.bfc
> > > > > C:\Program Files\rcpapp\jre\lib\management
> > > > > C:\Program Files\rcpapp\jre\lib\cmm\CIEXYZ.pf
> > > > > C:\Program Files\rcpapp\jre\lib\cmm\GRAY.pf
> > > > > C:\Program Files\rcpapp\jre\lib\cmm\LINEAR_RGB.pf
> > > > > C:\Program Files\rcpapp\jre\lib\cmm\PYCC.pf
> > > > > C:\Program Files\rcpapp\jre\lib\cmm\sRGB.pf
> > > > > C:\Program
> > Files\rcpapp\jre\lib\management\jmxremote.password.template
> > > > > C:\Program Files\rcpapp\jre\lib\management\snmp.acl.template
> > > > >
> > > > > Any ideas on why these files are not deleted? Could it be the
> > > > INITIAL_DELAY
> > > > > is too short in the cleaner.exe?
> > > > >
> > > > >
> > > >
> > https://github.com/apache/netbeans/blob/0580490be48a9a2ec6279218fd0e39561aff
> > > > > dab8/nbi/engine/native/cleaner/windows/src/main.c#L28
> > > > >
> > > > > Thanks,
> > > > > Christian
> > > >
> > > >
> > > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
> >
---
Re: Packaging JRE in RCP installer
Lars,
Is the plan to continue to keep the cleaner as a 32bit exe?
$ file cleaner.exe
cleaner.exe: PE32 executable (GUI) Intel 80386, for MS Windows
The nlw.exe executable was built as a 64bit exe, which used to be 32bit in
previous NetBeans releases. This would prevent using the NBI to create a
package that
runs on 32bit Windows (not that there should be any reason to be running a
32bit version of Windows in 2019).
$ file nlw.exe
nlw.exe: PE32+ executable (GUI) x86-64 (stripped to external PDB), for MS
Windows
This is actually what lead me down the path of embedding the JVM in the
installer since 64bit installer will not find a JRE if there is only a
32bit JVM installed on Windows.
It could be worked around by using the --javahome command line option, but
embedding it provides a better user experience.
--Christian
On Thu, Sep 12, 2019 at 4:05 PM Lars Bruun-Hansen
wrote:
> I've filed a Jira ticket :
> https://issues.apache.org/jira/browse/NETBEANS-3094
> with the aim to change the C code for the cleaner.exe to be able to
> delete read-only files too. It is rather trivial. I've assigned it to
> myself.
>
> @Emilian Bold: Where would I document? Please point me in right
> direction. Thanks.
>
> On Thu, Sep 12, 2019 at 9:46 PM Christian Oyarzun wrote:
> >
> > Oliver, it is just a question of changing the permissions on the files
> > before zipping the JRE.
> >
> > I'm using a modified version (JRE instead of JDK) of
> > jMonkeyEngine's script to create the JRE unzipsfx files.
> >
> > It's a question of adding the following to
> >
> https://github.com/jMonkeyEngine/sdk/blob/d72264096f8c75fdf558bbb157dd573664ccf9bb/jdks/download-jdks.sh#L146
> >
> > find . -exec chmod u+w {} \; # Make all file writable to allow
> > uninstaller's cleaner to remove file
> >
> > I'll send them a PR.
> >
> > --Christian
> >
> >
> > On Thu, Sep 12, 2019 at 3:17 PM Oliver Rettig
> wrote:
> >
> > > Hi,
> > > I remember on such problems also with Netbeans 8.2. It had todo with
> > > access rights. I am
> > > interested in if you can figure it out.
> > > best regards
> > > Oliver
> > > > Is anyone packaging the JRE in a RCP installer using Netbeans 11.1
> > > > following these instructions?
> > > > https://dzone.com/articles/including-jre-in-nbi
> > > >
> > > > While this works fine under Linux , the Windows uninstaller does not
> > > delete
> > > > some of the JRE files.
> > > >
> > > > C:\Program Files\rcpapp>dir /s /b
> > > > C:\Program Files\rcpapp\jre
> > > > C:\Program Files\rcpapp\jre\ASSEMBLY_EXCEPTION
> > > > C:\Program Files\rcpapp\jre\lib
> > > > C:\Program Files\rcpapp\jre\LICENSE
> > > > C:\Program Files\rcpapp\jre\THIRD_PARTY_README
> > > > C:\Program Files\rcpapp\jre\lib\cmm
> > > > C:\Program Files\rcpapp\jre\lib\currency.data
> > > > C:\Program Files\rcpapp\jre\lib\fontconfig.bfc
> > > > C:\Program Files\rcpapp\jre\lib\management
> > > > C:\Program Files\rcpapp\jre\lib\cmm\CIEXYZ.pf
> > > > C:\Program Files\rcpapp\jre\lib\cmm\GRAY.pf
> > > > C:\Program Files\rcpapp\jre\lib\cmm\LINEAR_RGB.pf
> > > > C:\Program Files\rcpapp\jre\lib\cmm\PYCC.pf
> > > > C:\Program Files\rcpapp\jre\lib\cmm\sRGB.pf
> > > > C:\Program
> Files\rcpapp\jre\lib\management\jmxremote.password.template
> > > > C:\Program Files\rcpapp\jre\lib\management\snmp.acl.template
> > > >
> > > > Any ideas on why these files are not deleted? Could it be the
> > > INITIAL_DELAY
> > > > is too short in the cleaner.exe?
> > > >
> > > >
> > >
> https://github.com/apache/netbeans/blob/0580490be48a9a2ec6279218fd0e39561aff
> > > > dab8/nbi/engine/native/cleaner/windows/src/main.c#L28
> > > >
> > > > Thanks,
> > > > Christian
> > >
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: Packaging JRE in RCP installer
I've filed a Jira ticket : https://issues.apache.org/jira/browse/NETBEANS-3094
with the aim to change the C code for the cleaner.exe to be able to
delete read-only files too. It is rather trivial. I've assigned it to
myself.
@Emilian Bold: Where would I document? Please point me in right
direction. Thanks.
On Thu, Sep 12, 2019 at 9:46 PM Christian Oyarzun wrote:
>
> Oliver, it is just a question of changing the permissions on the files
> before zipping the JRE.
>
> I'm using a modified version (JRE instead of JDK) of
> jMonkeyEngine's script to create the JRE unzipsfx files.
>
> It's a question of adding the following to
> https://github.com/jMonkeyEngine/sdk/blob/d72264096f8c75fdf558bbb157dd573664ccf9bb/jdks/download-jdks.sh#L146
>
> find . -exec chmod u+w {} \; # Make all file writable to allow
> uninstaller's cleaner to remove file
>
> I'll send them a PR.
>
> --Christian
>
>
> On Thu, Sep 12, 2019 at 3:17 PM Oliver Rettig wrote:
>
> > Hi,
> > I remember on such problems also with Netbeans 8.2. It had todo with
> > access rights. I am
> > interested in if you can figure it out.
> > best regards
> > Oliver
> > > Is anyone packaging the JRE in a RCP installer using Netbeans 11.1
> > > following these instructions?
> > > https://dzone.com/articles/including-jre-in-nbi
> > >
> > > While this works fine under Linux , the Windows uninstaller does not
> > delete
> > > some of the JRE files.
> > >
> > > C:\Program Files\rcpapp>dir /s /b
> > > C:\Program Files\rcpapp\jre
> > > C:\Program Files\rcpapp\jre\ASSEMBLY_EXCEPTION
> > > C:\Program Files\rcpapp\jre\lib
> > > C:\Program Files\rcpapp\jre\LICENSE
> > > C:\Program Files\rcpapp\jre\THIRD_PARTY_README
> > > C:\Program Files\rcpapp\jre\lib\cmm
> > > C:\Program Files\rcpapp\jre\lib\currency.data
> > > C:\Program Files\rcpapp\jre\lib\fontconfig.bfc
> > > C:\Program Files\rcpapp\jre\lib\management
> > > C:\Program Files\rcpapp\jre\lib\cmm\CIEXYZ.pf
> > > C:\Program Files\rcpapp\jre\lib\cmm\GRAY.pf
> > > C:\Program Files\rcpapp\jre\lib\cmm\LINEAR_RGB.pf
> > > C:\Program Files\rcpapp\jre\lib\cmm\PYCC.pf
> > > C:\Program Files\rcpapp\jre\lib\cmm\sRGB.pf
> > > C:\Program Files\rcpapp\jre\lib\management\jmxremote.password.template
> > > C:\Program Files\rcpapp\jre\lib\management\snmp.acl.template
> > >
> > > Any ideas on why these files are not deleted? Could it be the
> > INITIAL_DELAY
> > > is too short in the cleaner.exe?
> > >
> > >
> > https://github.com/apache/netbeans/blob/0580490be48a9a2ec6279218fd0e39561aff
> > > dab8/nbi/engine/native/cleaner/windows/src/main.c#L28
> > >
> > > Thanks,
> > > Christian
> >
> >
> >
-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Packaging JRE in RCP installer
Oliver, it is just a question of changing the permissions on the files
before zipping the JRE.
I'm using a modified version (JRE instead of JDK) of
jMonkeyEngine's script to create the JRE unzipsfx files.
It's a question of adding the following to
https://github.com/jMonkeyEngine/sdk/blob/d72264096f8c75fdf558bbb157dd573664ccf9bb/jdks/download-jdks.sh#L146
find . -exec chmod u+w {} \; # Make all file writable to allow
uninstaller's cleaner to remove file
I'll send them a PR.
--Christian
On Thu, Sep 12, 2019 at 3:17 PM Oliver Rettig wrote:
> Hi,
> I remember on such problems also with Netbeans 8.2. It had todo with
> access rights. I am
> interested in if you can figure it out.
> best regards
> Oliver
> > Is anyone packaging the JRE in a RCP installer using Netbeans 11.1
> > following these instructions?
> > https://dzone.com/articles/including-jre-in-nbi
> >
> > While this works fine under Linux , the Windows uninstaller does not
> delete
> > some of the JRE files.
> >
> > C:\Program Files\rcpapp>dir /s /b
> > C:\Program Files\rcpapp\jre
> > C:\Program Files\rcpapp\jre\ASSEMBLY_EXCEPTION
> > C:\Program Files\rcpapp\jre\lib
> > C:\Program Files\rcpapp\jre\LICENSE
> > C:\Program Files\rcpapp\jre\THIRD_PARTY_README
> > C:\Program Files\rcpapp\jre\lib\cmm
> > C:\Program Files\rcpapp\jre\lib\currency.data
> > C:\Program Files\rcpapp\jre\lib\fontconfig.bfc
> > C:\Program Files\rcpapp\jre\lib\management
> > C:\Program Files\rcpapp\jre\lib\cmm\CIEXYZ.pf
> > C:\Program Files\rcpapp\jre\lib\cmm\GRAY.pf
> > C:\Program Files\rcpapp\jre\lib\cmm\LINEAR_RGB.pf
> > C:\Program Files\rcpapp\jre\lib\cmm\PYCC.pf
> > C:\Program Files\rcpapp\jre\lib\cmm\sRGB.pf
> > C:\Program Files\rcpapp\jre\lib\management\jmxremote.password.template
> > C:\Program Files\rcpapp\jre\lib\management\snmp.acl.template
> >
> > Any ideas on why these files are not deleted? Could it be the
> INITIAL_DELAY
> > is too short in the cleaner.exe?
> >
> >
> https://github.com/apache/netbeans/blob/0580490be48a9a2ec6279218fd0e39561aff
> > dab8/nbi/engine/native/cleaner/windows/src/main.c#L28
> >
> > Thanks,
> > Christian
>
>
>
Re: Packaging JRE in RCP installer
Hi, I remember on such problems also with Netbeans 8.2. It had todo with access rights. I am interested in if you can figure it out. best regards Oliver > Is anyone packaging the JRE in a RCP installer using Netbeans 11.1 > following these instructions? > https://dzone.com/articles/including-jre-in-nbi > > While this works fine under Linux , the Windows uninstaller does not delete > some of the JRE files. > > C:\Program Files\rcpapp>dir /s /b > C:\Program Files\rcpapp\jre > C:\Program Files\rcpapp\jre\ASSEMBLY_EXCEPTION > C:\Program Files\rcpapp\jre\lib > C:\Program Files\rcpapp\jre\LICENSE > C:\Program Files\rcpapp\jre\THIRD_PARTY_README > C:\Program Files\rcpapp\jre\lib\cmm > C:\Program Files\rcpapp\jre\lib\currency.data > C:\Program Files\rcpapp\jre\lib\fontconfig.bfc > C:\Program Files\rcpapp\jre\lib\management > C:\Program Files\rcpapp\jre\lib\cmm\CIEXYZ.pf > C:\Program Files\rcpapp\jre\lib\cmm\GRAY.pf > C:\Program Files\rcpapp\jre\lib\cmm\LINEAR_RGB.pf > C:\Program Files\rcpapp\jre\lib\cmm\PYCC.pf > C:\Program Files\rcpapp\jre\lib\cmm\sRGB.pf > C:\Program Files\rcpapp\jre\lib\management\jmxremote.password.template > C:\Program Files\rcpapp\jre\lib\management\snmp.acl.template > > Any ideas on why these files are not deleted? Could it be the INITIAL_DELAY > is too short in the cleaner.exe? > > https://github.com/apache/netbeans/blob/0580490be48a9a2ec6279218fd0e39561aff > dab8/nbi/engine/native/cleaner/windows/src/main.c#L28 > > Thanks, > Christian
Re: Packaging JRE in RCP installer
Lars, those notes do deserve a wiki page indeed. --emi joi, 12 sept. 2019, 20:45 Lars Bruun-Hansen a scris: > Hi Christian > > I once wrote some notes on how the cleaner works. (yes, they are > probably worthy of a Wiki page, but currently the only exist here). It > was written about 5 years ago, but I doubt it has changed. The notes > are below and I think they are worth the read because I'm guessing > they implicitly tell you what your problem is. Here we go: > > > --- Begin notes --- > > Background > -- > The "cleaner" is a small native application which is part of the > NetBeans Installer (NBI) infrastructure. The job of the cleaner is to > delete files which the JVM process for some reason cannot delete > itself. Java has its own deleteOnExit() method but that method is > pretty useless as it cannot delete files that the JVM itself uses. > Hence the idea of a cleaner. > > NBI has two cleaners: One for Linux/Mac which is a shell script and > one for Windows (cleaner.exe) which is a native image. The cleaner > gets launched from Java at the end of the NBI install/uninstall > process (from a shutdown hook). It gets launched in such a clever way > that it becomes detached from the JVM process itself, hence it will > live on even when the JVM process closes. On Unices such a process > would be known as a 'daemon' and is created by a technique called > double-fork. On Windows this is known as a 'process without handles'. > Java doesn't support spawning such a process so NBI has to rely on > native OS calls in order to create such a detached process. > > The cleaner works off a list of files to delete. It gets passed this > list of files as an argument on the command line. The list is in a > temporary file. The cleaner deletes this file after it has read it. > The list of files is supposed to be ordered so the delete happens in > the right sequence (you cannot delete a directory before you've > deleted all files in it). This ordering is done automatically by the > NBI Engine (nbi-engine.jar) so this is not something anyone creating > an installer should worry about. > > The cleaner can delete both files and directories ...if they are > empty. The cleaner has no feature for recursing through a directory > and deleting all files below it. Therefore, in order to delete a tree, > the cleaner must be told explicitly which files to delete and in which > order. > > > > How does the cleaner work on Windows ? > -- > > On Windows the cleaner is a very small C program. It is (at the > moment) always 32-bit regardless of JVM or Windows version. > > After launch the cleaner will read the list of files to delete from a > temporary file. The list of files to delete is read into memory and > the cleaner can therefore delete the temporary file immediately after > it has been read. > > After reading the file list the cleaner sleeps for 2 seconds. This is > to allow the JVM process that has started it to close down. The 2 secs > are hardcoded. > > The cleaner will then loop over the list of files to delete. Each > file-delete operation is spawned into a thread of its own up to a > maximum of 64 threads. Therefore the delete operations happens in > parallel rather than in sequence. (Note: I find this design somewhat > dangerous as the order of delete can be quite important.). > > For each delete operation the cleaner will do the following: > > - Checks to see if the file exists (by getting its attributes) > - If file: delete file, if directory: delete directory (these are > two different calls in the Win32 API). > - Attempt to delete each file/dir up to 15 times sleeping for 200 > ms between each attempt. > > If there are no available threads (i.e. there more than 64 files to > delete) then the cleaner process will wait until a there are less than > 64 active threads. In other words: At any point in time there are > never more than 64 active threads. > > The cleaner process has absolutely no logging features so it is pretty > difficult so say what it does if something goes wrong. > > > --- End notes --- > > Those were my notes. > > I'm guessing the problem you see is that the cleaner cannot delete a > file with read-only attribute set. Or it is the somewhat dangerous > design of deleting files in parallel which is causing probs. I'm > leaning towards the first one. Your own guess - the two secs delay - I > don't much believe is the problem since the cleaner will attempt to > delete each file 15 times sleeping 200 ms between each attempt. > > > /Lars > > On Thu, Sep 12, 2019 at 3:48 PM Christian Oyarzun wrote: > > > > Is anyone packaging the JRE in a RCP installer using Netbeans 11.1 > > following these instructions? > > https://dzone.com/articles/including-jre-in-nbi > > > > While this works fine under Linux , the Windows uninstaller does not > delete > > some of the JRE files. > > > > C:\Program Files\rcpapp>dir /s /b > > C:\Program Files\rcpapp\jre > > C:\Program Files\rcpapp\j
Re: Packaging JRE in RCP installer
Hi Lars, Thanks for the information. Your guess was correct, those files had the read-only attribute set. Unsetting those attributes allowed the clearer to remove the files and top-level directory. Thanks, Christian On Thu, Sep 12, 2019 at 1:45 PM Lars Bruun-Hansen wrote: > Hi Christian > > I once wrote some notes on how the cleaner works. (yes, they are > probably worthy of a Wiki page, but currently the only exist here). It > was written about 5 years ago, but I doubt it has changed. The notes > are below and I think they are worth the read because I'm guessing > they implicitly tell you what your problem is. Here we go: > > > --- Begin notes --- > > Background > -- > The "cleaner" is a small native application which is part of the > NetBeans Installer (NBI) infrastructure. The job of the cleaner is to > delete files which the JVM process for some reason cannot delete > itself. Java has its own deleteOnExit() method but that method is > pretty useless as it cannot delete files that the JVM itself uses. > Hence the idea of a cleaner. > > NBI has two cleaners: One for Linux/Mac which is a shell script and > one for Windows (cleaner.exe) which is a native image. The cleaner > gets launched from Java at the end of the NBI install/uninstall > process (from a shutdown hook). It gets launched in such a clever way > that it becomes detached from the JVM process itself, hence it will > live on even when the JVM process closes. On Unices such a process > would be known as a 'daemon' and is created by a technique called > double-fork. On Windows this is known as a 'process without handles'. > Java doesn't support spawning such a process so NBI has to rely on > native OS calls in order to create such a detached process. > > The cleaner works off a list of files to delete. It gets passed this > list of files as an argument on the command line. The list is in a > temporary file. The cleaner deletes this file after it has read it. > The list of files is supposed to be ordered so the delete happens in > the right sequence (you cannot delete a directory before you've > deleted all files in it). This ordering is done automatically by the > NBI Engine (nbi-engine.jar) so this is not something anyone creating > an installer should worry about. > > The cleaner can delete both files and directories ...if they are > empty. The cleaner has no feature for recursing through a directory > and deleting all files below it. Therefore, in order to delete a tree, > the cleaner must be told explicitly which files to delete and in which > order. > > > > How does the cleaner work on Windows ? > -- > > On Windows the cleaner is a very small C program. It is (at the > moment) always 32-bit regardless of JVM or Windows version. > > After launch the cleaner will read the list of files to delete from a > temporary file. The list of files to delete is read into memory and > the cleaner can therefore delete the temporary file immediately after > it has been read. > > After reading the file list the cleaner sleeps for 2 seconds. This is > to allow the JVM process that has started it to close down. The 2 secs > are hardcoded. > > The cleaner will then loop over the list of files to delete. Each > file-delete operation is spawned into a thread of its own up to a > maximum of 64 threads. Therefore the delete operations happens in > parallel rather than in sequence. (Note: I find this design somewhat > dangerous as the order of delete can be quite important.). > > For each delete operation the cleaner will do the following: > > - Checks to see if the file exists (by getting its attributes) > - If file: delete file, if directory: delete directory (these are > two different calls in the Win32 API). > - Attempt to delete each file/dir up to 15 times sleeping for 200 > ms between each attempt. > > If there are no available threads (i.e. there more than 64 files to > delete) then the cleaner process will wait until a there are less than > 64 active threads. In other words: At any point in time there are > never more than 64 active threads. > > The cleaner process has absolutely no logging features so it is pretty > difficult so say what it does if something goes wrong. > > > --- End notes --- > > Those were my notes. > > I'm guessing the problem you see is that the cleaner cannot delete a > file with read-only attribute set. Or it is the somewhat dangerous > design of deleting files in parallel which is causing probs. I'm > leaning towards the first one. Your own guess - the two secs delay - I > don't much believe is the problem since the cleaner will attempt to > delete each file 15 times sleeping 200 ms between each attempt. > > > /Lars > > On Thu, Sep 12, 2019 at 3:48 PM Christian Oyarzun wrote: > > > > Is anyone packaging the JRE in a RCP installer using Netbeans 11.1 > > following these instructions? > > https://dzone.com/articles/including-jre-in-nbi > > > > While this works fine under Linux , the Wi
Re: Packaging JRE in RCP installer
Hi Christian I once wrote some notes on how the cleaner works. (yes, they are probably worthy of a Wiki page, but currently the only exist here). It was written about 5 years ago, but I doubt it has changed. The notes are below and I think they are worth the read because I'm guessing they implicitly tell you what your problem is. Here we go: --- Begin notes --- Background -- The "cleaner" is a small native application which is part of the NetBeans Installer (NBI) infrastructure. The job of the cleaner is to delete files which the JVM process for some reason cannot delete itself. Java has its own deleteOnExit() method but that method is pretty useless as it cannot delete files that the JVM itself uses. Hence the idea of a cleaner. NBI has two cleaners: One for Linux/Mac which is a shell script and one for Windows (cleaner.exe) which is a native image. The cleaner gets launched from Java at the end of the NBI install/uninstall process (from a shutdown hook). It gets launched in such a clever way that it becomes detached from the JVM process itself, hence it will live on even when the JVM process closes. On Unices such a process would be known as a 'daemon' and is created by a technique called double-fork. On Windows this is known as a 'process without handles'. Java doesn't support spawning such a process so NBI has to rely on native OS calls in order to create such a detached process. The cleaner works off a list of files to delete. It gets passed this list of files as an argument on the command line. The list is in a temporary file. The cleaner deletes this file after it has read it. The list of files is supposed to be ordered so the delete happens in the right sequence (you cannot delete a directory before you've deleted all files in it). This ordering is done automatically by the NBI Engine (nbi-engine.jar) so this is not something anyone creating an installer should worry about. The cleaner can delete both files and directories ...if they are empty. The cleaner has no feature for recursing through a directory and deleting all files below it. Therefore, in order to delete a tree, the cleaner must be told explicitly which files to delete and in which order. How does the cleaner work on Windows ? -- On Windows the cleaner is a very small C program. It is (at the moment) always 32-bit regardless of JVM or Windows version. After launch the cleaner will read the list of files to delete from a temporary file. The list of files to delete is read into memory and the cleaner can therefore delete the temporary file immediately after it has been read. After reading the file list the cleaner sleeps for 2 seconds. This is to allow the JVM process that has started it to close down. The 2 secs are hardcoded. The cleaner will then loop over the list of files to delete. Each file-delete operation is spawned into a thread of its own up to a maximum of 64 threads. Therefore the delete operations happens in parallel rather than in sequence. (Note: I find this design somewhat dangerous as the order of delete can be quite important.). For each delete operation the cleaner will do the following: - Checks to see if the file exists (by getting its attributes) - If file: delete file, if directory: delete directory (these are two different calls in the Win32 API). - Attempt to delete each file/dir up to 15 times sleeping for 200 ms between each attempt. If there are no available threads (i.e. there more than 64 files to delete) then the cleaner process will wait until a there are less than 64 active threads. In other words: At any point in time there are never more than 64 active threads. The cleaner process has absolutely no logging features so it is pretty difficult so say what it does if something goes wrong. --- End notes --- Those were my notes. I'm guessing the problem you see is that the cleaner cannot delete a file with read-only attribute set. Or it is the somewhat dangerous design of deleting files in parallel which is causing probs. I'm leaning towards the first one. Your own guess - the two secs delay - I don't much believe is the problem since the cleaner will attempt to delete each file 15 times sleeping 200 ms between each attempt. /Lars On Thu, Sep 12, 2019 at 3:48 PM Christian Oyarzun wrote: > > Is anyone packaging the JRE in a RCP installer using Netbeans 11.1 > following these instructions? > https://dzone.com/articles/including-jre-in-nbi > > While this works fine under Linux , the Windows uninstaller does not delete > some of the JRE files. > > C:\Program Files\rcpapp>dir /s /b > C:\Program Files\rcpapp\jre > C:\Program Files\rcpapp\jre\ASSEMBLY_EXCEPTION > C:\Program Files\rcpapp\jre\lib > C:\Program Files\rcpapp\jre\LICENSE > C:\Program Files\rcpapp\jre\THIRD_PARTY_README > C:\Program Files\rcpapp\jre\lib\cmm > C:\Program Files\rcpapp\jre\lib\currency.data > C:\Program Files\rcpapp\jre\lib\fontconfig.bfc > C:\Program Files\rcpapp\jre\lib\m
