Remove unused/deprecated openide.options module

[mbien]

• module isn't used by NB itself and was already deprecated before NB was donated to apache (19y ago)
• uses java.beans.beancontext which is deprecated-for-removal since JDK 23
• it is still shipped in the zip and maven artifacts generating warnings
• even though its not in class path at runtime, it is still hooked into the test class path across the project. Shrinking cp size helps to avoid issues like 15cbc0a

meta issue #8256

[mbien]

had to update the code in nbbuild/antsrc/org/netbeans/nbbuild/SetApidocClustersConfig.java since it expected an non-empty list

[BradWalker]

Looks good. Maybe duplicate the title into the body so that it's not empty?

[jtulach]

• Keep the module for backward compatibility reasons
• at least that's what I'd do to follow the original NetBeans Platform compatibility visions.
• it just lies around causing no harm
• 3rd party applications can get it from Maven central
• there is (almost) no cost associated to the module being around

[neilcsmith-net]

• Keep the module for backward compatibility reasons
• at least that's what I'd do to follow the original NetBeans Platform compatibility visions.
• it just lies around causing no harm

@jtulach full backwards compatibility is a nice ideal, but it's certainly not been a reality with the platform in at least the 15+ years I've worked with it. It should not be used to make things unnecessarily more difficult. This is going to come up more and more over the coming year or two as the ecosystem we rely on moves on while various features of the IDE and platform are lying around without getting necessary updates. It's not true to say this just causes no harm - see the linked issues eg. #8256 If you wish to propose changes to this module to meet those issues instead, then feel free if you have the time and inclination - because I'm not sure anyone else does.

[mbien]

• Keep the module for backward compatibility reasons
• at least that's what I'd do to follow the original NetBeans Platform compatibility visions.
• it just lies around causing no harm
• 3rd party applications can get it from Maven central

older versions up to NB 27 of this module are on maven central and the deprecation happened 19y ago with the commit msg: "Marking module deprecated to remind people not to use it.". Stopping to release it is just the next step to remind people to not use it.

• there is (almost) no cost associated to the module being around

I disagree. Dead code has cumulative maintenance costs associated with it. Security team has to respond to exploit notifications and javac, code scanners and vulnerability scanners produce extra noise which is in the way every time a real issue is investigated.

And as mentioned, the module uses JDK API which is deprecated for removal. We shouldn't wait for things to break before we have to react in a hurry, we pushed our luck with the security manager removal once, we don't have to do this every time.

[mbien]

rebasing and running all tests before integration.

edit: all green except javadoc link checker, will try to find the reference I overlooked

[mbien]

all green, made only minor updates to resolve the javadoc link check problems since approval.

Checked the thread on the private list and it had no new comments regarding this PR -> merging.

thanks for the reviews!