WIP: Cleanup of maven poms.

[splatch]

This code is small reorganization of Maven poms. I've removed redundant elements (scm in sub modules) and removed inherited dependencies set in parent. I also had a look on OSGi stuff. I haven't tested it yet, hence I mark this PR as "work in progress".

[hypfvieh]

To be honest, I don't like these changes. They mix up re-ordering of configuration-nodes (e.g. parent, artifactId, description etc) and functional changes. I don't want the config nodes to be re-ordered. They should stay like they are.

Also I'm pretty sure that the changes in OSGi bundle will break something. I also played around with this OSGi crap and tried to use the library as dependency and do not provide any source to compile. This was always failing to build or the resulting artifact was useless. That's why I've added the relative path so the OSGi crap can compile the library (again) and is happy that there are sources to compile and bundle.

To get this request done, we have 2 options:

• You clean up the changes so it will only move the dependencies (common things to parent), you revert the stuff from OSGi
• I drop your changes

[splatch]

They mix up re-ordering of configuration-nodes (e.g. parent, artifactId, description etc) and functional changes. I don't want the config nodes to be re-ordered. They should stay like they are.

I reordered elements so they occur in most common order I've seen so far (model version, parent, GAV + packaging). It is a cosmetic thing. Can you tell why you don't like it or like your order more than standard one? At least for the SCM part - as long as you do releases from project roo scm tag in child modules is ignored.

Also I'm pretty sure that the changes in OSGi bundle will break something. I also played around with this OSGi crap and tried to use the library as dependency and do not provide any source to compile.

I can help you with that part since I know that crap pretty well. :-) I am able to update your build and make a small unit test confirming that osgi packaging is fine. Looking at shape of dbus-java I do not expect many new dependencies so its maintenance should be straight and made in a way which is harmless to you as primary maintainer.

I did a test drive with dbus-java and it worked with following bundles:

    <bundle dependency="true">mvn:org.ow2.asm/asm/7.3.1</bundle>

    <bundle>mvn:com.github.jnr/jnr-unixsocket/0.33</bundle>
    <bundle>mvn:com.github.jnr/jnr-constants/0.9.15</bundle>
    <bundle>mvn:com.github.jnr/jnr-enxio/0.28</bundle>
    <bundle>mvn:com.github.jnr/jnr-ffi/2.1.15</bundle>
    <bundle>mvn:com.github.jnr/jnr-posix/3.0.58</bundle>
    <bundle>wrap:mvn:com.github.jnr/jnr-a64asm/1.0.0</bundle>
    <bundle>wrap:mvn:com.github.jnr/jnr-x86asm/1.0.2</bundle>
    <bundle>mvn:com.github.jnr/jffi/1.2.23/jar/complete</bundle>
    <bundle>wrap:mvn:com.github.jnr/jffi/1.2.23/jar/native</bundle>
    <bundle>wrap:mvn:com.github.hypfvieh/dbus-java/3.2.3</bundle>
    <bundle>wrap:mvn:com.github.hypfvieh/java-utils/1.0.6</bundle>

Some of your troubles come from incomplete manifest in JNR dependencies (see wrap: prefix). In order to get problem solved we should work with JNR folks to provide valid metadata first in their projects. If that's done then your osgi packaging can be moved straight to dbus-java without need for additional maven mambo-jambo.

[hypfvieh]

I reordered elements so they occur in most common order I've seen so far (model version, parent, GAV + packaging). It is a cosmetic thing. Can you tell why you don't like it or like your order more than standard one?

I don't like that order because more un-interesting things are listed before the real interesting parts are shown. Most of the time I don't care about the parent of an artifact but I want to see the name/artifactId, version and so on. That's why I always put the parent stuff below the information regarding the artificat itself.

Yes it is some kind of 'cosmetic', but I'm so used to it, that I don't want to change it without any reason.

At least for the SCM part - as long as you do releases from project roo scm tag in child modules is ignored. I don't have any issues with the SCM stuff as long as it stays at the end of the file ;)

If you are sure the OSGi stuff is working, then I'm fine with that. I don't use OSGi and cannot check if it is working in a OSGi project (and I don't like or understand this format anyways)...

[splatch]

I don't like that order because more un-interesting things are listed before the real interesting parts are shown. Most of the time I don't care about the parent of an artifact but I want to see the name/artifactId, version and so on. That's why I always put the parent stuff below the information regarding the artificat itself.

Understood, I will revert reoderding changes and limit scope of this PR just to dependency re-arrangements.

If you are sure the OSGi stuff is working, then I'm fine with that. I don't use OSGi and cannot check if it is working in a OSGi project (and I don't like or understand this format anyways)...

I am quite sure it does work, since I successfully interacted with NetworkManager over dbus using above bundle list. I am not saying that dbus-java-osgi is wrong, cause it ships everything in one jar for fast test, it just makes little sense in semi "embedded" scenarios. Current approach makes it hard to use bluez-java-osgi and dbus-java-osgi at the same time, cause both wrap same artifacts.

Given that for sure you have people out there using dbus-java-osgi and bluez wrapper I'd opt for making separate PR for both with clear instruction how to migrate. I'll first try to interact with JNR guys to see how long lap it will be.

[hypfvieh]

This PR is too old and incompatible with the current state of dbus-java, also there was no update on this since end of 2020.