Updating org.netbeans.modules.gototest/ org.netbeans.modules.gsf.codecoverage and org.netbeans.modules.gsf.testrunner as public packages

[albilu]

Fix for #6871 Making gototest/gsf.codecoverage/gsf.testrunner public APIs

[sdedic]

Note that from a 'common' sense review (I've never worked with that API), the quality is ... strange. Take for example this: https://github.com/apache/netbeans/blob/master/ide/gsf.testrunner/src/org/netbeans/modules/gsf/testrunner/plugin/CommonTestUtilProvider.java#L31 which is not documented at all. The documentation is perhaps here: https://github.com/apache/netbeans/blob/master/java/java.testrunner/src/org/netbeans/modules/java/testrunner/CommonTestUtil.java#L286

• there's a fixed set of keys. The set is NOT extensible from other modules.
• each key has its own data type, which is specified by the documentation

... that would normally lead to a final settings bean class or r/o class with a builder rather than untyped map.

Nobody cared that much since it is a friend API with a limited impact, but if we ever make it public, it has to be maintained forever. Going public is the last chance the API can be cleaned up and made future-changes-compatible. It's not that just a "flag is flipped".

[lahodaj]

I concur with @dbalek and @sdedic - while exposing a package to be public is easy, we then need to take care of it as an API for a long time/forever, which is difficult code that was originally arbitrary implementation code.

I would suggest to first find out and describe what are the usecases/what you need, and then we can talk about how to extend the API to support that usecases. And do the API extension in a way that can be supported in long term.

Thanks.

[albilu]

Thanks all: @neilcsmith-net @sdedic @dbalek for your feedbacks and sorry for the late response.

However, this PR doesn't make that change?! What are you trying to achieve and why?

I am trying to make these API public so that plugin developpers are no longer restricted by the friend restriction: meaning avoid to have to provide a new build of a plugin depending on these API for each Netbeans release.

From this DEV thread https://lists.apache.org/thread/rdwh4vh07zxgbxyjfzfhxd8yjk7o23wv, Laszlo Kishalmi seemed ok with these API going public. That's why i made the PR.

I would suggest to first find out and describe what are the usecases/what you need, and then we can talk about how to extend the API to support that usecases. And do the API extension in a way that can be supported in long term.

Here are what i need:

• Avoid to have to provide a new build of a plugin (in this case https://github.com/albilu/netbeansPython) for each Netbeans release. It is very annoying.
• More generally the usecase is to ease Language support plugin development for all Plugin developpers.

@lahodaj : I understand the concerns from everyone. I will be glad for any other solution to achieve this