Make dbus-java OSGi ready

[svagionitis]

Hi David,

First of all thanks for this library, it is very helpful if you want to connect to DBus.

Now, checking the MANIFEST file of v3.0.0 jar file in the maven repository, I could see that there are not any metadata specific for an OSGi bundle, like Import-Package, Export-Package, etc. Are you considering to add them in a later release?

Regards,

Stavros

[hypfvieh]

Hi,

I'm not familiar with all this OSGi stuff (always looked very confusing to me), so no I have no plans to add this.

Anyways, if you want to provide the required manifest entries and stuff needed for OSGi compatibility, please feel free to send me a pull request.

[svagionitis]

Cool thanks David for the quick response. I am not so familiar with OSGi myself, but I will try to create a pull request with necessary changes.

[cdealti]

@svagionitis are you still working on this? If not I can do that.

[stack-head]

I've put out two PRs that might be suitable-you wouldn't want to merge both of them, either one or the other:
#66
#67

[hypfvieh]

Thanks for your PRs.
As I'm not familiar with that OSGi stuff, I'm not sure which PR would be "the better one".

If I understand correctly, using #66 would not be suitable as the required dependencies are not OSGi compliant. I don't think that we have the chance to convince every project to make there stuff OSGi compliant.

Using #67 will in deed create a very large bundle.
I hate those fat-jars providing old versions of some libraries which were messing up other ones projects.

If my observations are correct, some kind of "hybrid" model would be great.

I would like to provide two different versions, one "fat" version which is OSGi ready (e.g. dbus-java-osgi), and the regular version we have right now (dbus-java).
Any idea on how to do this in one deployment step?

[stack-head]

As you state in your last statement, generating both a typical jar file and a second "fat" bundle as separate outputs should be agreeable. I spent a bit of time reading, there seems to be a pretty strong consensus that trying to produce two artifacts in a single pom.xml file is more trouble than it's worth. I think you could either: 1. maintain two separate pom files, one for each output, 2. Create a parent pom file with all the shared properties (pom packaging), and two additional pom files that inherit from it-one would be jar packaging, the other would be bundle packaging. You may also choose to differentiate between the two artifacts with either a different artifactId or a different version (Think 3.2.0-SNAPSHOT and 3.2.0-bundled-SNAPSHOT), I'm not sure what would be better. Let me know if you'd favor one approach over the other, and I'll put out another PR. Thanks for the fast response.

…

------------------------------ *James O'Carroll* | [email protected]

On Thu, Jun 6, 2019 at 12:08 AM David M. ***@***.***> wrote: Thanks for your PRs. As I'm not familiar with that OSGi stuff, I'm not sure which PR would be "the better one". If I understand correctly, using #66 <#66> would not be suitable as the required dependencies are not OSGi compliant. I don't think that we have the chance to convince every project to make there stuff OSGi compliant. Using #67 <#67> will in deed create a very large bundle. I hate those fat-jars providing old versions of some libraries which were messing up other ones projects. If my observations are correct, some kind of "hybrid" model would be great. I would like to provide two different versions, one "fat" version which is OSGi ready (e.g. dbus-java-osgi), and the regular version we have right now (dbus-java). Any idea on how to do this in one deployment step? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#32?email_source=notifications&email_token=AEB66R3GLAKAUZCLBIUJ7JDPZCLVLA5CNFSM4GI2QV32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXBXV2Q#issuecomment-499350250>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEB66R5NXTJA3SZ6IISC7RDPZCLVLANCNFSM4GI2QV3Q> .

[hypfvieh]

What I was thinking about was some kind of additional module.

dbus-java already is a maven multi-module project, so I created a third module which builds an OSGi bundle.

Changes pushed, maybe you can have a look if this is working for you.

[stack-head]

This is great, this works just fine for me. Thank you, feel free to close the two PRs. Have a good one.

…

------------------------------ *James O'Carroll* | [email protected]

On Fri, Jun 7, 2019 at 3:17 AM David M. ***@***.***> wrote: What I was thinking about was some kind of additional module. dbus-java already is a maven multi-module project, so I created a third module which builds an OSGi bundle. Changes pushed, maybe you can have a look if this is working for you. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#32?email_source=notifications&email_token=AEB66R6RKRAQR7XUEKFT2PTPZIKTHA5CNFSM4GI2QV32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXFFKZY#issuecomment-499799399>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEB66R4H5QNXGQ3BO6VINGLPZIKTHANCNFSM4GI2QV3Q> .

[hypfvieh]

I guess the OSGi stuff is now solved. I'll close this ticket.