But it also gives harder times to debug things, and I suspect most of the time no one really will use substitution packages, e.g. just the usual “add OSGi headers to this library please” no one will really ever want to provide an alternative package variant.
Yep that’s why I wanted to to switch to @Export annotation
It depends on what what one qualifies as an “issue”, from a technical POV this all will work but:
- If I add OSGi metadata to a library, I most often try to find the smallest possible increment, that is, the less I add compared to the current library state, the more likely it is that my change will be accepted by a maintainer knowing not much about OSGi
- Enabling features (here package substitution) for there is no real need (e.g most of the time no one really likes to substitute anything) always have the risk of adding complexity or maybe side-effects hard to understand, so less features are generally better in terms of maintaining by a non OSGi-Expert
So these are more soft-facts than hard technical issues, but often it is better to have less sophisticated support than full-fledged support that makes people feel it is “to complex” for a library that is not primarily used in OSGi and maintained by people with zero knowledge about all the fancy stuff from OSGi.