Missing reification of the Module-path?

[mark.reinhold at oracle.com]

2015/9/28 9:51 -0700, peter.kriens at aqute.biz:
> The proposal specifies how to resolve a module from a _module path_, a
> module path being one or more directories with modular JARs.
> 
> Since the resolution is without versions, the module-path *must*
> contain a consistent set of artifacts. That is, the module path cannot
> be a repository like a maven repository it is closely bound to an
> executable since for each module only one of its versions can be
> chosen.
> 
> For example in maven the module path would consist of the transitive
> runtime dependencies. This is a unique set per application per
> version. I do not think it is practical to synchronize this set with
> other applications so one should assume this is unique and cannot be
> shared. It is potentially very large.
> 
> Ergo, the module-path *is* the application.

Or, almost equivalently, the module graph resolved from the module path
on behalf of the main module is the application.

> I therefore wonder if there is a need for a reification of the module
> path + main class? Such an artifact could contain an indirection like
> a URL to not require creating temporary module path directories for
> each application with potentially very large duplicated artifacts.
> 
> Such an artifact could then be made available as an atomic Layer.

Hmm.  Do you mean that such an artifact would contain copies of all of
the modules in the module graph, i.e., would it be a "fat" artifact?  Or
would it just record references to the necessary modules, presumably with
content hashes to ensure integrity?

We've explored similar notions in earlier prototypes.  An artifact in
either of these forms could, in principle, be generated by the linker,
but would require some new support at install time and/or run time.

It's an interesting idea, though outside the scope of this JSR unless
we conclude it's important to standardize the format of such artifacts.

- Mark