<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>If you don't wish to use version numbers, why not generate a
SHA256 hash of each module instead?<br>
</p>
<pre class="moz-signature" cols="72">--
Regards,
Peter </pre>
<div class="moz-cite-prefix">On 17/12/2024 1:34 pm, Ethan McCue
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA+NR86ic8ssCJBgqUD-aJcD4g1o4Br=+HzUYZ5DfNFBL58Pfpg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>That might be useful, but it is not closer to what I am
looking for.<br>
<br>
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. <br>
<br>
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)<br>
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.<br>
<br>
> Just to say again that theses module hashes are for
tightly coupled<br>
modules, they aren't the same as hashes that might be
generated when<br>
uploading a module artifact to a repository. <br>
<br>
They are if someone uploads JMODs to the repository.<br>
<br>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Mon, Dec 16, 2024 at
2:26 AM Alan Bateman <<a
href="mailto:alan.bateman@oracle.com"
moz-do-not-send="true" class="moz-txt-link-freetext">alan.bateman@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On
16/12/2024 02:12, Ethan McCue wrote:<br>
> I am experimenting with making a package repository
where modules are <br>
> the artifacts (bundled as JMODs) and not jars. In this
context we lack <br>
> information about what version a particular module
requires or what <br>
> provider to get that module from. What I *can* do is
say "if you use <br>
> this java.base, you must use this java.xml" and so on,
but given a two <br>
> java.xml modules I can't say without those hashes which
one you are <br>
> allowed to use when constructing a "module set".<br>
><br>
> This is relevant also if someone uploads some of their
own modules <br>
> where the hashes don't line up.<br>
><br>
<br>
Just to say again that theses module hashes are for tightly
coupled <br>
modules, they aren't the same as hashes that might be
generated when <br>
uploading a module artifact to a repository. For example, a
build of <br>
some project might produce 3 modules, one of which uses a
qualified <br>
export to make its internal API accessible to other two
modules. That <br>
internal API might isn't a stable interface. The hash that
the jar or <br>
jmod tools can generate at packaging time is used to tie the
3 modules <br>
and prevent accidental mixing of modules from Monday's build
with the <br>
modules from Friday's build.<br>
<br>
One thing that may be useful to your experiment is the <br>
"requires_version" in the requires entries of the Module
attribute. This <br>
is where a compiler can record the version string of a
dependency. It <br>
might be closer to what you are looking for.<br>
<br>
-Alan<br>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>