Rename artifact id and module name

[Sparky983]

When the base package was moved from org.jspecify.nullness to org.jspecify.annotations, the module name and artifact id where changed. It seems that when the base package name was reverted, unintentionally, neither the module name nor the artifact id were also reverted.

[cpovirk]

Thanks. There was a very brief discussion of this in #332.

I think we mostly just felt that no one would be too affected either way. Are the current names causing you build problems, or do you find them confusing, or are you merely noticing that we didn't fully switch back?

[Sparky983]

Sorry for the late reply.

I think we mostly just felt that no one would be too affected either way. Are the current names causing you build problems, or do you find them confusing, or are you merely noticing that we didn't fully switch back?

Originally, it was merely something I had noticed, but I do believe there is a valid argument for switching them back.

I think with the org.jspecify.nullness package, there was a case for org.jspecify:jspecify and org.jspecify, but now that that was reverted, the reasoning for maintaining those names is a little less clear. The argument about additional artifacts made by kevinb9n in #181 (comment) still holds strong though.

I can see that this would help tools like Dependabot however, I think this deserves a second look.

[cpovirk]

@kevinb9n may have thoughts on this, given his hope to soon commit to making no more changes that would break a plain javac build: A change to the module name would of course do that (though in a less severe way than almost any other such breaking change), so we'd either want to do this soon or else stick with what we have permanently.

[cpovirk]

I bounced this off @kevinb9n, who (as you saw) had been an advocate for including "annotations" in the artifact name (and presumably module name). A rename does make sense, given that it mirrors the name of the package and given that it suggests the eventual existence of other artifacts, as noted in the post you linked.

Kevin reminded me that he'd given up on pushing for that. (I'd forgotten about that, and apparently I didn't re-read it when I followed your link above.) That doesn't change the fact that it makes sense, just that it's not a hot-button issue :)

At this point, we think we've got bigger things to worry about. Now would be the time to change it, since it would disrupt the fewest users. But it doesn't seem worth it to us to force even the modest number of existing users to change their build configurations and module declarations (especially since, as you point out, Dependabot won't help... or maybe it could for the build configurations if we used some kind of Maven forwarding/deprecation?). Perhaps worse, it would increase the possibility that someone would end up with both org.jspecify:jspecify and org.jspecify:annotations on the classpath at the same time, and whichever comes first would win. Neither problem is big, but the problem of the odd name isn't big, either.

So, while we arguably should have done the rename in the first place, and while we already set a precedent of being willing to introduce some inconvenience by changing the module and artifact names previously, we don't think it's worth it now.

[netdpb]

The current (as of 2024-01-24) names are

Package: org.jspecify.annotations
Module: org.jspecify
Artifact: org.jspecify:jspecify

Stephen Colebourne suggests the module name should be either org.jspecify or org.jspecify.annotations, and that the artifact ID doesn't have to match the module name.

Since we plan to release other binary artifacts separately, like the conformance test library and maybe other libraries, and those are in different repos and their code in different subpackages of org.jspecify, I would think it make life more difficult if the annotation module name were org.jspecify. That suggests that the module name should be org.jspecify.annotations.

For the artifact ID, I'm comfortable with either org.jspecify:jspecify, since it's the main artifact, or org.jspecify:jspecify-annotations. I think the "jspecify-" prefix helps because some tools may show just the artifact ID without the group ID, and "annotations" is very generic.

[cpovirk]

I don't think the module name makes anything more difficult, does it? I could see making an argument that it's surprising, but I don't think that anything prevents having org.jspecify and also org.jspecify.conformance.

That said, the module name is a lesser concern from my perspective: I'd probably leave it alone unless it causes a concrete problem, but I think we could get away with changing it with a relatively small impact.

The artifact name, though, I think should remain as it is. A big reason for that is something that I think I had overlooked before: We don't appear to have ever published a release to Maven Central under the artifact name "org.jspecify:annotations." So today, there is only one artifact that looks like it might contain the JSpecify annotations, org.jspecify:jspecify. If we were to change the name, then we'd end up with both the old name (albeit with a pre-1.0 version number) and the new. That's not catastrophic, but it increases the chances that someone would pick the wrong name from zero (or at least close, since we'll gradually have more artifacts under org.jspecify) to a larger number, and it increases the chance that users end up with two conflicting copies of the org.jspecify.annotations package from zero to a larger number, too. That seems like trouble that our users don't need unless there's a concrete problem that the current name would cause.

[netdpb]

I may not understand something: Is it a problem to have two modules org.jspecify and org.jspecify.foo? Or is there no other constraint than that the set of types within each such modular JAR must be in disjoint packages (no package with a type in one JAR can also have a type in the other JAR), just like any two modules with unrelated names?

[cpovirk]

Yes, I believe it's possible to have two such modules. I don't think there's any sort of hierarchy based on module names; the restriction is just that a given package can't be part of multiple modules.

[fredrikjonson]

Just a small comment here, and not a problem as it seems the name wont change.

@cpovirk

The artifact name, though, I think should remain as it is. [...] We don't appear to have ever published a release to Maven Central under the artifact name "org.jspecify:annotations."

Another reason for not using only "annotations", without any other identifier as part of the artifact id, is that that name is too generic. While artifact names are name-spaced by their package id in the context of build systems, when downloaded the artifact becomes only "annotation-X.Y.Z.jar". And searching for only "annotations" returns hundreds of results.

https://central.sonatype.com/search?q=annotations
https://central.sonatype.com/search?q=a%3Aannotations

If you want to use "annotations" as part of the artifact id, I humbly suggest using "org.jspecify:jspecify-annotations".

[netdpb]

I think org.jspecify:jspecify is a fine name for the annotations artifact, better than :annotations for the reasons discussed. I could see :jspecify-annotations, but I don't think it's necessary, as we expect the annotations to be the core artifact people will depend on.

The fact that we've never released a Maven artifact with any other name is good; it means we don't have to worry about JLBP-6.

I'm convinced by all this that the JPMS module name doesn't matter too much, but the fact that org.jspecify corresponds to org.jspecify:jspecify is nice.

I propose that we keep the current JMPS module name (org.jspecify) and the current Maven artifact name (org.jspecify:jspecify).