Removed old, now defunct, Mylyn Integration

[lkishalmi]

trafficstars

Well this PR removes the unmaintained Mylyn integration. The main reason is to remove some really old library dependencies as old Apache httpclient, Lang. there mostly were used by the Bugzilla integration.

Mylyn provided originally 3 kind of issue tracker integration:

1. JIRA: the plugin is not available on recent Update center, the old plugin is nowhere compatible with modern JIRA APIs
2. Bugzilla: Only tested with NetBeans Bugzilla Archive. Could connect, but cannot query issues any more.
3. Local Repository: That functionality still works, though I'd question it's usefulness.

@junichi11 had integrations for GitHub and Backlog. I do not know how well they would work as their last released ~5 years ago for NetBeans 8.2 and 8.1

I left the BugTracking module in. Though without providers it is not that useful. There might be additional external dependency modules orphaned by this change.

[mbien]

Always a bit sad to see features go, but this removes so many 15+ year old libs (xmlrpc, httpclient, lang) including unmaintained code that its ultimately the better option.

Bugzilla: Only tested with NetBeans Bugzilla Archive. Could connect, but cannot query issues any more.

The bugzilla integration would still work if you connect to a not read-only db. I believe I tested this with the firefox bugzilla back when I took a look at those dependencies. (although obviously not recommended since the client is 17 years old)

Removing this would leave NB with no task management plugins, so if someone tries to add a task repository, the services UI will throw an exception. We should probably open a notification instead if no task system impl is found.

java.lang.IllegalStateException: No data for the combo-box.
	at org.netbeans.modules.bugtracking.ui.selectors.RepositorySelectorBuilder.initializeCombo(RepositorySelectorBuilder.java:253)
	at org.netbeans.modules.bugtracking.ui.selectors.RepositorySelectorBuilder.getComboBox(RepositorySelectorBuilder.java:221)
	at org.netbeans.modules.bugtracking.ui.selectors.RepositorySelectorBuilder.createPanel(RepositorySelectorBuilder.java:297)
	at org.netbeans.modules.bugtracking.ui.selectors.RepositorySelectorBuilder$ValidatingDialogDescriptor.<init>(RepositorySelectorBuilder.java:353)
	at org.netbeans.modules.bugtracking.ui.selectors.RepositorySelectorBuilder.createDialogDescriptor(RepositorySelectorBuilder.java:346)
	at org.netbeans.modules.bugtracking.ui.selectors.SelectorPanel.create(SelectorPanel.java:45)
	at org.netbeans.modules.bugtracking.ui.selectors.RepositorySelector.create(RepositorySelector.java:52)
	at org.netbeans.modules.bugtracking.util.BugtrackingUtil.createRepository(BugtrackingUtil.java:52)
	at org.netbeans.modules.bugtracking.api.Util.createRepository(Util.java:162)
	at org.netbeans.modules.bugtracking.bridge.nodes.BugtrackingRootNode$1.actionPerformed(BugtrackingRootNode.java:90)
	at java.desktop/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1972)

regarding the test failures:

CV tests pass if AutoUpdate-Show-In-Client: true is set in harness/jellytools.platform/manifest.mf

[lkishalmi]

CV failed on bugtracking.common as that module got orphaned. After all I've removed that one as well. Could have played with the module load policies though, make the API public (same for bugtracking)...

Maybe implementing some provider not based on Mylyn could make up for the loss...

[lahodaj]

Unfortunate, but unless someone steps up and helps maintaining this, the removal is inevitable.

And if someone would want to restore this functionality later, they still can, the code is still in the history, and under AL.

[matthiasblaesing]

2. Bugzilla: Only tested with NetBeans Bugzilla Archive. Could connect, but cannot query issues any more.

This might not be a problem of the integration, but of the instance. Manual operation also does not seem to work:

• Call via browse fails: https://bz.apache.org/netbeans/buglist.cgi?product=java&component=Classfile&resolution=---
• Call via issue input fails: https://bz.apache.org/netbeans/buglist.cgi?quicksearch=4223

[eirikbakke]

If there are concerns about whether a particular feature is still being used or not (e.g. Local Repository), one strategy we could use is to first remove it from the UI, and then remove all the actual implementation code in a later release. That way, users have some time to give feedback--or not.

[mbien]

@matthiasblaesing connecting to non read-only instances does work - I tried that before but wouldn't recommend to toy with that too much due to the 17 year old http client artifact. Thats like surfing the web with internet explorer ~9~ 8.

[matthiasblaesing]

@mbien what is the attack vector you are assuming? (Edit: Browsers are a totally different beast, as they run a turing complete scripting language on the content they receive)

[mbien]

@matthiasblaesing most attacks are a chain of exploits. Any web connected component with open CVEs gives exploit toolkits more options. Being a missing link in the chain is just as bad as being the entry point.

edit: this reminded me to take a look at tomcat since it closed a CVE too edit2: https://github.com/apache/netbeans/pull/8400

[matthiasblaesing]

I will not fight for issue tracking integration and now think we should kill the integration:

• I think in many cases the issue integration moved from IDE to CI/CD environment/forge system, so integration is less important.
• I found at least one CVE, that warrants a quick removal
• Localtasks seems to be broken ( I can create a task, but not find it, local repository is not listed for finding or in "Task Repositories") so is not an argument.

[mbien]

Agreed. Today's code forges became all by-convention and don't really rely on tool integration. If you click on a #123 number referenced in a commit, NB (and many other code editors like zed) can open the right page in most cases - because it can guess what the upstream branch is and how the forge works (zero configuration). Closing tasks via commit is also a relict from pre-distributed VCS times. Tasks aren't done with a commit or push these days.

I tried to come up with ways to make the task system useful again (so that it would make me want to use it) but couldn't come up with something. (convenient ways to switch between PR branches, seeing comments inline etc would be all great but the modules here would also not help with those kind of features)

[mbien]

build is failing due to javadoc config, e.g: https://github.com/apache/netbeans/blob/68e420dcd08d0e1a3bb7fc1687dd0722881e9422/nbbuild/build.properties#L195 needs removal I think

[lkishalmi]

There are some references in a few look and feels an there is a part of bugtracking support in teams common as well.

[mbien]

we would have to find the places where tasks are used in UI and check that they don't throw exceptions. one I mentioned at https://github.com/apache/netbeans/pull/8396#issuecomment-2780671848

there is also the bottom part of the commit window of course:

[lkishalmi]

Yes, those are usually in the org.netbeans.modules.bugtracking.commons package.

[lkishalmi]

I'm going to split this one.