Enable loading of bundles importing java.-packages and update Bouncy Castle to fix jgit signing

[matthiasblaesing]

jgit signing requires bouncy castle libraries with a version higher equal to or higher than 1.79.

Recent versions of bouncy castle declare an import package:

Import-Package: java.io;resolution:=optional,java.lang;resolution:=optional,java.lang.ref;resolution:=optional,java.lang.reflect;resolution:=optional,java.math;resolution:=optional,java.net;resolution:=optional,java.nio;resolution:=optional,java.nio.channels;resolution:=optional,java.nio.charset;resolution:=optional,java.security;resolution:=optional,java.security.cert;resolution:=optional,java.security.interfaces;resolution:=optional,java.security.spec;resolution:=optional,java.sql;resolution:=optional,java.text;resolution:=optional,java.util;resolution:=optional,java.util.concurrent;resolution:=optional,java.util.concurrent.atomic;resolution:=optional,java.util.logging;resolution:=optional,java.util.zip;resolution:=optional,javax.crypto;resolution:=optional,javax.crypto.interfaces;resolution:=optional,javax.crypto.spec;resolution:=optional,javax.naming;resolution:=optional,javax.naming.directory;resolution:=optional,javax.security.auth;resolution:=optional,javax.security.auth.callback;resolution:=optional,javax.security.auth.x500;resolution:=optional

which is rejected by the NetBeans bundled equinox version. The validation provided by this version rejects alls java.* imports. This PR removes that check and updates bouncy castle to 18.3.

Closes: #8894
Closes: #8776

[mbien]

refreshed #8892 and temporarily added this PR to it to test everything together with jgit 7.4.

edit: smoke test worked, modules loaded + tested basic git workflow

[mbien]

changes look good. Checked the dependency tree for the new versions and nothing changed there.

osgi.nb10 probably needs its final hosting location still

[matthiasblaesing]

changes look good. Checked the dependency tree for the new versions and nothing changed there.

osgi.nb10 probably needs its final hosting location still

Valid point - I wanted to wait with moving to final hosting until this got some opinion apart from mine. Uploaded the artifact to osuosl and updated the corresponding commit.

[jherkel]

@matthiasblaesing why does netbeans contain two different OSGI providers? From historical point of view I understood but is there any reason to have them both now?

[neilcsmith-net]

Yes, while I have no issue with moving a quick fix for NB30, this got merged quite quickly, and there are two open questions here for me.

Firstly, are we still looking to remove this OSGi provider in the near future, as that was part of the reasoning behind the Mylyn removal?

Secondly, why are we still pushing stuff to OSUOSL when we're trying to move away from using it? Is that the only option here?

[mbien]

#9020 (comment)
was the last time I experimented with starting everything on one provider. If i remember correctly it started noticeably slower, I didn't do any measurements though (or searched for a cause) since that wasn't the goal - and there were other problems, see link.

Firstly, are we still looking to remove this OSGi provider in the near future, as that was part of the reasoning behind the Mylyn removal?

#9020 (comment)

Secondly, why are we still pushing stuff to OSUOSL when we're trying to move away from using it? Is that the only option here?

I think this is the pragmatic option. OSUOSL usage can be still reduced and ultimately removed but this is a slow / parallel process to other maintenance tasks.

[neilcsmith-net]

Sure, pragmatism is fine, just checking short term fixes and long term plans don't conflict.

I also have a slight issue with us using OSUOSL for new patched binaries. This was not what it was intended to be for, which was hosting legacy things. I do understand it might not be feasible to move this elsewhere at this time, or at all? We do need to consider what is still on there that is not easily migrated to somewhere else.