Hi, On Thu, 27 Feb 2025 at 04:12, Michael Bien <mbie...@gmail.com> wrote: > I can't really help there much, but we have community packages linked which > are able to reliably install NB+Runtime JDK on windows. So this is > technically a solved problem (for now) IMO ... We cant rely on the existence > of community packages since they may disappear.
There will be no community installers from Codelerity after NetBeans 25. There is some discussion ongoing about whether they move somewhere else. > We can't release a JDK bundle I believe. But as long PMCs (in the sense of > community members we trust) provide those outside of apache - we can > certainly continue linking to them as trusted downstream package offering > below the main zip release artifact. Well, we can't distribute anything that is GPL without CPE, which takes HotSpot out of the equation. That might be problematic! :-) Incidentally, one reason NBPackage was written the way it is is so that you can binary diff the installed files with the binary release zip. Of course, doesn't tell you whether the installer itself can be trusted, only its output. > mac: > > - mac is covered by our .pkg artifact, right? We would need another PMC member to take this on. This is partly related to the above, and partly that it happens that the certificate has now expired, which is the best time to pass this over. Personally, I have doubts that a .pkg without JDK is the right approach anyway. It is better IMO that a .pkg contains a JDK that is signed and notarized as one artefact. > >> On 26.02.25 16:28, Eric Barboni wrote: > > Removing nbi windows trying to get wine+iscc in the ci jenkins to align > > with the two others debian/rpm already package could be an option too. > > Was looking for lightweight alternative with nsis as Apache Directory > > Studio had something working with that. Could be doable but macos still > > behind for that. Even if we keep producing a macOS artefact, it will always have to be built locally on a RM's machine. I do not see the benefit to putting a lot of time into getting a Windows installer to build on Jenkins. The RM already has to download the installer to sign and test it on Windows. The moment it's signed you lose the ability to verify against the upstream file (unless we go the detached signature for vote route). Building the installer locally is a 10min job on top (unlike the extended macOS process). Getting the InnoSetup installer to "work" in the short term could be a one line template override, as outlined above, to set --jdkhome to %JAVA_HOME% in the shortcut. It's not ideal - the real fix is to get the Windows launchers working to find the JDK again. That way the zip and the platform is improved too! > > We need also to tell/tools user of nbm-plugin / ant on how to migrate to > > nbpackage > > doc would be great yeah ;) Extra documentation is always good, but it's not like there's none! ;-) Build zip, follow https://github.com/apache/netbeans-nbpackage/blob/master/README.md Should we enhance the IDE or plugins with ability to run NBPackage? It's doable, but there is also a fundamental shift in that it's OS specific. Best wishes, Neil --------------------------------------------------------------------- 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
