Missing reification of the Module-path?

[Peter Kriens]

I think some simplifications could be made in the current design if we could standardize an artifact for the application module path at the same time. 

I think it should be quite straightforward to support fat applications and applications that reference their constituents (or  a mix).

Thanks, kind regards,

	Peter Kriens

P.S. And I’ve figured out the Application Module path, not sure what I was smoking :-(



> On 5 okt. 2015, at 20:51, mark.reinhold at oracle.com wrote:
> 
> 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