Please publish `org-netbeans-insane-hook.jar` to Maven Central

[basil]

Description

netbeans-13-bin.zip contains a JAR file at netbeans/harness/modules/ext/org-netbeans-insane-hook.jar. I cannot seem to find org-netbeans-insane-hook.jar anywhere on Maven Central. Please publish this JAR file to Maven Central.

See below for the motivation and reasoning behind this request.

Use case/motivation

The Jenkins project consumes org.netbeans.modules:org-netbeans-insane in jenkinsci/jenkins-test-harness. When upgrading from RELEASE126 to RELEASE130 in jenkinsci/jenkins-test-harness#397, we started getting the following error:

java.lang.NoClassDefFoundError: org/netbeans/insane/hook/MakeAccessible
	at org.netbeans.insane.impl.InsaneEngine.processClass(InsaneEngine.java:224)
	at org.netbeans.insane.impl.InsaneEngine.process(InsaneEngine.java:185)
	at org.netbeans.insane.impl.InsaneEngine.traverse(InsaneEngine.java:73)
	at org.netbeans.insane.impl.LiveEngine.traceImpl(LiveEngine.java:165)
	at org.netbeans.insane.impl.LiveEngine.trace(LiveEngine.java:143)
	at org.jvnet.hudson.test.MemoryAssert.fromRoots(MemoryAssert.java:300)
	at org.jvnet.hudson.test.MemoryAssert.assertGC(MemoryAssert.java:187)
	... 32 more
Caused by: java.lang.ClassNotFoundException: org.netbeans.insane.hook.MakeAccessible
	at java.net.URLClassLoader.findClass(URLClassLoader.java:387)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
	... 39 more

Looking into this further, I see that in order to adapt to 04ed090 from #3206, we will need to add --patch-module=java.base=org-netbeans-insane-hook.jar --add-exports=java.base/org.netbeans.insane.hook=ALL-UNNAMED to our test JVM arguments on Java 9 (and later) and -Xbootclasspath/p:org-netbeans-insane-hook.jar to our test JVM arguments on Java 8 (and below). One of the first problems I am having in doing so is that I cannot seem to find org-netbeans-insane-hook.jar anywhere on Maven Central.

I found it buried in netbeans-13-bin.zip, a 427 MiB .zip archive, but it is not practical to download and extract this during a Jenkins plugin build. Checking in org-netbeans-insane-hook.jar into Git is not practical either, as this JAR needs to be available when running tests from multiple Jenkins plugin repositories.

How should the Jenkins project proceed? I can think of one solution: for the NetBeans project to publish org-netbeans-insane-hook.jar to Maven Central. The Jenkins project could then fetch this artifact during our plugin builds and consume it using the test JVM arguments given above.

Related issues

See #3206 and JENKINS-67974.

CCing @JaroslavTulach as the author of the breaking change and @neilcsmith-net regarding release management.

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow the Apache Software Foundation's Code of Conduct

[jglick]

Since it is trivial

netbeans/harness/o.n.insane/hook/org/netbeans/insane/hook/MakeAccessible.java

Lines 27 to 29 in 30b1d7c

	public static void setAccessible(AccessibleObject obj, boolean accessible) {
	obj.setAccessible(accessible);
	}

we could just create a similar JAR ourselves I guess.

[basil]

Fine as a short-term workaround, but I think it would create a long-term maintenance burden on the Jenkins project to stay in sync.

[neilcsmith-net]

I'm not the best person to CC on this. Maybe @ebarboni has a thought?

[jglick]

a long-term maintenance burden on the Jenkins project to stay in sync

From looking at the contents I am guessing there is no reason for this class to ever be modified. I am not very familiar with JMS but I suppose this is simply a workaround for the way setAccessible calls are checked: a class loaded from java.base is considered trusted to use reflection without restriction.

[basil]

From looking at the contents I am guessing there is no reason for this class to ever be modified.

But keeping up with source modifications is only part of the maintenance burden of a fork; maintaining a build and release process is another part. Over time, that adds up, especially when you have a lot of tiny modules with only a few classes (as the Jenkins project does). So unless you are volunteering to maintain such a fork, I would prefer that the NetBeans project accommodate the original request.

Moreover, I think the request is reasonable: the NetBeans project publishes org.netbeans.modules:org-netbeans-insane to Maven Central, and in order for it to be consumable from Maven Central the transitive closure of its dependencies must also be available on Maven Central. org-netbeans-insane-hook.jar is a new direct dependency, so I think the NetBeans project ought to publish it on Maven Central.

[jglick]

What build and release process? We can just check in the tiny JAR to Git and be done. Nothing to maintain.

[basil]

As I wrote in the issue description:

Checking in org-netbeans-insane-hook.jar into Git is not practical either, as this JAR needs to be available when running tests from multiple Jenkins plugin repositories.

When running e.g. org.jenkinsci.plugins.workflow.libs.LibraryMemoryTest from a checkout of workflow-cps-global-lib-plugin (and we cannot assume a checkout of jenkins-test-harness in this scenario!), we need to be able to pass in some path to org-netbeans-insane-hook.jar to the test JVM arguments. I do not think it is practical to force all consumers of jenkins-test-harness to check in a copy of org-netbeans-insane-hook.jar to their own repository.

[jglick]

Check it in to jenkins-test-harness/src/main/resources/. jenkins-test-harness.jar would just contain org-netbeans-insane-hook.jar as a nested entry, unpacking it to a temp dir whenever INSANE is needed. At least that would work for RealJenkinsRule which explicitly controls the launch of the test process. For other cases indeed we would need to customize Surefire booter arguments somehow. I am not really sure offhand how you would propose to do that, especially if you want to do so both for Java 8 and 11, but if it is helpful to grab org-netbeans-insane-hook.jar as a Maven artifact (for use from dependency:copy?) we can easily deploy it to our Artifactory. Again there is no need to ever repeat this process since it should never change.

[basil]

Check it in to jenkins-test-harness/src/main/resources/. jenkins-test-harness.jar would just contain org-netbeans-insane-hook.jar as a nested entry, unpacking it to a temp dir whenever INSANE is needed. At least that would work for RealJenkinsRule which explicitly controls the launch of the test process.

Whatever you are suggesting here, it is for some hypothetical use case, as there are no existing RealJenkinsRule-based tests that use org.netbeans.modules:org-netbeans-insane via org.jvnet.hudson.test.MemoryAssert#assertGC.

For other cases

You mean all existing use cases.

we can easily deploy it to our Artifactory.

Easily only in the opinion of some, Jesse. To which local repository in Artifactory should it be uploaded? Who should have permissions to upload it to that local repository? Who should be responsible for it if it becomes a liability in the future (e.g., if some security-conscious organization objects to some random JAR whose place in the supply chain cannot be established)? Please don't answer these questions, as they are rhetorical. My point is that this is not necessarily a simple matter, and I do not want to be responsible for it personally. So unless you are volunteering to deploy such an artifact to the Jenkins Artifactory server and to be responsible for it long-term, I continue to request that the NetBeans project publish this JAR to Maven Central. And for the reasons given in the issue description and #3743 (comment) I think this request is perfectly reasonable.

[jglick]

unless you are volunteering to deploy such an artifact to the Jenkins Artifactory server

I hope I lack permissions personally, but it could be filed as a helpdesk ticket.

It is also straightforward to configure maven-install-plugin to treat a specified local file (committed JAR) as an attached artifact, so every jenkins-test-harness deployment would also deploy this hook JAR with a special classifier.

To be clear, I am certainly not objecting if someone from the NB project cares to take the time to resolve this ticket the “right” way. I am just saying there is no reason to wait for that to happen merely to be able to receive INSANE updates.

[basil]

I hope I lack permissions personally, but it could be filed as a helpdesk ticket.

I hope I lack permissions personally for the same reasons as you (whatever those reasons may be), and I intend not to file a helpdesk ticket to ensure that this continues.

It is also straightforward to configure maven-install-plugin to treat a specified local file (committed JAR) as an attached artifact, so every jenkins-test-harness deployment would also deploy this hook JAR with a special classifier.

You must have a different definition of "straightforward" than I do. The above sounds like a convoluted workaround to me, and I would rather avoid implementing and maintaining it.

To be clear, I am certainly not objecting if someone from the NB project cares to take the time to resolve this ticket the “right” way.

I am glad you do not object, though I did not solicit your opinion in the first place.

I am just saying there is no reason to wait for that to happen merely to be able to receive INSANE updates.

There is a reason to wait: not wanting to design, implement, operate, or maintain a non-trivial workaround for an issue not caused by the Jenkins project, as part of a broader effort that is already large enough in scope without having to take this particular issue into account.

[ebarboni]

Hi sorry you are too fast for me, I know we had issue for 13 on some maven related dependencies but they were obvious to fix as pom leads to non existing artefact.

For hook and I guess other jar that are put in ext folder the nb-repository plugin is not able to retrieve or make a reference this need investigation, I'm not completly aware on how it works on this point. Home you may have a workaround.

[jlahoda]

I think it is reasonable to make sure the hook is published. I'll try to investigate a bit as well.
I wonder if you can stay on 12.6 for now? Also, I wonder on which JDKs you test, as insane from 12.6 can't reliably traverse the object hierarchy on JDK 17, I think?
Thanks.