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.
Two option for nbi removal from jenkins build No more installer: https://github.com/apache/netbeans-jenkins-lib/pull/118 Only the linux nbpackaged one https://github.com/apache/netbeans-jenkins-lib/pull/117 --- To me we need to remove (or move to another repo for reference) nbi folder and module from code base so we do not release it anymore. If it's only deprecated will still land in the zip and be used for build mess. We have contrib/rust/cpp folders in the code base Just for having the scope of what needs to me cleanup (clusters codebase wide, not infra): (draft PR for nbi removal https://github.com/apache/netbeans/pull/8283 ) Remove to harness module related to nbi + apisupport installer + adjust apisupport.kit and we have a first step. -- Nbm installer target could use nbpacker as "harness" to kind of mitigate the transition for some cases. Wizard should also be updated to alter deployment profile in mavenized project. Best Regards Eric -----Message d'origine----- De : Neil C Smith <neilcsm...@apache.org> Envoyé : vendredi 28 février 2025 11:12 À : dev@netbeans.apache.org Objet : Re: Re : Re: heads up: windows installer/uninstaller issues On Fri, 28 Feb 2025 at 09:11, Michael Bien <mbie...@gmail.com> wrote: > On 27.02.25 11:49, Neil C Smith wrote: > > 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. > > I don't mind either way. I think both approaches are fine, while the > all-in-one bundle with latest JDK is certainly the most convenient option for > users. To be clear, that point has nothing to do with which approach either of us thinks is fine or most convenient to users. It's down to what Apple will allow to run or pass notarization, and so actually be usable by users. The code is deep signed by NBPackage (including all the native libs, even those in JARs) with the entitlements that the application requires. https://developer.apple.com/documentation/security/hardened-runtime Do anything not allowed by the permissions and the application is forcefully terminated. The default permission set for NBPackage does include https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.cs.disable-library-validation OK, for now, although with some caveats. Bundling a JDK using NBPackage will re-sign the JDK with the same Team ID and entitlements as the rest of the application. That is still the preferable situation IMO. macOS isn't the only OS moving in this direction. Personally I think if you want to use a JDK of your choice, you use the zip and you link it up yourself, if you want a package then it should be self contained. For me, that includes the DEB and RPM, because distro JDK packages can sometimes be "interesting"! Better than they were, mind you - I remember an early distro OpenJDK that had multiple concurrent EDTs. :-) 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 --------------------------------------------------------------------- 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
