That might be useful, but it is not closer to what I am looking for. I am treating it as a constraint that the repository be able to hold java.base, java.xml,etc. That those modules are tightly coupled is information I don't want to lose.
If I have @corretto/java.base and @adoptium/java.base I can have some heuristics about what they can be used alongside (like, must be same provider + same version) but its metadata I would have to add in special for those cases and I would still not be able to handle if say, someone published @spring/spring.core v1.0.0 and @spring-boot/spring.whatever v2.3.4 and those have hashed dependencies recorded. > Just to say again that theses module hashes are for tightly coupled modules, they aren't the same as hashes that might be generated when uploading a module artifact to a repository. They are if someone uploads JMODs to the repository. On Mon, Dec 16, 2024 at 2:26 AM Alan Bateman <alan.bate...@oracle.com> wrote: > On 16/12/2024 02:12, Ethan McCue wrote: > > I am experimenting with making a package repository where modules are > > the artifacts (bundled as JMODs) and not jars. In this context we lack > > information about what version a particular module requires or what > > provider to get that module from. What I *can* do is say "if you use > > this java.base, you must use this java.xml" and so on, but given a two > > java.xml modules I can't say without those hashes which one you are > > allowed to use when constructing a "module set". > > > > This is relevant also if someone uploads some of their own modules > > where the hashes don't line up. > > > > Just to say again that theses module hashes are for tightly coupled > modules, they aren't the same as hashes that might be generated when > uploading a module artifact to a repository. For example, a build of > some project might produce 3 modules, one of which uses a qualified > export to make its internal API accessible to other two modules. That > internal API might isn't a stable interface. The hash that the jar or > jmod tools can generate at packaging time is used to tie the 3 modules > and prevent accidental mixing of modules from Monday's build with the > modules from Friday's build. > > One thing that may be useful to your experiment is the > "requires_version" in the requires entries of the Module attribute. This > is where a compiler can record the version string of a dependency. It > might be closer to what you are looking for. > > -Alan >
