An interesting observation, for sufficiently small values of interesting...

[sesuncedu]

I'm currently doing an analysis of OSGI bundles as found in maven central.

Maven Coordinates	bundle symbolic name	Earliest bundle in central index
org.joda:joda-money:0.6	org.joda.money	2011-07-31 20:44:49
org.joda:joda-beans:0.8	org.joda.beans	2013-09-30 14:07:58
org.joda:joda-convert:1.4	org.joda.convert	2013-08-15 10:31:35
joda-time:joda-time:1.6	joda-time	2008-12-01 16:45:34

joda-time is an anomaly, but then again, so is its group-name. The earliest joda-time bundle in the dataset is re-wrapped by the apache servicemix project, and uses the normal reverse DNS conventions. I would add it to the table, but the name is too prefixed :)

Overall, there are 24,397 group+artifact series with bundle names that include at least one '.', compared to 2,053 that don't. Of the ones that don't, 537 have group names that contain the word 'jclouds'.

Not all of the bundle names with dots are proper reverse dns, but many of the old school unitary group names have newer BSNs. There's usually a relationship to a primary package, but not always, and that's not the purposes of the bundle name, since the package names are where the real action happens.

Would you like a csv dump of the relevant query?

[jodastephen]

The BSN is often generated from the Maven groupId and artifactId, which can result in a DNS name a lot of the time. I think overall we want to push people to choose their module name deliberately though.

Projects like joda-time pre-date a major change in Maven co-ordinates, where they insisted on groupId based on DNS.

The CSV dump might be useful, perhaps fork the repo and add a PR to highlight it?

[sesuncedu]

Nods (former sunsite/iBiblio employee from back in the day).

Will run the extract and do a PR when the database server and swap drives forgive me :) I will try and do JSON and markdown formatted dumps. I've been loading hashes and offsets of all the contents of all the jars (which are wrapped in a tar.xz for each artifact +classifier. The average compression ratio is around 5:1, and that's constrained by using multiple blocks. That is not a good sign of modular release practice).

The sad thing is that there's so much growing cruft that there's no time left for actual modularizing, and the big wins are gone. The module name shouldn't be a big deal as long as it's unique, and consumers shouldn't be forced to have to synthesize them. But that's where we are (or were this morning).

One of the problems with JPMS is the way that the module name has been forced to do a lot more work than it can comfortably bear, and a variety of not great ways of not doing versions. Granted, it seems that most libs have there own not great ways of doing versions, but it's less on purpose :)

I have a feeling that the best way of generating the module-info.class may be some hacks on the osgi generating tools, especially the annotations.

Also, I hate the way that module-info.java doesn't allow annotations in most of the places they'd be useful. What is this, jdk 7? :)

The hard work is still designing an api and separating that from the implementation. All a module system can do is not make it harder than it needs to be.

Jigsaw is actually helping me understand the reasons for some of the the things in OSGI I'd thought were just pointless complexity (and that OSGI is not the Latin term for "class cast exception"). The actual pointless complexity becomes more obvious.

My hope for the big analysis project is to find some indica for properly designed / versioned modules in central, (possibly with byte code rewrites), and to make resolving against central-sized repositories practical.

On Mon, May 15, 2017, 11:13 AM Stephen Colebourne [email protected] wrote:

The BSN is often generated from the Maven groupId and artifactId, which can result in a DNS name a lot of the time. I think overall we want to push people to choose their module name deliberately though.

Projects like joda-time pre-date a major change in Maven co-ordinates, where they insisted on groupId based on DNS.

The CSV dump might be useful, perhaps fork the repo and add a PR to highlight it?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jodastephen/jpms-module-names/issues/1#issuecomment-301506025, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZIG2zjc5BXBx9T56jfT6UqIZoa3wUwks5r6GuBgaJpZM4NaOi8 .

[jodastephen]

Just to note that I don't think Maven or similar should create module-info.class. I think that module-info.java will be an important part of your source code, and should be treated as such.

[sesuncedu]

Based on what I'm observing, in the OSGI case, the modularity and module metadata seems to be better when the metadata is assembled by the build tool, from source code that is appropriately​ annotated.

That may be a side effect of the complexity in the OSGI headers, or might be a result of more sophisticated users knowing how to use the tools more fully (although they would have been fine without them).

jdeps --generate-* is probably going to be the source of a lot future legacy :)

On Tue, May 16, 2017, 4:26 PM Stephen Colebourne [email protected] wrote:

Just to note that I don't think Maven or similar should create module-info.class. I think that module-info.java will be an important part of your source code, and should be treated as such.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jodastephen/jpms-module-names/issues/1#issuecomment-301905018, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZIG8AjV_qUo2RyO_FuLEwfE34-QkE7ks5r6gZugaJpZM4NaOi8 .