Download launcher binaries as produced by #8756

[jtulach]

• Post merge actions of Make sure netbeans in embedded terminal means itself #8756
• Uses the netbeans.exe and netbeans64.exe binaries produced by the merge commit 8e2bc77 github action
  • right now the downloading happens from dev area
• wait for CI build to finish
  • do testing on Windows - local build works fine with Cygwin
  • call for a vote like in this case, if it passes
  • release the bits
  • update the URL to release area
  • merge

[jtulach]

@matthiasblaesing has discovered ideopen functionality after #8756 was merged. I believe existence of such a functionality doesn't make #8756 obsolete and thus I am proceeding as agreed to. I'd like to:

• make sure terminal integration on Windows works without cygwin
• be able to open files in any terminal like cmd or Windows powershell, not just cygwin
• being able to use other CLI arguments (--close-group, --open-group, LSP options, etc.)

Those additional goals can be achieved most easily by making sure netbeans means NetBeans in the terminal. Thus I'd like to proceed with the originally agreed plan.

[mbien]

after #8756 was merged. I believe existence of such a functionality doesn't make #8756 obsolete and thus I am proceeding as agreed to

I think its worth pointing out that the PR was merged without approval which would usually indicate integration readiness or some kind of consensus between the participating reviewers.

I still think it would have been good to explore some (pure java) init-profile based solutions which are common for situations like this. As mentioned before, they are the standard way how to initialize a terminal and more flexible without having to modify the user's PATH variable.

$ cat nb_profile 
echo "Welcome to the NB Terminal"
alias nb='echo blabla...'

$ bash --init-file <(cat /etc/profile ~/.bashrc nb_profile)
Welcome to the NB Terminal
$ nb
blabla...

More flexibility provided by profiles might be needed, since users will soon ask why does javac not point to the default JDK and mvn doesn't run the bundled maven etc. If PATH concatenation is needed after all, the nb_profile file would be able to do that too as opt-in and it would be fully transparent and configurable by the user.

While I don't like how this was handled I don't care enough to veto this, so I leave it at -0.9 and won't participate in the maintenance of this feature. Removing myself from the reviewers list.

[matthiasblaesing]

I think its worth pointing out that the PR was merged without approval which would usually indicate integration readiness or some kind of consensus between the participating reviewers.

While I think a simpler solution would be possible, we are not in pre-merge approval mode.

[mbien]

While I think a simpler solution would be possible, we are not in pre-merge approval mode.

I didn't try to say that we would be. (We would have enforced it via github pre-merge checks otherwise) I have merged trivial changes before too without review to avoid notification noise. But I don't think a change which requires platform dependent testing and a launcher release would fall into that category.

[jtulach]

change which requires platform dependent testing and a launcher release

• exactly because of the platform dependency there was a lot of testing done by Matthias and me
  • all bugs were addressed
• moreover it was decided to not hurry with this change for NetBeans 28, but wait for NetBeans 29
  • next three months will give us enough time to test the change deeply
• to test we need to update the windows launchers as this PR does
• I suggest to stick to the agreed plan
  • a plan that nobody objected to by the time I merged Make sure netbeans in embedded terminal means itself #8756
  • let's get the plan done - e.g.:
  • vote on the launchers and integrate this PR
• the sooner we integrate, the sooner we all participate in testing

[jtulach]

The build seems to be green. Is there a .zip file to test? I built one manually myself, but having a .zip built by CI somewhere would increase reproducibility.

[matthiasblaesing]

@jtulach the builds for the native bits are triggered by changes to the corresponding paths:

netbeans/.github/workflows/native-binary-build-launcher.yml

Lines 34 to 48 in d753c90

	push:
	# Triggers the workflow on push or pull request events but only for
	# relevant paths
	paths:
	- .github/workflows/native-binary-build-launcher.y*
	- platform/o.n.bootstrap/launcher/windows/**
	- harness/apisupport.harness/windows-launcher-src/**
	- nb/ide.launcher/windows/**
	pull_request:
	paths:
	- .github/workflows/native-binary-build-launcher.y*
	- platform/o.n.bootstrap/launcher/windows/**
	- harness/apisupport.harness/windows-launcher-src/**
	- nb/ide.launcher/windows/**

You can trigger the build from the "Actions" tab of the repository. Select "NetBeans Native Launcher" and then "Run workflow". You can run from master as that hold the latest changes to the launcher.

Or easier: go to checks page of the original PR https://github.com/apache/netbeans/pull/8756/checks, Select "Make sure netbeans in embedded terminal means itself" and you are redirected to the result of that run: https://github.com/apache/netbeans/actions/runs/18612911215. There are your binaries.