If you don't wish to use version numbers, why not generate a SHA256 hash
of each module instead?
--
Regards,
Peter
On 17/12/2024 1:34 pm, Ethan McCue wrote:
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
