On 6/20/26 14:24, Matthias Bläsing wrote:
Greetings, my understanding of the OSGI integration of NetBeans is, that both Apache Felix and a patched version of Eclipse Equinox (Netbinox) can be currently used. By default Netbinox is used. The reason as I understood is that some of the bundled eclipse modules relied on special behavior of Equinox. While Netbinox works I think it has become a problem as it is not maintained. We use a patched version of Equinox: https://github.com/apache/netbeans/blob/f88a2a3dab55dc731996f4f9625065e9234803d6/platform/netbinox/external/M20140115-0800.patch and that patch applies to equinox as of 12 years ago. (the name of the patch file refers to this tag): https://github.com/eclipse-equinox/equinox.framework/releases/tag/M20140115-0800 The patch does not apply to newer versions of Equinox. The latest change to the equinox patch added a hack to be able to load recent versions of the bouncy castle OSGI bundles. For bouncy castle that works as the package imports are marked optional, for other dependencies we patch the JARs to be able to load them: https://github.com/apache/netbeans/blob/f88a2a3dab55dc731996f4f9625065e9234803d6/platform/o.apache.commons.lang3/build.xml#L29-L37 I was reminded of this when I tried to integrate new OSGI bundles to support ssh signing with jgit. This fails on equinox as these import JDK packages, which does not work on equinox. I don't think that further patching is sustainable solution. So I tested and did this: - Remove NetBinox hard dependency from common code (https://github.com/apache/netbeans/pull/9426) - add the required jgit jars - remove NetBinox - remove the unused packages: - o.eclipse.core.contenttype - o.eclipse.core.jobs - o.eclipse.core.net - o.eclipse.core.runtime - o.eclipse.core.runtime.compatibility.auth - o.eclipse.equinox.app - o.eclipse.equinox.common - o.eclipse.equinox.preferences - o.eclipse.equinox.registry - o.eclipse.equinox.security The hypothesis here is, that the eclipse packages were "only" there to support Mylin (Bugtracking integration). As that was removed the packages seem to unused and should be removed. So before I create a PR from this: Is there a reason to keep two OSGI runtimes? Greetings Matthias
Well, as someone who tried to do some standalone testing done on Netbinox modules, and found that frustrating experience. I'd really see that gone.
Honestly, if it would be possible, i would like to see both OSGI runtime out. It was a great technical breakthrough of the time.
I'm not sure if we actually use anything out of that now, besides that we have a few libraries where we use the OSGI metadata instead of project.xml to put them into the module system. So if we would provide the external metadata, there would be no need to have any OSGI runtime at all.
So as of now, I'm supporting the idea of dropping Netbinox.
PS: Sending from my apache address as the mailinglist has still broken dmarc settings --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
