-
Notifications
You must be signed in to change notification settings - Fork 241
OSGi Support? #84
Comments
I can try to get to this in the next few weeks. Pull requests welcome. |
I checked your dependencies. slf4j-api, Google Guava, jax-rs, javax-annotation and Jackson are OSGi bundles. So your dependencies are full OSGi-compliant, this is a good news. But pom.xml of consul-client must be rewritten completely: all dependencies should be declared as |
So IMO this library probably shouldn't support OSGI - it seems like the primary use case is for non-OSGI apps, so the burden should probably be on those who want it. One option would be to publish your wrapper with dependencies/exclusions setup, with the correct manifests in a separate repo that pulls in consul-client. Ultimately it's @rickfast's call but just wanted to drop my 2c in. |
I would like to hep here but first I'd like to understand why should the dependencies be declared as provided ? |
I don't know enough about OSGi bundles to answer this. We can't change the main generate me pom to declare dependencies in the provided scope because that will break most of the clients. |
I do not think is is needed, as far as I know, once you have a proper manifest you should be ready to go (unless you have some specific requirement for calss-loading etc) |
|
This is true if you enable Embed-Dependencies, but you can configure it to include only the dependencies you need or to skip transitive ones (Embed-Transitive). |
I'll defer to you guys on this. My only requirement is that this work doesn't affect the default published artifact |
@rickfast definitively ;) |
@rickfast any chance to do a new release which include this OSGi enhancement ? |
|
@rickfast thx |
Life would be easier if consul-client will support OSGi. Today I have to wrap your library into OSGi bundle using many manipulations: excluding some dependencies, adding OSGi-compliant MANIFEST.MF and many other things.
The text was updated successfully, but these errors were encountered: