Add Java module system support with Multi-Release JAR

[cowwoc]

Add module-info.java files to all modules and configure Multi-Release JAR compilation to support both Java 8 (without modules) and Java 9+ (with modules).

• Add module declarations for common, service, value, and factory modules
• Configure Maven compiler for dual compilation (release=8 and release=9)
• Update build order and versions for consistency
• Maintain full backward compatibility with Java 8 runtime

Enables module system benefits for Java 9+ users while preserving existing Java 8 compatibility through Multi-Release JAR mechanism.

[cowwoc]

Fixes #597

[eamonnmcmanus]

The CI is failing with this message:

Error: The action actions/upload-artifact@v3 is not allowed in google/auto because all actions must be pinned to a full-length commit SHA.

[cowwoc]

@eamonnmcmanus Fixed. Try again.

[eamonnmcmanus]

Still failing, unfortunately. I think we're probably not going to want to keep that 999.0.0-SNAPSHOT stuff? I believe we may have tooling that assumes the HEAD-SNAPSHOT we have. Is there a way to avoid that change?

[cowwoc]

Still failing, unfortunately. I think we're probably not going to want to keep that 999.0.0-SNAPSHOT stuff? I believe we may have tooling that assumes the HEAD-SNAPSHOT we have. Is there a way to avoid that change?

As @cpovirk mentioned, it isn't possible to keep HEAD-SNAPSHOT. The version must start with a number, per the JPMS specification.

[cowwoc]

Is it possible to configure the CI to keep on running the build every time I push an update? I just pushed a fix.

[eamonnmcmanus]

Is it possible to configure the CI to keep on running the build every time I push an update? I just pushed a fix.

It might be, but I don't know how. (Meaning, I don't know how to configure that for you without also configuring it for everybody.) This is something that GitHub put in place a few years ago because people were sending bogus PRs that would update the CI actions to do Bitcoin mining. Even if your PR wasn't submitted, those CI actions would run. I don't know if the countermeasure actually needs to require manual approval for PRs that don't touch the CI actions, but anyway it does.

I'll look into committing a trivial punctuation change and recording you as the author, in the hope that that will mean that updates to your PRs won't require manual approval for the CI.

[cpovirk]

You might also have luck with locally running the two commands from our config in series, noting that the first always fails:

https://github.com/google/auto/blob/c508fdae344bab23869146679d3025be52118bca/.github/workflows/ci.yml#L40,L43

[cpovirk]

I should have said this in #1976 (review), but:

I suspect that no files should reference 999.0.0-SNAPSHOT except:

• to declare the version of this project itself (meaning as the value in the <version> element directly nested inside the top-level <project> element)
• implicitly by referring to ${project.version} for intra-project dependencies (by which I mean, e.g., how value/processor has to refer to auto-value-annotations, not for cases in which, e.g., value/processor has to refer to auto-common, a "separate project")
• in a <parent> reference (where we can't use ${project.version} because it's declared in the parent, for better or for worse)

My logic is: We can't release with a SNAPSHOT dependency. Thus, unless we were to try to wire up an atomic release for all the projects, we'd need to release a modularized AutoCommon, then update deps to use that, then release a modularized AutoValue, then update deps to use that, and then release a modularized AutoService. (This is roughly the same situation as I was in during the f3fbb3b saga that eamonnmcmanus dug up earlier.)

Under that logic, I'd be looking at updating:

• factory/pom.xml: auto-service.version, auto-value.version
• service/processor/pom.xml: version of auto-common
• value/processor/pom.xml: version of auto-common

But really, I'd be looking at having one PR that targets just AutoCommon, at least when it's time to merge. Until then, it is very possible that we could get additional value out of testing everything with SNAPSHOT dependencies.

In the above, I omitted AutoFactory. I'm not sure that we should modularize it at all until we finish splitting out its annotations. Again, there may be value in testing our setup for it beforehand.

[cowwoc]

Sorry, work sucked all the energy out of me this week. I'd love for someone else to pick up where I left off; otherwise, I'll try getting back to this in a couple of weeks.