Please create a new thread for this question. >From my perspective, I have multiple versions of Amazon Corretto installed locally, and I've installed them via the installer Amazon provides for each JDK I need. To switch between different JDK's I use jenv[1]. Outside of that nothing needs to be touched.
I also installed SVN via homebrew, and I have no issues with Netbeans and SVN working together. [1]: https://www.jenv.be On Thu, 24 Mar 2022 at 19:13, Mark Eggers <its_toas...@yahoo.com.invalid> wrote: > Hi, > > First of all, I don't have a Macintosh. However, I'm trying to support a > person who does. This person is primarily a front end developer and uses > a different IDE, but is slowly being brought into the server-side world. > > After looking at the convoluted ways various Java providers manage > multiple JDK versions, I prompted this person to install Java similar to > how I install it on a Linux platform. > > 1. Create an /opt/Java directory > 2. Install various Java versions from tar.gz files in that directory > 3. Make soft links to generic directories, such as jre11, jdk11, etc. > 4. Add the bin paths to the user's path > 5. Add JAVA_HOME, JRE_HOME to the user's environment variables > > I have then written a script that will conveniently switch paths, > JAVA_HOME, and JRE_HOME based on a user-supplied argument. > > In a terminal session, all of this works as expected. > > Using the NetBeans installer only worked because the user already had a > very old version of Java installed in /Library/Java/JavaVirtualMachines. > The netbeans.conf file had to be edited in order to point to the correct > JDK. > > The next of the problem is that NetBeans (at least from the installer, > have not tried the zip or tar.gz), does not seem to be aware of the > user's PATH environment variable. This was discovered as follows: > > 1. User has installed svn in /usr/local/bin > 2. User checks out Maven project on the command line > 3. User changes to that directory, and mvn package is successful > 4. During the build (validate), the buildnumber MOJO executes the > following: > > /bin/sh -c cd '/Users/auser/NetBeansProjects/aproject' && 'svn' > '--username' > 'auser' '--password' '*****' '--no-auth-cache' '--non-interactive' > 'info' > > This all works from the command line. > > In NetBeans, the svn command in the build fails with: > > Cannot run program "svn" (in directory > "/Users/auser/NetBeansProjects/aproject"): error=2, No such file or > directory > > The exact same environment works as expected on an Ubuntu 20.04 system > (ksh, .kshenv, NetBeans 13 installed via snap). Subversion is installed > in /usr/bin, and not /usr/local/bin as it is on the person's Macintosh. > > Without .kshenv, the user's PATH does not include /usr/local/bin. > > I think that I could solve the above problem with a soft link from > /usr/local/bin/svn* to /usr/bin, and possibly the Java issues with soft > links as well into /Library/Java/JavaVirtualMachines (for the installer). > > However, not having a Macintosh, I'm a bit reluctant to instruct the > user to further mangle the machine. > > What is the Apple-approved way of handling all of this? > > I will probably get a Macintosh soon just to be able to hack around with > this. > > Thanks for any ideas. > > . . . just my two cents > /mde/ > > On 3/24/2022 11:22 AM, Alex Lewis wrote: > > Hi, > > > > Just to offer an opinion of an average netbeans user regarding Netbeans > and > > sdkman... As of Netbeans 12.1, sdkman is explicitly supported for > detecting > > available JVMs. In my opinion it is an odd inconsistency for the main > > application to support sdkman but not the installer. Besides that and as > > far as I know, sdkman is a widely used tool for managing Java versions on > > macos, even with its avoidance of java_home. In which case, not > supporting > > it in the installer impacts some amount of a large user base. By > > not supporting sdkman in the installer it means an additional > complication > > at the very first step in using Netbeans and that to me feels > unfortunate. > > If sdkman was an esoteric tool used by a small minority then I could > > understand any reluctance to put in the effort but, I have the impression > > that sdkman's user base would be large enough to warrant the effort. I > > obviously can't quantify that and I may be totally wrong about > > its popularity, if I am then I apologise. I just think that if it was > > important enough to include in the main application, doesn't that make it > > important enough to include support in the installer? > > > > The blame may be on sdkman but, as a user I have not yet suffered because > > of it, it's only when I try to install Netbeans that I run into an issue. > > If that's true for a significant volume of other users then I suspect > > people will believe the blame lies with Netbeans, regardless of what > might > > be the truth. > > > > I'm happy to install a java version outside of sdkman in order to install > > Netbeans. I can even remove it after Netbeans is installed, which again > > points to only the installer needing Java to be in > > /Library/Java/JavaVirtualMachines. For others it might be enough for them > > to just give up on Netbeans and not bother, which would be a shame for > > Netbeans to lose (potential) users that way. > > > > I realise the answer may be "We're happy to take your contribution to the > > installer to add support for sdkman", and I understand why that is the > > case. I will certainly take a look at the installer to see if there's > even > > a chance I could contribute something even though native macos > development > > is not my forte but, I hope that sdkman support could be considered > outside > > of what I may or may not be able to contribute. > > > > I'm a very happy user of Netbeans and it's clear to see Netbeans get > better > > each and every version. I'd like to say a huge thank you to the team for > > the great work. > > > > Cheers > > > > > > > > On Tue, 22 Mar 2022 at 20:49, Scott Palmer <swpal...@gmail.com> wrote: > > > >> JDKs installed by SDKMAN don’t work with /usr/libexec/java_home. That’s > >> why I believe SDKMAN should not be used for Java on macOS, it doesn’t > >> integrate properly. (I brought this up to SDKMAN team and they don’t > want > >> to write any files outside of their controlled space. I get it, but the > >> user suffers as a result.) > >> > >> You might be able to work around it by sym-linking the SDKMAN installed > >> JDK into the correct location at /Libraries/Java/JavaVirtualMachines - > but > >> if you have to manage it yourself, what is SDKMAN doing for you? > >> > >> Scott > >> > >>> On Mar 22, 2022, at 1:15 PM, John Mc <mcdonnell.j...@gmail.com> wrote: > >>> > >>> +1 (binding) > >>> > >>> Vote Closed, I will tally up the votes later and move the artefacts > over. > >>> > >>> @Djamel TORCHE <djamel.tor...@gmail.com> Sorry just seeing this now. > >> What > >>> output do you get when you run this in your terminal > >> "/usr/libexec/java_home" > >>> That's how the installer verifies Java exists. > >>> > >>> Maybe for NB14 I might do an RC for the macOS installer to help verify > no > >>> late issues in future. > >>> > >>> John > >>> > >>>> On Tue, 22 Mar 2022 at 14:12, Neil C Smith <neilcsm...@apache.org> > >> wrote: > >>>> > >>>> +1 (binding) > >>>> > >>>> Checksum and signature checked. > >>>> Installed and ran successfully. > >>>> Checked module versions match git hash. > >>>> > >>>> JDK 17 Temurin x86_64 running on M1 macOS 12.2.1 > >>>> > >>>> Thanks John!!! > >>>> > >>>> Best wishes, > >>>> > >>>> Neil > >>>> > >>>>> On Sat, 19 Mar 2022 at 10:11, John Mc <mcdonnell.j...@gmail.com> > >> wrote: > >>>>> > >>>>> This has been a lot longer than I wanted as I got caught up with > work, > >>>> but > >>>>> here is the updated macOS installer for Apache NetBeans 13. > >>>>> > >>>>> Primary voting artefact : > >>>>> > >>>> > >> > https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/13/Apache-NetBeans-13-bin-macosx.dmg > >>>>> > >>>>> SHA512 checksum : > >>>>> > >>>> > >> > https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/13/Apache-NetBeans-13-bin-macosx.dmg.sha512 > >>>>> > >>>>> > >>>> > >> > 68cd93b697b8fa02013d4ab69f773a93c3c42f92498578470af6d808179d292649b85bdb946a9bc75d9cc94aba3d4c8e0d0a3eb3fee565ab390810ad7b609b49 > >>>>> Apache-NetBeans-13-bin-macosx.dmg > >>>>> > >>>>> KEYS file : > >>>>> https://dist.apache.org/repos/dist/release/netbeans/KEYS > >>>>> > >>>>> PGP signature file : > >>>>> > >>>> > >> > https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/13/Apache-NetBeans-13-bin-macosx.dmg.asc > >>>>> > >>>>> Built locally using the artefacts found in the Jenkins job: > >>>>> > >>>> > >> > https://ci-builds.apache.org/job/Netbeans/job/netbeans-TLP/job/netbeans/job/release130/20/ > >>>>> > >>>>> NOTE: The distpreparation artefact from this Jenkins job was replaced > >>>> with: > >>>>> > >>>> > >> > https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/13/distpreparation.zip > >>>>> The changes can be compared against the PR: > >>>>> https://github.com/apache/netbeans/pull/3699 > >>>>> > >>>>> This vote is going to be open at least 72 hours, vote with +1, 0, and > >>>>> -1 as usual. Please mark your vote with (binding) if you're an Apache > >>>>> NetBeans PMC member. > >>>>> > >>>>> This vote is dependent on the main Apache NetBeans 13 release vote > >>>> passing. > >>>>> > >>>>> Regards > >>>>> > >>>>> John >
