-
-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SnakeYAML base64Coder is not OSGI exported #62
Comments
Thank you for reporting this. This seems odd, as Felix OSGi maven plugin should construct declarations automatically. 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. |
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. |
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 |
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. |
That was quick. Nope. Codec only accessed internally by |
Fixed for |
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.
The text was updated successfully, but these errors were encountered: