It's not that I *don't* want to use version numbers, it's that in general
it doesn't account for these sorts of constraints. When I can use jmod
describe and see "oh it can only be used with a java.xml that has this
exact hash" but can't look in my bucket of java.xmls and say which ones
have that h
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
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 ca
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*
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 m
On 14/12/2024 08:02, Ethan McCue wrote:
Hi all,
Not sure if this is best for core-libs or langtools, but best I can
tell there is no way to determine the hash of a module programmatically.
The hashes you found are a JDK-specific feature so you there isn't a
standard API exposed. Hashes are u
