Use maven-bundle-plugin to export a bundle.

[JonathanLennox]

For the sake of OGSi, as used in Jitsi Desktop.

[ibauersachs]

Apart from the plugin-version this seems okay, but I'll try to have a look at the created jar later.

[ibauersachs]

Few things:

• I would add the following instruction to the bundle plugin. It removes hassle.

  <_removeheaders>Bnd-*, Tool, Require-Capability</_removeheaders>

• Why is a shaded jar built? It includes BouncyCastle, which removes its signature and will probably not work anyway. And lots of other crap, like IntelliJ annotations. It just doesn't make sense for a library.

• The srtpKdf256Test test fails for me on Windows (but my JDK is rather old, 1.8.0_144)

[JonathanLennox]

I believe I'm just using whatever the maven defaults are. If they're wrong, let me know. (By shaded jar do you mean the "jar-with-dependencies" jar file that's generated? I don't think we use it, so yeah, if there's a way to avoid generating it that's not a bad idea.)

srtpKdf256 works for me with 1.8.0_221 on Mac. Can you tell me which provider it says it's using?

[JonathanLennox]

@ibauersachs: I added the _removeheaders; I got a separate PR to remove the maven-assembly-plugin use (#7).

[ibauersachs]

Tests run fine now with an updated JDK.

[ibauersachs]

Not sure if this is new or if I didn't see it before, but: it won't work as long as there are protected fields (and maybe other things) referencing stuff from the crypto package.

[JonathanLennox]

So I need to add the org.jitsi.srtp.crypto to the export-package directive?

org.jitsi.srtp.utils contains only static methods - do I need to add that as well?

[ibauersachs]

Omit the entire directive and the plugin should figure it out.

In general, it doesn't matter if methods are static or not. Everything that needs to be accessible by consumers (i.e. bundles that consume this bundle) must be exported.
In this case, the stuff in .crypto must be exported because classes that derive from )(Base)Srt(c)pCryptoContext need to know the types of the protected fields. If Java had a notion of "package protected" or "internal protected" (like C#) this wouldn't be necessary.