Add automatic module name

[raphw]

Closes #1268.

Adds Automatic-Module-Name: dev.sigstore. As in the issue, only sigstore-java gets one.

The other two commits are what make that name usable, both are about compatibility on the module path.

sigstore-java compiled its own copies of google/api/{annotations,field_behavior,http}.proto and shipped the resulting com.google.api classes in the jar. Those are the same class names that proto-google-common-protos publishes, and that artifact is already on the runtime class path via grpc-protobuf. So the copies never really solved anything: the fully qualified names are identical either way, and which one wins comes down to class path order. On the module path it is not silent any more:

java.lang.module.ResolutionException: Module proto.google.common.protos contains
package com.google.api, module dev.sigstore exports package com.google.api to
proto.google.common.protos

The README kept the copies because proto-google-common-protos had gone stale. It is at 2.74.0 now, and its versions of those three files are identical to ours apart from a cc_enable_arenas option that only affects C++. So I dropped them and declared the dependency explicitly, since BundleVerifier links against com.google.api directly and only got it transitively before.

Same story for the DSSE envelope. envelope.proto sets go_package and ruby_package but no java_package, so protoc put Envelope and Signature in io.intoto and shipped them. protobuf-specs has published protos only since 0.3.2, so these are generated here regardless and the Java package is ours to pick. I set it to dev.sigstore.proto.dsse, matching what the sibling protos already do.

That last one is a breaking change for Java callers, Bundle.getDsseEnvelope() and friends change type. Only the Java package moves though. The proto package stays io.intoto, so the descriptor is still io.intoto.Envelope, and the wire and JSON encodings are unchanged. Existing bundles stay valid.

Happy to split the envelope commit out if you would rather take that separately.

[loosebazooka]

I think we should just update the intoto envelope proto in sigstore/protobuf-specs. I'll put that in and we can update this PR after: sigstore/protobuf-specs#923.

I wish I used the module system more, but if we were to split sigstore-java into multiple modules (potentially planned), how would the naming strategy change?

[raphw]

You'd keep the "main module" with its current name and likely suffix the other modules with a dot.

Have a look at jenesis.build if you are curious about easier access. My current pet project.

[loosebazooka]

hey, I think you can continue with this for now, and update the dependency on protobuf-specs to 0.5.2 to clean up some of those generated code renames

[loosebazooka]

My bad I wasn't really thinking. Lemme do that protobuf-specs update in a separate pr so we don't pollute this one

[loosebazooka]

okay sorry, so I got that done, we can just move this to automatic module name

[loosebazooka]

and what are the consequences of changing the module names later?

[raphw]

I would not recommend changing the name. It would lead to any module compiled against your module to fail. During compiletime or runtime. It's a name you should choose once and stick to it. Similarly to a groupId and artifactId. It's going to be the durable representation of your artifact on the module path.

[loosebazooka]

okay, I think this sounds good then. sigstore-java may break out into multiple modules, but a sigstore-module umbrella module will always exist.

Are you in a time crunch for this? can it wait a few weeks while we flesh out how we plan to split this up?

[raphw]

Yes, that is the recommended refactoring. Have one empty module that imports submodules. Starting at root from the reverse DNS name of the library's domain.

[loosebazooka]

I do think it would be weird to have this be the dev.sigstore module though. This is just a client. We could have other dev.sigstore libraries coming from other parts of the ecosystem.

[raphw]

That's fair. I would still avoid using Java in the name, as this is a Java-scoped coordinate already. But possibly append client?

[loosebazooka]

that would require us to set all packages to dev.sigstore.client.xyz?

[raphw]

No, you can have packages whereever, but it is a convention to align root package and module name. What you cannot have us that packages in one module also exist in another module. Packages are reserved by each module on startup and overlaps crash the VM.

[loosebazooka]

okay cool. Do you mind if I come back to this next week. I want to see how we can keep things aligned. Its starting to sound like dev.sigstore should be fine, but I want to make sure.

[raphw]

Certainly. Better to get this right than to rename later!

[vlsi]

dev.sigstore looks the right way to go.

[loosebazooka]

okay lets go with dev.sigstore then? Can you rebase or whatever, so it's just the remaining change in the build.gradle.kts?

[raphw]

Perfect, this makes this a trivial change!

[loosebazooka]

@raphw we need the sign off line in the commit message. If you could just git commit -s --amend on this commit and push it back up before we can merge.

[raphw]

Added the sign-off.

[hfhbd]

Just curious, why not use a module file?

[raphw]

Would be possible, too. I wanted to make the least intrusive step, and I'd be happy to see this project add a named module file once this has proven to not yield issues with users.

[loosebazooka]

assuming that's an easy transition I can do a release of this now.

[hfhbd]

Yeah, we can do it later, I was just wondering.