API for determining the hash of a module
Peter Firmstone
peter.firmstone at zeus.net.au
Tue Dec 17 03:39:47 UTC 2024
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.bateman at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241217/a34ec3e5/attachment-0001.htm>
More information about the core-libs-dev
mailing list