SnakeYAML base64Coder is not OSGI exported

[mbechler]

d95b5c3 introduced a dependency on org.yaml.snakeyaml.external.biz.base64Coder resulting in an OSGI import of that package. However that is not exported by the SnakeYAML bundle (which seems correct given that it's a shaded copy that I would consider private) so the 2.9.3 artifacts cannot be resolved (== be used) in OSGI environments right now.

[cowtowncoder]

Thank you for reporting this.

This seems odd, as Felix OSGi maven plugin should construct declarations automatically. pom.xml for yaml package does not add explicit instructions (nor its parent pom).
So I am not quite sure why dependency is not included.

I also do not know how to fix this, so help would be appreciated.

Alternatively I guess I could just switch to using Jackson's own codec.

[mbechler]

The import is generated as one would expect but the package is not exported by the snakeyaml bundle. Given the .external. name (and the fact that it's explicitly excluded from export in snakeyaml) I think that code is not really meant to be consumed so it might be wiser in general to use jackson's implementation.

[cowtowncoder]

Ah, right, wrt exporting. What seems odd / unfortunate, then, is that plug-in was unable to detect such a dependency and report it.

I guess underlying challenge is that from purely Java call perspective class is perfectly reachable and as things are there is no way (AFAIK?) to indicate boundaries wrt OSGi.

... also, I wish OSGi did not have such huge problems with shading. SnakeYAML is a perfect candidate for shading, and was treated as such. Until someone pointed out OSGI having heartburn wrt it, and we changed it to regular dependency.

At this point I am also wondering what level of OSGi compatibility I should even try to reach, given that I do not have any use for it myself as things are. But end up having to work around issues compatibility requirements bring forth.

But from practical perspective perhaps I'll need to go with jackson base64 codec given that it works and is easily accessible and exposed by jackson-core.

[cowtowncoder]

Fwtw, yes, SnakeYAML does explicitly prevent this and it does seem to be embedded from an external project. So in hindsight it makes sense. The main reason why I would have preferred to use it was to try to maximize SnakeYAML compatibility. Will see if there is another API entry point that would allow this; if not, will use different codec.

[cowtowncoder]

That was quick. Nope. Codec only accessed internally by SafeConstructor / SafeRepresenter, and while latter deals with serialization base64 functionality not exposed in reusable form as far as I can see.

[cowtowncoder]

Fixed for 2.9.4.