Java Platform Libraries: Support source archives with multiple modules

[matthiasblaesing]

The OpenJFX SDK and OpenJDK itself provide src.zip files, where the source is not located at the toplevel directory, but an intermediate level with one folder per module is used.

Closes: #7888

[matthiasblaesing]

This was successfully tested, so I intent to merge this sometime next week.

[mbien]

you don't want to target delivery for smaller fixes like this? We still at rc 1 I believe.

[matthiasblaesing]

@mbien I still think, NB would be better served with quicker releases, so I try to limit changes to delivery to a minimum. Anyway, I rebased my change onto delivery, will give it a quick smoketest and update this.

[matthiasblaesing]

Rebased and retargeted onto/to delivery. Adjusted milestone accordingly.

[mbien]

I still think, NB would be better served with quicker releases, so I try to limit changes to delivery to a minimum.

will test and review this later so it won't slow the release train down.

I personally think that small fixes are ok during stabilization phase if we can say with some confidence that they are low risk.

[mbien]

makes sense. Created an Ant Library from the JavaFX 23 gluon SDK and the sources were resolved.

This code path runs only for ant projects, right (e.g tools -> libraries)? (the "attach sources" button on the editor javap preview does seem to work in NB 23 maven projects already - tried with zulu JavaFX JDK after removing its sources first)

Wondering if we should rename Tools -> Libraries into Ant Libraries at some point?

[mbien]

restarting CI with build-tools job enabled for more ant coverage

[neilcsmith-net]

I personally think that small fixes are ok during stabilization phase if we can say with some confidence that they are low risk.

@matthiasblaesing small fixes are desirable. The release process is time-based and small fix PRs have no effect on how quickly the release happens*. See https://cwiki.apache.org/confluence/display/NETBEANS/Pull+requests+for+delivery

* assuming that they don't need to be reverted and that the RCs are happening on schedule - we should be heading to RC3 this week already.

[mbien]

The release process is time-based and small fix PRs have no effect on how quickly the release happens*

@neilcsmith-net they can delay things though if a release manager sees PRs which are not reviewed targeting delivery. So i think it is a good idea to try to get it reviewed quickly too.

But given the current situation where RCs are delayed due to availability reasons of the release team (i guess), we may as well use the time to add more (reviewed) PRs before RC 2 is built.

[neilcsmith-net]

they can delay things though if a release manager sees PRs which are not reviewed targeting delivery

@mbien not as originally intended. RCs are meant to be weekly, and the cut-off should be clear and stuck to. PRs to delivery that have not passed review should miss the cut, not be waited for (with discretion for high priority things occasionally).