Comments (9)
hypfvieh
commented on July 23, 2024
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.
from dbus-java.
svagionitis
commented on July 23, 2024
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.
from dbus-java.
cdealti
commented on July 23, 2024
@svagionitis are you still working on this? If not I can do that.
from dbus-java.
stack-head
commented on July 23, 2024
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
from dbus-java.
hypfvieh
commented on July 23, 2024
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?
from dbus-java.
stack-head
commented on July 23, 2024
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>
.
from dbus-java.
hypfvieh
commented on July 23, 2024
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.
from dbus-java.
stack-head
commented on July 23, 2024
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>
.
from dbus-java.
hypfvieh
commented on July 23, 2024
I guess the OSGi stuff is now solved. I'll close this ticket.
from dbus-java.
Related Issues (20)
- dbus-java's Maven site is difficult to discover
- Emit meaningful error message instead of IndexOutOfBoundsException when demarshalling FileDescriptor without prerequisites satisfied HOT 5
- DBusSignal constructor is package private HOT 1
- Kotlin Interface does not work HOT 3
- NPE in org.freedesktop.dbus.connections.AbstractConnection.internalDisconnect(IOException) prevents JVM shutdown HOT 4
- Documentation example does not work correctly. HOT 1
- In version 5, `withAutoConnect(false)` appears broken. HOT 2
- Cleanup AbstractConnection
- `default` interface methods. Or not. HOT 7
- problem to execute DBusViewer HOT 3
- How to export/publish Property in interface? HOT 2
- Properties Get method endless waiting HOT 1
- Cannot connect to DBUS HOT 11
- Sending signal with byte[] fails with verbose logging HOT 1
- [Feature request] Any plan in adding a module-info ? HOT 2
- Custom ITransportProvider cannot be found by ServiceLoader HOT 4
- Something a bit wrong with `@DBusBoundProperty` HOT 9
- Incorrect code generation for systemd StartTransientUnit HOT 3
- Add dbus-java-transport-junixsocket to dbus-java-bom
- Help with DBusConnectionBuilder HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dbus-java.