[jsr294-modularity-eg] dependency declaration syntax...

[Alex Buckley]

Almost everything is module system specific: the granularity of a 
dependency, the optionality of a dependency, the version scheme, the 
resolution algorithm, the location of modules, etc.

The common ground that 294 has found is that:
- a module has versioned dependencies on other abstract entities
   // typically on other modules and packages
- a module publishes names to a module system which allow the module to 
satisfy a dependency of another module
   // OSGi's exported packages come to mind, or Jigsaw's virtual modules

(a.k.a. 'requires'/'provides' keywords and API constructs.)

Because this leaves many details up to the module system, the EG has 
discussed how to identify which module system "owns" a module 
compilation unit. Please see 
http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2009-April/000261.html
Further see 
http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2009-May/000278.html 
where the EG's view was that this identification should be mandatory.

Alex

paulus.benedictus at gmail.com wrote:
> Wouldn't I be right to conclude then that modularization is then module 
> version specific? So if I want to run a module under many different 
> module systems, I would need different bundling descriptors or 
> something? It sounds a bit dangerous and unpredictable. With so many 
> interpretations of just a simple "6.0", how can anyone have confidence 
> that all the right bundles will be provided? Shouldn't there be at least 
> a canonical representation that everyone should interpret equally?
> 
> 
> On May 8, 2009 1:41pm, Alex Buckley <Alex.Buckley at sun.com> wrote:
>  > JSR 294 identifies the concept of a version in a module's identity 
> and in the target of a dependency:
>  >
>  >
>  >
>  >  module com.foo.myapp @ 5.0 {   // module identity
>  >
>  >    requires package com.foo.bar @ 6.0;   // dependency target
>  >
>  >
>  >
>  > JSR 294 does not define the details of a version's structure (digits 
> and dots? name-value pairs? qualifiers?), order (partial? total?), or 
> range operators (intervals? intersections? exclusions?). Those are 
> features of a module system. OSGi would interpret version "6.0" as 
> [6.0,infinity), Jigsaw as [6.0,7.0), and javac when bootstrapping the 
> JDK as [6.0,6.0].
>  >
>  >
>  >
>  > (This is why the EG has discussed a mandatory identifier in a module 
> compilation unit for which module system "owns" the dependencies.)
>  >
>  >
>  >
>  > Since JSR 294 does not define the semantics of a version, it should 
> not unduly restrict the syntax of a version. (Except where it's 
> necessary to respect existing language conventions, notably ';'.) Module 
> systems may invent new version structures, orders, and ranges. For example:
>  >
>  >
>  >
>  >    requires module   com.bar.nib @ 3.*-beta6+;
>  >
>  >    requires service  com.quux.la @ 2.0-2.5\2.3;
>  >
>  >    requires contract com.nab.top @ quantity='X',quality='Y';
>  >
>  >
>  >
>  > A module system can validate the string representing a version - see
>  >
>  > 
> http://cr.openjdk.java.net/~mr/jigsaw/api/java/lang/module/ModuleSystem.html#parseVersion(java.lang.String) 
> - so your compiler or IDE gives an error if, for example, you write an 
> invalid interval notation for an OSGi dependency. (The word 'jigsaw' in 
> that URL refers to the OpenJDK project, not the Jigsaw module system.)