search

hypfvieh / dbus-java

Improved version of java DBus library provided by freedesktop.org (https://dbus.freedesktop.org/doc/dbus-java/)
https://hypfvieh.github.io/dbus-java/
MIT License
192 stars 74 forks source link

Make dbus-java OSGi ready #32

Closed svagionitis closed 5 years ago

svagionitis commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

stack-head commented 5 years ago

I've put out two PRs that might be suitable-you wouldn't want to merge both of them, either one or the other: https://github.com/hypfvieh/dbus-java/pull/66 https://github.com/hypfvieh/dbus-java/pull/67

hypfvieh commented 5 years ago

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 commented 5 years ago

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 | james.ocarroll@stackhead.com

On Thu, Jun 6, 2019 at 12:08 AM David M. notifications@github.com 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 https://github.com/hypfvieh/dbus-java/pull/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 https://github.com/hypfvieh/dbus-java/pull/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 https://github.com/hypfvieh/dbus-java/issues/32?email_source=notifications&email_token=AEB66R3GLAKAUZCLBIUJ7JDPZCLVLA5CNFSM4GI2QV32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXBXV2Q#issuecomment-499350250, or mute the thread https://github.com/notifications/unsubscribe-auth/AEB66R5NXTJA3SZ6IISC7RDPZCLVLANCNFSM4GI2QV3Q .

hypfvieh commented 5 years ago

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 commented 5 years ago

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 | james.ocarroll@stackhead.com

On Fri, Jun 7, 2019 at 3:17 AM David M. notifications@github.com 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 https://github.com/hypfvieh/dbus-java/issues/32?email_source=notifications&email_token=AEB66R6RKRAQR7XUEKFT2PTPZIKTHA5CNFSM4GI2QV32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXFFKZY#issuecomment-499799399, or mute the thread https://github.com/notifications/unsubscribe-auth/AEB66R4H5QNXGQ3BO6VINGLPZIKTHANCNFSM4GI2QV3Q .

hypfvieh commented 5 years ago

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