Duplicate jars published to maven central

[splatch]

I been looking into your project lately and I have found that it has two jars published to maven central. Three if we'd count natives. My very brief look on jffi-1.2.23.jar and jffi-1.2.23-complete.jar shows that they're almost identical. Is there a reason why these are distinct?

I' have noticed that one with complete classifier has a valid OSGI manifest (which I been looking for). If its only one difference then I'd propose to merge both and ship OSGi manifest by default with Main-Class attribute for regular use.

[headius]

@splatch If we can just merge these jars I see no reason not to do it. Maybe you can come up with a PR and we'll go from there?

[splatch]

Sure, I am able to improve way how osgi stuff is handled. Since I was brought here by OSGi I will also mention that I some modules do miss metadata leading to situation where ie. dbus-java wraps all jnr artifacts to fix the issue.
I would like to address that and align maven dependencies through one parent descriptor (ie. jnr-parent?), however I found no valid place to start doing that. Would you mind making some cleanups in poms and extracting commonalities one level up shared across all jnr repos/modules?

[headius]

@splatch Actually we have talked about doing this for some time, but none of us are keen to work on Maven stuff and know even less about OSGi. We would love to have a master project or pom that contains the common pieces.

[splatch]

That's lovely cause I can help you with that. Once base structuring is done it should be relatively easy to maintain whole thing.

I am still between tasks but probably will have some relief after christmas or new year to take care of this. I'll create new repo with such parent and update one or two modules to use it. We should then have a base to discuss further directions.

[headius]

@splatch I guess we lost track of this. Can you do a preliminary PR that merges the two jars into a single one? I just realized that the Automatic-Module-Name directive is also only going into the complete jar.

[splatch]

@headius thanks for reminder. Indeed I lost track of this ticket. I believe end of this week or early next week I can start working on jnr-parent which should unify handling of plugins and other stuff between all modules. Does it fit your schedule or should I stress more?

[headius]

@splatch There is no particular time crunch. I am doing a release of everything from jnr-ffi down today to align dependencies and update to ASM 9.1, which will mean no updates are necessary for a while.

Looking forward to working with you to get these packages tidied up!

[splatch]

@headius Looking at how fast the official jvm ffi work is I think we need to work here. Are you still interested in maven cleanup?

[headius]

@splatch Yes we are! We need to do a cleaner job of packaging native resources, with an eye for Java modularity and cleaner handling of the native library unpacking.

For example, modules cannot see each others classloader resources, which would break unpacking these libraries from a separate module jar. I'm not sure what the proper blessed logic should be, but we may need to move the library selection and unpacking and loading into the "native" half of these jars. We should chat more about this.

I have also been looking into Panama and it seems likely that it will largely replace jnr-ffi on down and the remaining enxio, unixsocket, posix, constants, and process sub-libraries would be rewired to work on top of Panama.

It might also be possible to simulate jnr-ffi's API on top of Panama, but I have not dug deeply enough into the API to know for sure.

Let me know what you're thinking. We can chat directly on the JRuby Matrix channel or on some other service if it would be easier