You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Eirik Bakke <eb...@ultorg.com.INVALID> on 2025/03/14 18:02:17 UTC
Re: Re : Re: heads up: windows installer/uninstaller issues
My NetBeans Platform app uses an MSI installer on Windows, built and signed with GitHub actions scripts that I could share, if this would be an alternative for NetBeans.
If anyone on Windows wants to test that installation experience and evaluate it for NetBeans, the installer is here: https://www.ultorg.com/download/
(Behind a “start trial” account creation flow, sorry…)
In my case the app redistributes a Zulu build of OpenJDK. Was this ever found to be a possibility for official Apache releases of NetBeans, or is it still always necessary for users to download the JDK on their own?
-- Eirik
From: Michael Bien <mb...@gmail.com>
Reply-To: "dev@netbeans.apache.org" <de...@netbeans.apache.org>
Date: Friday, February 28, 2025 at 11:12 AM
To: "dev@netbeans.apache.org" <de...@netbeans.apache.org>, Eric Barboni <sk...@apache.org>
Subject: Re: Re : Re: heads up: windows installer/uninstaller issues
On 28.02.25 16:53, Eric Barboni wrote:
Thanks for the triage of issue.
I'm not sure windows user got easy to powershell to manage their packet. What I see on others IDE it's MSSTORE stuff or msi/exe.
https://winstall.app/apps/Apache.NetBeans
sounds like easy enough to do, no?
as double click solution we could offer a .bat file ;)
-mbien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org<ma...@netbeans.apache.org>
For additional commands, e-mail: dev-help@netbeans.apache.org<ma...@netbeans.apache.org>
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Michael Bien <mb...@gmail.com>.
On 3/25/25 21:52, Matthias Bläsing wrote:
> Hi,
>
> Am Dienstag, dem 25.03.2025 um 21:50 +0100 schrieb Michael Bien:
>> On 3/25/25 21:33, Matthias Bläsing wrote:
>>> Hi,
>>>
>>> Am Dienstag, dem 25.03.2025 um 19:44 +0000 schrieb Eirik Bakke:
>>>>> The quicker fix might just be to look at making the launcher JAVA_HOME aware, and show a better message about setting that?
>>>> Yes, that's also an improvement!
>>> as part of the agent idea to fix the clipboard problem, the launcher
>>> needs to be modified.
>> lets try to avoid this is possible. The agent itself needs to be able to turn itself off anyway. If we want to enable it in the zip and not only via specific installers, it should be possible to configure it with the launch config file in a platform independent manner without baking the flags it into the windows launcher binaries.
>>
>> the last win launcher release was motivated alone due to the need to remove a JVM option - lets not keep adding temporary options if avoidable.
> you have not seen what I implemented, so please hold back judgement.
>
> The agent does not need to disable itself. It just has to ensure, that
> it only modifies classes, it should touch.
of course, but this is not the issue here. Looking forward to take a look at the proposal.
-mbien
>
> Greetings
>
> Matthias
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Matthias Bläsing <mb...@doppel-helix.eu.INVALID>.
Hi,
Am Dienstag, dem 25.03.2025 um 21:50 +0100 schrieb Michael Bien:
> On 3/25/25 21:33, Matthias Bläsing wrote:
> > Hi,
> >
> > Am Dienstag, dem 25.03.2025 um 19:44 +0000 schrieb Eirik Bakke:
> > > > The quicker fix might just be to look at making the launcher JAVA_HOME aware, and show a better message about setting that?
> > > Yes, that's also an improvement!
> > as part of the agent idea to fix the clipboard problem, the launcher
> > needs to be modified.
>
> lets try to avoid this is possible. The agent itself needs to be able to turn itself off anyway. If we want to enable it in the zip and not only via specific installers, it should be possible to configure it with the launch config file in a platform independent manner without baking the flags it into the windows launcher binaries.
>
> the last win launcher release was motivated alone due to the need to remove a JVM option - lets not keep adding temporary options if avoidable.
you have not seen what I implemented, so please hold back judgement.
The agent does not need to disable itself. It just has to ensure, that
it only modifies classes, it should touch.
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Michael Bien <mb...@gmail.com>.
On 3/25/25 21:33, Matthias Bläsing wrote:
> Hi,
>
> Am Dienstag, dem 25.03.2025 um 19:44 +0000 schrieb Eirik Bakke:
>>> The quicker fix might just be to look at making the launcher JAVA_HOME aware, and show a better message about setting that?
>> Yes, that's also an improvement!
> as part of the agent idea to fix the clipboard problem, the launcher
> needs to be modified.
lets try to avoid this is possible. The agent itself needs to be able to turn itself off anyway. If we want to enable it in the zip and not only via specific installers, it should be possible to configure it with the launch config file in a platform independent manner without baking the flags it into the windows launcher binaries.
the last win launcher release was motivated alone due to the need to remove a JVM option - lets not keep adding temporary options if avoidable.
-mbien
> I locally have a version, that:
>
> - scans registry (retain old behavior)
> - checks JAVA_HOME
> - checks PATH
>
> The latter two are added. Seems to work, give me a bit, I'll try to get
> it out in the next days.
>
> Greetings
>
> Matthias
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Matthias Bläsing <mb...@doppel-helix.eu.INVALID>.
Hi,
Am Dienstag, dem 25.03.2025 um 19:44 +0000 schrieb Eirik Bakke:
>
> > The quicker fix might just be to look at making the launcher JAVA_HOME aware, and show a better message about setting that?
>
> Yes, that's also an improvement!
as part of the agent idea to fix the clipboard problem, the launcher
needs to be modified. I locally have a version, that:
- scans registry (retain old behavior)
- checks JAVA_HOME
- checks PATH
The latter two are added. Seems to work, give me a bit, I'll try to get
it out in the next days.
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Eirik Bakke <eb...@ultorg.com.INVALID>.
> Why would we have to preserve comments in an (almost certainly) non-existent file? Note I mean <userdir>/etc/netbeans.conf and not the netbeans.conf in the installation.
Oh, I assumed ~/etc/netbeans.conf was some existing, frequently used way to override the NetBeans configuration. If not, never mind.
> Fine for Windows. Surprised that's working for you to pass notarization on macOS.
Actually, I was wrong--the script there is in fact signed with codesign.
> The quicker fix might just be to look at making the launcher JAVA_HOME aware, and show a better message about setting that?
Yes, that's also an improvement!
-- Eirik
From: Neil C Smith <ne...@apache.org>
Reply-To: "dev@netbeans.apache.org" <de...@netbeans.apache.org>
Date: Tuesday, March 25, 2025 at 1:27 PM
To: "dev@netbeans.apache.org" <de...@netbeans.apache.org>
Subject: Re: Re : Re: heads up: windows installer/uninstaller issues
On Tue, 25 Mar 2025 at 16:50, Eirik Bakke <eb...@ultorg.com.inva>lid> wrote:
> Well, the obvious place to store it would be the <userdir>/etc/netbeans.conf although there's potentially a chicken and egg upgrade issue with doing that.
That sounds fine, too. Though netbeans.conf is traditionally modified the user, and never automatically. If the launcher is going to modify a setting, it might be best to have a separate file for that so that we don't have to worry about preserving comments etc. (And so the user doesn't have to wonder if a change was their own or made automatically.)
Why would we have to preserve comments in an (almost certainly)
non-existent file? Note I mean <userdir>/etc/netbeans.conf and not
the netbeans.conf in the installation.
> But then we've also been making a move to get rid of native executables rather than add more, as they're a pain for releasing.
In my platform app I just treat the native executable as a pre-compiled asset that doesn't actually need to be re-built for each release.
Exactly as we are doing, just they need to be voted on and release
signed separately so they can be distributed for use in the build.
I also intentionally do not sign it. (Rather, I sign the entire MSI installer on Windows and the entire application package on MacOS.)
Fine for Windows. Surprised that's working for you to pass
notarization on macOS.
Yeah, my inclination would be to implement the same "browse for JDK on first start" enhancement in both the MacOS Swift launcher and the netbeans64.exe launcher on Windows. It's twice the work, but once it's done, it's done, and the launcher can be left alone again essentially forever.
The fundamental difference being that the Swift launcher is not in the
zip and the exe launcher is. The Swift launcher is also much simpler
as it executes the existing shell script. As for being left alone
again, we've had two updates to the Windows launcher in the last year
or so. Although your proposal would potentially be a bigger change
than either of those. The quicker fix might just be to look at making
the launcher JAVA_HOME aware, and show a better message about setting
that?
There was a brief discussion on Slack about a Java-based launcher that
could work either as a source file or compiled into a native image. I
personally think that's an idea worth considering at least. It would
improve our ability to enhance, maintain and adapt the launcher.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org<ma...@netbeans.apache.org>
For additional commands, e-mail: dev-help@netbeans.apache.org<ma...@netbeans.apache.org>
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Neil C Smith <ne...@apache.org>.
On Tue, 25 Mar 2025 at 16:50, Eirik Bakke <eb...@ultorg.com.invalid> wrote:
> > Well, the obvious place to store it would be the <userdir>/etc/netbeans.conf although there's potentially a chicken and egg upgrade issue with doing that.
>
> That sounds fine, too. Though netbeans.conf is traditionally modified the user, and never automatically. If the launcher is going to modify a setting, it might be best to have a separate file for that so that we don't have to worry about preserving comments etc. (And so the user doesn't have to wonder if a change was their own or made automatically.)
Why would we have to preserve comments in an (almost certainly)
non-existent file? Note I mean <userdir>/etc/netbeans.conf and not
the netbeans.conf in the installation.
> > But then we've also been making a move to get rid of native executables rather than add more, as they're a pain for releasing.
>
> In my platform app I just treat the native executable as a pre-compiled asset that doesn't actually need to be re-built for each release.
Exactly as we are doing, just they need to be voted on and release
signed separately so they can be distributed for use in the build.
> I also intentionally do not sign it. (Rather, I sign the entire MSI installer on Windows and the entire application package on MacOS.)
Fine for Windows. Surprised that's working for you to pass
notarization on macOS.
> Yeah, my inclination would be to implement the same "browse for JDK on first start" enhancement in both the MacOS Swift launcher and the netbeans64.exe launcher on Windows. It's twice the work, but once it's done, it's done, and the launcher can be left alone again essentially forever.
The fundamental difference being that the Swift launcher is not in the
zip and the exe launcher is. The Swift launcher is also much simpler
as it executes the existing shell script. As for being left alone
again, we've had two updates to the Windows launcher in the last year
or so. Although your proposal would potentially be a bigger change
than either of those. The quicker fix might just be to look at making
the launcher JAVA_HOME aware, and show a better message about setting
that?
There was a brief discussion on Slack about a Java-based launcher that
could work either as a source file or compiled into a native image. I
personally think that's an idea worth considering at least. It would
improve our ability to enhance, maintain and adapt the launcher.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Eirik Bakke <eb...@ultorg.com.INVALID>.
> Well, the obvious place to store it would be the <userdir>/etc/netbeans.conf although there's potentially a chicken and egg upgrade issue with doing that.
That sounds fine, too. Though netbeans.conf is traditionally modified the user, and never automatically. If the launcher is going to modify a setting, it might be best to have a separate file for that so that we don't have to worry about preserving comments etc. (And so the user doesn't have to wonder if a change was their own or made automatically.)
> But then we've also been making a move to get rid of native executables rather than add more, as they're a pain for releasing.
In my platform app I just treat the native executable as a pre-compiled asset that doesn't actually need to be re-built for each release. I also intentionally do not sign it. (Rather, I sign the entire MSI installer on Windows and the entire application package on MacOS.)
> NBPackage already builds a small Swift launcher on macOS. That might be extended to provide that functionality without impact on IDE builds on other platforms.
Yeah, my inclination would be to implement the same "browse for JDK on first start" enhancement in both the MacOS Swift launcher and the netbeans64.exe launcher on Windows. It's twice the work, but once it's done, it's done, and the launcher can be left alone again essentially forever.
-- Eirik
From: Neil C Smith <ne...@apache.org>
Reply-To: "dev@netbeans.apache.org" <de...@netbeans.apache.org>
Date: Tuesday, March 25, 2025 at 8:19 AM
To: "dev@netbeans.apache.org" <de...@netbeans.apache.org>
Subject: Re: Re : Re: heads up: windows installer/uninstaller issues
I realized I didn't respond to this ...
On Fri, 21 Mar 2025 at 18:06, Eirik Bakke <eb...@ultorg.com.inva>lid> wrote:
> I don't think having a system installed IDE relying on any of these transient user space things makes sense
This is true--but perhaps it could be alleviated by having the installer install per-user rather than per-machine? This is what I did for my MSI installer, after a lot of research.
...
The great thing about this is that no administrator access is needed to install.
This is feasible, although at the moment would require using the
NBPackage facility to override default templates - in particular
https://github.com/apache/netbeans-nbpackage/blob/master/src/main/resources/org/apache/netbeans/nbpackage/innosetup/InnoSetup.iss.template
Adding settings for either
https://jrsoftware.org/ishelp/index.php?topic=setup_privilegesrequiredoverridesallowed
or https://jrsoftware.org/ishelp/index.php?topic=setup_privilegesrequired
It might be useful to add an option for that instead. Would need
testing. Some people do want admin installs though.
And if NetBeans is installed this way, then makes more sense to allow the user to browse to their own unzipped OpenJDK distro somewhere when they first run netbeans64.exe. If that folder later goes away, we can always prompt again.
..
I'd propose the same approach as for the Windows installer; have a small native executable that prompts for the location of the JDK. Then remember it for subsequent runs. The single piece of information about where the JDK is can be stored in the user's home directory, e.g. "~/.netbeans".
Well, the obvious place to store it would be the
<userdir>/etc/netbeans.conf although there's potentially a chicken and
egg upgrade issue with doing that.
Partly this comes down to enhancing all the launchers, which would
benefit the zip too. But then we've also been making a move to get
rid of native executables rather than add more, as they're a pain for
releasing. NBPackage already builds a small Swift launcher on macOS.
That might be extended to provide that functionality without impact on
IDE builds on other platforms.
That's mostly concentrating on the lesser point I was making, which
was more about the importance of the signed bundle being immutable,
self-contained, and with all the correct permissions.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org<ma...@netbeans.apache.org>
For additional commands, e-mail: dev-help@netbeans.apache.org<ma...@netbeans.apache.org>
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Neil C Smith <ne...@apache.org>.
I realized I didn't respond to this ...
On Fri, 21 Mar 2025 at 18:06, Eirik Bakke <eb...@ultorg.com.invalid> wrote:
> > I don't think having a system installed IDE relying on any of these transient user space things makes sense
>
> This is true--but perhaps it could be alleviated by having the installer install per-user rather than per-machine? This is what I did for my MSI installer, after a lot of research.
...
> The great thing about this is that no administrator access is needed to install.
This is feasible, although at the moment would require using the
NBPackage facility to override default templates - in particular
https://github.com/apache/netbeans-nbpackage/blob/master/src/main/resources/org/apache/netbeans/nbpackage/innosetup/InnoSetup.iss.template
Adding settings for either
https://jrsoftware.org/ishelp/index.php?topic=setup_privilegesrequiredoverridesallowed
or https://jrsoftware.org/ishelp/index.php?topic=setup_privilegesrequired
It might be useful to add an option for that instead. Would need
testing. Some people do want admin installs though.
> And if NetBeans is installed this way, then makes more sense to allow the user to browse to their own unzipped OpenJDK distro somewhere when they first run netbeans64.exe. If that folder later goes away, we can always prompt again.
..
> I'd propose the same approach as for the Windows installer; have a small native executable that prompts for the location of the JDK. Then remember it for subsequent runs. The single piece of information about where the JDK is can be stored in the user's home directory, e.g. "~/.netbeans".
Well, the obvious place to store it would be the
<userdir>/etc/netbeans.conf although there's potentially a chicken and
egg upgrade issue with doing that.
Partly this comes down to enhancing all the launchers, which would
benefit the zip too. But then we've also been making a move to get
rid of native executables rather than add more, as they're a pain for
releasing. NBPackage already builds a small Swift launcher on macOS.
That might be extended to provide that functionality without impact on
IDE builds on other platforms.
That's mostly concentrating on the lesser point I was making, which
was more about the importance of the signed bundle being immutable,
self-contained, and with all the correct permissions.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Eirik Bakke <eb...@ultorg.com.INVALID>.
> Obviously a single, system installed JDK is less of a thing these days. I don't think you can get an installer for Eclipse or IntelliJ that doesn't bundle a runtime now.
I agree with this. Myself, I never "install" Java these days; I unzip it somewhere.
> I don't think having a system installed IDE relying on any of these transient user space things makes sense
This is true--but perhaps it could be alleviated by having the installer install per-user rather than per-machine? This is what I did for my MSI installer, after a lot of research.
It means that the IDE would end up in
C:\Users\myusername\AppData\Local\Programs\NetBeans
instead of in
C:\Program Files\NetBeans
The great thing about this is that no administrator access is needed to install. And if NetBeans is installed this way, then makes more sense to allow the user to browse to their own unzipped OpenJDK distro somewhere when they first run netbeans64.exe. If that folder later goes away, we can always prompt again. And inside the IDE, there's a lot more flexibility with respect to how to select JDK folders for actual builds (in Tools->Java Options).
> There is an additional factor with macOS which might eventually be seen elsewhere related to code signing, integrity and permissions. Never mind admin permissions, you can't even change the netbeans.conf on the macOS install without it being marked as broken.
I'd propose the same approach as for the Windows installer; have a small native executable that prompts for the location of the JDK. Then remember it for subsequent runs. The single piece of information about where the JDK is can be stored in the user's home directory, e.g. "~/.netbeans".
-- Eirik
From: Neil C Smith <ne...@apache.org>
Reply-To: "dev@netbeans.apache.org" <de...@netbeans.apache.org>
Date: Friday, March 21, 2025 at 11:59 AM
To: "dev@netbeans.apache.org" <de...@netbeans.apache.org>
Subject: Re: Re : Re: heads up: windows installer/uninstaller issues
On Fri, 21 Mar 2025 at 15:03, Eirik Bakke <eb...@ultorg.com.inva>lid> wrote:
2) is unnecessary - we can already build a Windows installer using NBPackage - the only thing stopping us switching a long time ago is something like 1).
OK, very good. Is the thing it generates an InnoSetup EXE that does not by itself require Java?
Yes. Everything that NBPackage generates uses native tools and does
not require Java at install time - InnoSetup exe, macOS pkg, Linux
deb, rpm, or appimage.
A JDK runtime is also optional in all the package types. All the
other installers from ASF have been built with it for some time. The
launcher issues on Windows are why we've stuck with NBI to date. We
should fix them regardless because it would make the zip better.
There is a way to use the InnoSetup installer now by customizing the
shortcut to use netbeans --jdkhome "%JAVA_HOME%\" It's a bit clunky,
and requires the extra backslash as I noted earlier on this thread
because Windows decided that mixing path separators and escape
characters makes sense! :-)
> installers without a runtime have other issues
Even if netbeans64.exe is updated to prompt for a JDK folder?
Obviously a single, system installed JDK is less of a thing these
days. I don't think you can get an installer for Eclipse or IntelliJ
that doesn't bundle a runtime now. I have a whole bunch of JDKs on my
machine, some installed, some downloaded manually, or by NetBeans, or
by Gradle. I don't think having a system installed IDE relying on any
of these transient user space things makes sense, even if I regularly
test things using --jdkhome overrides. The default works out of the
box, is a known entity, and is not affected by anything else. Nor
does it affect anything else - the bundled JDK is an entirely private
part of the installed IDE (or RCP app).
There is an additional factor with macOS which might eventually be
seen elsewhere related to code signing, integrity and permissions.
Never mind admin permissions, you can't even change the netbeans.conf
on the macOS install without it being marked as broken. NBPackage
re-signs any JDK inside the app bundle with the same signature and
hardened runtime permissions as the IDE.
Not sure I understand... why would users build themselves an installer?
It's an option. In particular if you're a company, college, etc. with
a desire to bundle an alternative JDK to roll out. I used to
regularly build myself a deb to install rather than the old Linux nbi!
One of the things I'm working on with the community installer
migration at the moment is a GitHub build workflow for all the
packages. You could even fork that, change the JDK link, run it and
have your own installer in about 10min (unsigned obv unless set up!).
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org<ma...@netbeans.apache.org>
For additional commands, e-mail: dev-help@netbeans.apache.org<ma...@netbeans.apache.org>
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Neil C Smith <ne...@apache.org>.
On Fri, 21 Mar 2025 at 15:03, Eirik Bakke <eb...@ultorg.com.invalid> wrote:
> 2) is unnecessary - we can already build a Windows installer using NBPackage - the only thing stopping us switching a long time ago is something like 1).
>
> OK, very good. Is the thing it generates an InnoSetup EXE that does not by itself require Java?
Yes. Everything that NBPackage generates uses native tools and does
not require Java at install time - InnoSetup exe, macOS pkg, Linux
deb, rpm, or appimage.
A JDK runtime is also optional in all the package types. All the
other installers from ASF have been built with it for some time. The
launcher issues on Windows are why we've stuck with NBI to date. We
should fix them regardless because it would make the zip better.
There is a way to use the InnoSetup installer now by customizing the
shortcut to use netbeans --jdkhome "%JAVA_HOME%\" It's a bit clunky,
and requires the extra backslash as I noted earlier on this thread
because Windows decided that mixing path separators and escape
characters makes sense! :-)
> > installers without a runtime have other issues
>
> Even if netbeans64.exe is updated to prompt for a JDK folder?
Obviously a single, system installed JDK is less of a thing these
days. I don't think you can get an installer for Eclipse or IntelliJ
that doesn't bundle a runtime now. I have a whole bunch of JDKs on my
machine, some installed, some downloaded manually, or by NetBeans, or
by Gradle. I don't think having a system installed IDE relying on any
of these transient user space things makes sense, even if I regularly
test things using --jdkhome overrides. The default works out of the
box, is a known entity, and is not affected by anything else. Nor
does it affect anything else - the bundled JDK is an entirely private
part of the installed IDE (or RCP app).
There is an additional factor with macOS which might eventually be
seen elsewhere related to code signing, integrity and permissions.
Never mind admin permissions, you can't even change the netbeans.conf
on the macOS install without it being marked as broken. NBPackage
re-signs any JDK inside the app bundle with the same signature and
hardened runtime permissions as the IDE.
> Not sure I understand... why would users build themselves an installer?
It's an option. In particular if you're a company, college, etc. with
a desire to bundle an alternative JDK to roll out. I used to
regularly build myself a deb to install rather than the old Linux nbi!
One of the things I'm working on with the community installer
migration at the moment is a GitHub build workflow for all the
packages. You could even fork that, change the JDK link, run it and
have your own installer in about 10min (unsigned obv unless set up!).
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Eirik Bakke <eb...@ultorg.com.INVALID>.
1) would be great, as long as it works for the platform too, and would be a major benefit to the zip as well. You might not be the only person looking at launcher code right now, so some coordination of approach might be good.
Noted! I'll stay away from that piece of code for now, and follow the discussion on the mailing list.
2) is unnecessary - we can already build a Windows installer using NBPackage - the only thing stopping us switching a long time ago is something like 1).
OK, very good. Is the thing it generates an InnoSetup EXE that does not by itself require Java?
> Personally, I'm still in favour of dropping installers here, because of the overhead
Are you referring to the work added to the release process itself? Totally understand... and by the way, I'm extremely grateful for the recurring volunteer work you and others have done for that part of the project.
> installers without a runtime have other issues
Even if netbeans64.exe is updated to prompt for a JDK folder?
> I remain of the view that if you want choice of runtime, you use the zip or use the tools we already provide to build yourself a bespoke installer.
Not sure I understand... why would users build themselves an installer?
-- Eirik
From: Neil C Smith <ne...@apache.org>
Reply-To: "dev@netbeans.apache.org" <de...@netbeans.apache.org>
Date: Friday, March 21, 2025 at 10:21 AM
To: Eirik Bakke <eb...@ultorg.com>
Cc: "dev@netbeans.apache.org" <de...@netbeans.apache.org>
Subject: Re: Re : Re: heads up: windows installer/uninstaller issues
On Fri, 21 Mar 2025 at 14:02, Eirik Bakke <eb...@ultorg.com>> wrote:
Here's one idea for how to make an "official" Windows installer, i.e. an installer that is distributed as a convenience binary, officially from Apache NetBeans:
1) Improve the netbeans64.exe launcher so that when it starts and doesn't find the JDK, it prompts the user to select one with a file browser, and remembers the selection for the next time.
2) Package this into an MSI installer using the scripts at https://github.com/eirikbakke/netbeans-msi-example , with only minimal changes to fit into the existing GitHub Actions scripts on the main NetBeans repo.
Thoughts on this approach? (In case I decide to work on it.)
1) would be great, as long as it works for the platform too, and would
be a major benefit to the zip as well. You might not be the only
person looking at launcher code right now, so some coordination of
approach might be good.
2) is unnecessary - we can already build a Windows installer using
NBPackage - the only thing stopping us switching a long time ago is
something like 1).
Personally, I'm still in favour of dropping installers here, because
of the overhead and because installers without a runtime have other
issues. I remain of the view that if you want choice of runtime, you
use the zip or use the tools we already provide to build yourself a
bespoke installer.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org<ma...@netbeans.apache.org>
For additional commands, e-mail: dev-help@netbeans.apache.org<ma...@netbeans.apache.org>
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Neil C Smith <ne...@apache.org>.
On Fri, 21 Mar 2025 at 14:02, Eirik Bakke <eb...@ultorg.com> wrote:
> Here's one idea for how to make an "official" Windows installer, i.e. an installer that is distributed as a convenience binary, officially from Apache NetBeans:
>
> 1) Improve the netbeans64.exe launcher so that when it starts and doesn't find the JDK, it prompts the user to select one with a file browser, and remembers the selection for the next time.
>
> 2) Package this into an MSI installer using the scripts at https://github.com/eirikbakke/netbeans-msi-example , with only minimal changes to fit into the existing GitHub Actions scripts on the main NetBeans repo.
>
> Thoughts on this approach? (In case I decide to work on it.)
1) would be great, as long as it works for the platform too, and would
be a major benefit to the zip as well. You might not be the only
person looking at launcher code right now, so some coordination of
approach might be good.
2) is unnecessary - we can already build a Windows installer using
NBPackage - the only thing stopping us switching a long time ago is
something like 1).
Personally, I'm still in favour of dropping installers here, because
of the overhead and because installers without a runtime have other
issues. I remain of the view that if you want choice of runtime, you
use the zip or use the tools we already provide to build yourself a
bespoke installer.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Eirik Bakke <eb...@ultorg.com.INVALID>.
Here's one idea for how to make an "official" Windows installer, i.e. an installer that is distributed as a convenience binary, officially from Apache NetBeans:
1) Improve the netbeans64.exe launcher so that when it starts and doesn't find the JDK, it prompts the user to select one with a file browser, and remembers the selection for the next time.
2) Package this into an MSI installer using the scripts at https://github.com/eirikbakke/netbeans-msi-example , with only minimal changes to fit into the existing GitHub Actions scripts on the main NetBeans repo.
Thoughts on this approach? (In case I decide to work on it.)
-- Eirik
From: Michael Bien <mb...@gmail.com>
Reply-To: "dev@netbeans.apache.org" <de...@netbeans.apache.org>
Date: Tuesday, March 18, 2025 at 5:36 PM
To: "dev@netbeans.apache.org" <de...@netbeans.apache.org>, Neil C Smith <ne...@apache.org>
Subject: Re: Re : Re: heads up: windows installer/uninstaller issues
On 3/18/25 11:50, Neil C Smith wrote:
We should have resolved the issue of a new home for the community
installers, which should lead to a viable alternative for NB26.
that would be great news for windows users i think!
-mbien
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org<ma...@netbeans.apache.org>
For additional commands, e-mail: dev-help@netbeans.apache.org<ma...@netbeans.apache.org>
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org<ma...@netbeans.apache.org>
For additional commands, e-mail: dev-help@netbeans.apache.org<ma...@netbeans.apache.org>
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Michael Bien <mb...@gmail.com>.
On 3/18/25 11:50, Neil C Smith wrote:
> We should have resolved the issue of a new home for the community
> installers, which should lead to a viable alternative for NB26.
that would be great news for windows users i think!
-mbien
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Eirik Bakke <eb...@ultorg.com.INVALID>.
Well, if the launcher can’t find the JDK, then explaining to the user exactly how to fix the problem will still go a long way.
“Signage” like this has a huge effect on conversion funnels.
-- Eirik
From: Neil C Smith <ne...@apache.org>
Reply-To: "dev@netbeans.apache.org" <de...@netbeans.apache.org>
Date: Tuesday, March 18, 2025 at 12:47 PM
To: "dev@netbeans.apache.org" <de...@netbeans.apache.org>
Subject: Re: Re : Re: heads up: windows installer/uninstaller issues
On Tue, 18 Mar 2025 at 16:33, Eirik Bakke <eb...@ultorg.com.inva>lid> wrote:
For example, the netbeans64.exe launcher currently displays just an angry error icon with the message “Cannot find Java 1.8 or higher”. If we make this dialog into actual instructions for downloading Java, perhaps the entire problem is solved?
That's not the problem. See eg.
https://github.com/apache/netbeans/issues/8336 It doesn't matter if
you download a JDK, the launcher probably won't find it. There is a
legacy (and optional) reg key that might get it to work. Otherwise
you have to do
what NBI does, and hardcode jdkhome in the conf. Or hardcode it in a
shortcut.
There's some work needed on the IDE and platform launchers to get it
to do a better search. And decide what the search priority should be
too I guess, as I'd put JAVA_HOME ahead of the legacy key for a start.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org<ma...@netbeans.apache.org>
For additional commands, e-mail: dev-help@netbeans.apache.org<ma...@netbeans.apache.org>
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Neil C Smith <ne...@apache.org>.
On Tue, 18 Mar 2025 at 16:33, Eirik Bakke <eb...@ultorg.com.invalid> wrote:
> For example, the netbeans64.exe launcher currently displays just an angry error icon with the message “Cannot find Java 1.8 or higher”. If we make this dialog into actual instructions for downloading Java, perhaps the entire problem is solved?
That's not the problem. See eg.
https://github.com/apache/netbeans/issues/8336 It doesn't matter if
you download a JDK, the launcher probably won't find it. There is a
legacy (and optional) reg key that might get it to work. Otherwise
you have to do
what NBI does, and hardcode jdkhome in the conf. Or hardcode it in a
shortcut.
There's some work needed on the IDE and platform launchers to get it
to do a better search. And decide what the search priority should be
too I guess, as I'd put JAVA_HOME ahead of the legacy key for a start.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Eirik Bakke <eb...@ultorg.com.INVALID>.
> Neither InnoSetup or WiX in themselves get us around the current problems with shipping a JDK-less installer
I wonder if the solution is simply to improve the message that is shown by the netbeans launcher when it cannot find Java.
For example, the netbeans64.exe launcher currently displays just an angry error icon with the message “Cannot find Java 1.8 or higher”. If we make this dialog into actual instructions for downloading Java, perhaps the entire problem is solved?
It requires really minimal implementation… just use the “Information” icon instead of the “Error” icon in the dialog, and change the user interface string.
-- Eirik
From: Neil C Smith <ne...@apache.org>
Reply-To: "dev@netbeans.apache.org" <de...@netbeans.apache.org>
Date: Tuesday, March 18, 2025 at 6:54 AM
To: "dev@netbeans.apache.org" <de...@netbeans.apache.org>
Subject: Re: Re : Re: heads up: windows installer/uninstaller issues
On Mon, 17 Mar 2025 at 20:35, Eirik Bakke <eb...@ultorg.com.inva>lid> wrote:
Here’s a NetBeans-ified version of my MSI installer building scripts, with a README:
https://github.com/eirikbakke/netbeans-msi-example/
> It would help to see usage with a NetBeans structured application.
The buildmsi_ci.bat script just assumes you set a PAYLOAD_DIR that contains bin/netbeans64.exe at a minimum. If you have a NetBeans platform application you’d do some search-and-replace of “netbeans” with whatever the branding token of your application is.
Many thanks for sharing this. Really useful! I'll start taking a
look at adding support for WiX to NBPackage sometime after NB26. I
may look at WiX 5+ though, as this looks like it might simplify the
templating requirements. NBPackage will handle all the branding token
stuff automatically.
We should have resolved the issue of a new home for the community
installers, which should lead to a viable alternative for NB26. That
would stick with InnoSetup for now, though, as that has been widely
tested already.
Neither InnoSetup or WiX in themselves get us around the current
problems with shipping a JDK-less installer, or we'd have ditched NBI
earlier. Not that the way that NBI handles that is a good idea to
replicate!
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org<ma...@netbeans.apache.org>
For additional commands, e-mail: dev-help@netbeans.apache.org<ma...@netbeans.apache.org>
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Neil C Smith <ne...@apache.org>.
On Mon, 17 Mar 2025 at 20:35, Eirik Bakke <eb...@ultorg.com.invalid> wrote:
>
> Here’s a NetBeans-ified version of my MSI installer building scripts, with a README:
>
> https://github.com/eirikbakke/netbeans-msi-example/
>
> > It would help to see usage with a NetBeans structured application.
>
> The buildmsi_ci.bat script just assumes you set a PAYLOAD_DIR that contains bin/netbeans64.exe at a minimum. If you have a NetBeans platform application you’d do some search-and-replace of “netbeans” with whatever the branding token of your application is.
Many thanks for sharing this. Really useful! I'll start taking a
look at adding support for WiX to NBPackage sometime after NB26. I
may look at WiX 5+ though, as this looks like it might simplify the
templating requirements. NBPackage will handle all the branding token
stuff automatically.
We should have resolved the issue of a new home for the community
installers, which should lead to a viable alternative for NB26. That
would stick with InnoSetup for now, though, as that has been widely
tested already.
Neither InnoSetup or WiX in themselves get us around the current
problems with shipping a JDK-less installer, or we'd have ditched NBI
earlier. Not that the way that NBI handles that is a good idea to
replicate!
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Eirik Bakke <eb...@ultorg.com.INVALID>.
Here’s a NetBeans-ified version of my MSI installer building scripts, with a README:
https://github.com/eirikbakke/netbeans-msi-example/
> It would help to see usage with a NetBeans structured application.
The buildmsi_ci.bat script just assumes you set a PAYLOAD_DIR that contains bin/netbeans64.exe at a minimum. If you have a NetBeans platform application you’d do some search-and-replace of “netbeans” with whatever the branding token of your application is.
> Good to know. I was curious if the fact that the trusted signing certificate isn't extended validation caused any issues with defender.
No, no issues as far as I have seen. It seems Azure Trusted Signing is meant to be the way to avoid these Windows Defender warnings.
-- Eirik
From: Neil C Smith <ne...@apache.org>
Reply-To: "dev@netbeans.apache.org" <de...@netbeans.apache.org>
Date: Monday, March 17, 2025 at 10:07 AM
To: "dev@netbeans.apache.org" <de...@netbeans.apache.org>
Subject: Re: Re : Re: heads up: windows installer/uninstaller issues
Hi,
On Sat, 15 Mar 2025 at 03:03, Eirik Bakke <eb...@ultorg.com.inva>lid> wrote:
I need to stick with the build pipeline I already have (it was a big project that I was glad to be done with…), but I can share my WiX scripts if it’s helpful.
Sure, understood. It would be useful to see the WiX scripts if you're
happy to share. It would help to see usage with a NetBeans structured
application. And it would be good to ensure that even if you don't
migrate, NBPackage could cover all the options you require.
Azure Trusted Signing works great! It successfully prevented the Windows Defender warning from appearing, just like the Sectigo Extended Validation physical USB token I used before.
Good to know. I was curious if the fact that the trusted signing
certificate isn't extended validation caused any issues with defender.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org<ma...@netbeans.apache.org>
For additional commands, e-mail: dev-help@netbeans.apache.org<ma...@netbeans.apache.org>
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Neil C Smith <ne...@apache.org>.
Hi,
On Sat, 15 Mar 2025 at 03:03, Eirik Bakke <eb...@ultorg.com.invalid> wrote:
> I need to stick with the build pipeline I already have (it was a big project that I was glad to be done with…), but I can share my WiX scripts if it’s helpful.
Sure, understood. It would be useful to see the WiX scripts if you're
happy to share. It would help to see usage with a NetBeans structured
application. And it would be good to ensure that even if you don't
migrate, NBPackage could cover all the options you require.
> Azure Trusted Signing works great! It successfully prevented the Windows Defender warning from appearing, just like the Sectigo Extended Validation physical USB token I used before.
Good to know. I was curious if the fact that the trusted signing
certificate isn't extended validation caused any issues with defender.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Neil C Smith <ne...@apache.org>.
On Sat, 15 Mar 2025 at 03:03, Eirik Bakke <eb...@ultorg.com.invalid> wrote:
> > Exactly the switch we're looking at right now. Although I have some concerns about the difference in trust of the certificate. Are you using it now? How have you found it?
>
> Azure Trusted Signing works great! It successfully prevented the Windows Defender warning from appearing, just like the Sectigo Extended Validation physical USB token I used before. I just talked to someone else who has also recently switched from physical USB tokens to Azure Trusted Signing. It seems like it’s the way forward for signing on Windows.
>
> I followed the instructions on https://melatonin.dev/blog/code-signing-on-windows-with-azure-trusted-signing/ and then used the https://github.com/Azure/trusted-signing-action from a GitHub Actions script.
Well, looks like we won't be making that switch for the community
installers for NetBeans 26, and will continue with the physical token
approach for now.
Microsoft recently restricted Trusted Signing back to companies in the
US and Canada only -
https://techcommunity.microsoft.com/blog/microsoft-security-blog/trusted-signing-public-preview-update/4399713
Hopefully that will be updated again soon as they move this out of
preview. I wonder if the restrictions came back due to need to
address abuse - eg.
https://www.bleepingcomputer.com/news/security/microsoft-trusted-signing-service-abused-to-code-sign-malware/
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Eirik Bakke <eb...@ultorg.com.INVALID>.
I need to stick with the build pipeline I already have (it was a big project that I was glad to be done with…), but I can share my WiX scripts if it’s helpful.
> And then there’s the signing, which used to involve a $600 physical USB token, but which can now be done on GitHub Actions using Azure Trusted Signing.
> Exactly the switch we're looking at right now. Although I have some concerns about the difference in trust of the certificate. Are you using it now? How have you found it?
Azure Trusted Signing works great! It successfully prevented the Windows Defender warning from appearing, just like the Sectigo Extended Validation physical USB token I used before. I just talked to someone else who has also recently switched from physical USB tokens to Azure Trusted Signing. It seems like it’s the way forward for signing on Windows.
I followed the instructions on https://melatonin.dev/blog/code-signing-on-windows-with-azure-trusted-signing/ and then used the https://github.com/Azure/trusted-signing-action from a GitHub Actions script.
-- Eirik
From: Neil C Smith <ne...@apache.org>
Reply-To: "dev@netbeans.apache.org" <de...@netbeans.apache.org>
Date: Friday, March 14, 2025 at 4:48 PM
To: dev <de...@netbeans.apache.org>
Subject: Re: Re : Re: heads up: windows installer/uninstaller issues
On Fri, 14 Mar 2025, 20:13 Eirik Bakke, <eb...@ultorg.com.inva>lid> wrote:
I only know how to generate MSI files with the WiX toolset (
https://www.firegiant.com/wixtoolset/), which must run on Windows.
Yes, this is exactly what we want. NBPackage is designed to run with
platform-specific tools, just like JPackage.
The NBPackage tool builds an image of all files and configuration, then
executes the native build tool.
I was planning on looking at WiX sometimes soonish, but if anyone else
wants to get there first that'd be great!
And then there’s the signing, which used to involve a $600 physical USB
token, but which can now be done on GitHub Actions using Azure Trusted
Signing. I don’t think the dependencies on these Microsoft-centric tools
can be avoided.
Exactly the switch we're looking at right now. Although I have some
concerns about the difference in trust of the certificate. Are you using it
now? How have you found it?
Signing can be done cross platform with JSign afaik mind you.
Best wishes,
Neil
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Neil C Smith <ne...@apache.org>.
On Fri, 14 Mar 2025, 20:13 Eirik Bakke, <eb...@ultorg.com.invalid> wrote:
> I only know how to generate MSI files with the WiX toolset (
> https://www.firegiant.com/wixtoolset/), which must run on Windows.
Yes, this is exactly what we want. NBPackage is designed to run with
platform-specific tools, just like JPackage.
The NBPackage tool builds an image of all files and configuration, then
executes the native build tool.
I was planning on looking at WiX sometimes soonish, but if anyone else
wants to get there first that'd be great!
And then there’s the signing, which used to involve a $600 physical USB
> token, but which can now be done on GitHub Actions using Azure Trusted
> Signing. I don’t think the dependencies on these Microsoft-centric tools
> can be avoided.
>
Exactly the switch we're looking at right now. Although I have some
concerns about the difference in trust of the certificate. Are you using it
now? How have you found it?
Signing can be done cross platform with JSign afaik mind you.
Best wishes,
Neil
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Eirik Bakke <eb...@ultorg.com.INVALID>.
I only know how to generate MSI files with the WiX toolset (https://www.firegiant.com/wixtoolset/), which must run on Windows (according to its founder). And then there’s the signing, which used to involve a $600 physical USB token, but which can now be done on GitHub Actions using Azure Trusted Signing. I don’t think the dependencies on these Microsoft-centric tools can be avoided.
> This is also what the community installers do. It's not possible to distribute a JDK from ASF because of the OpenJDK license.
Yeah, I suspected. MSI might not be the best option in this case. The other installer tools are probably easier to customize e.g. if e.g. someone wanted to streamline the process of helping the user pick a JDK.
-- Eirik
From: Neil C Smith <ne...@apache.org>
Reply-To: "dev@netbeans.apache.org" <de...@netbeans.apache.org>
Date: Friday, March 14, 2025 at 2:14 PM
To: "dev@netbeans.apache.org" <de...@netbeans.apache.org>
Subject: Re: Re : Re: heads up: windows installer/uninstaller issues
On Fri, 14 Mar 2025 at 18:02, Eirik Bakke <eb...@ultorg.com.inva>lid> wrote:
My NetBeans Platform app uses an MSI installer on Windows, built and signed with GitHub actions scripts that I could share, if this would be an alternative for NetBeans.
I'd be more interested in seeing a contribution to NBPackage that
could build an MSI! Is that something you'd be interested in working
on?
NBPackage currently has an InnoSetup installer backend.
In my case the app redistributes a Zulu build of OpenJDK. Was this ever found to be a possibility for official Apache releases of NetBeans, or is it still always necessary for users to download the JDK on their own?
This is also what the community installers do. It's not possible to
distribute a JDK from ASF because of the OpenJDK license.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org<ma...@netbeans.apache.org>
For additional commands, e-mail: dev-help@netbeans.apache.org<ma...@netbeans.apache.org>
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Re : Re: heads up: windows installer/uninstaller issues
Posted by Neil C Smith <ne...@apache.org>.
On Fri, 14 Mar 2025 at 18:02, Eirik Bakke <eb...@ultorg.com.invalid> wrote:
> My NetBeans Platform app uses an MSI installer on Windows, built and signed with GitHub actions scripts that I could share, if this would be an alternative for NetBeans.
I'd be more interested in seeing a contribution to NBPackage that
could build an MSI! Is that something you'd be interested in working
on?
NBPackage currently has an InnoSetup installer backend.
> In my case the app redistributes a Zulu build of OpenJDK. Was this ever found to be a possibility for official Apache releases of NetBeans, or is it still always necessary for users to download the JDK on their own?
This is also what the community installers do. It's not possible to
distribute a JDK from ASF because of the OpenJDK license.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists