Module descriptions versus module descriptors

[David M. Lloyd]

On 12/15/2015 12:53 PM, Paul Benedict wrote:
> On Tue, Dec 15, 2015 at 12:39 PM, David M. Lloyd <david.lloyd at redhat.com
> <mailto:david.lloyd at redhat.com>> wrote:
>
>     I think that this use case is supported by the requirements.  While
>     the requirements explicitly do not support multiple versions of
>     modules, it is easy enough to package each version as a separate
>     module with a different name, e.g.
>     "org.apache.commons.collections.3.2" vs.
>     "org.apache.commons.collections.3.3" or some such, optionally using
>     a module alias to choose one of these to be the proper
>     "org.apache.commons.collections" module.
>
>
> The SOTMS makes it clear the "convention" is to use the package name as
> the module name. My example is based on that convention. If versioning
> is always going to be an issue, that statement cannot hold true.
> Besides, I think putting the version in the module name defeats one of
> the design assumptions: the ability to swap in newer versions that are
> different than what was compiled against. In a world where semver is
> practiced perfectly, 3.3 should be able to be subbed for 3.2.

Ah, I took your question to be literally about the original requirements 
document.  Yes, the SOTMS document makes further assumptions and 
recommendations beyond the original requirements.

That said, my reading of SOTMS doesn't forbid what I've stated above - 
it does indeed state that "The name of a module will, therefore, often 
be a prefix of the names of its exported packages, but this relationship 
is not mandatory".  The SOTMS document furthermore does not appear to 
forbid numeric segments in module names, though it does say "A module's 
declaration does not include a version string, nor constraints upon the 
version strings of the modules upon which it depends", which one might 
interpret as forbidding this.  Even if numeric segments were not 
allowed, however, the problem could be addressed easily by using e.g. 
".v3_2" instead of ".3.2".

In a world of perfect semantic versioning, you probably wouldn't have 
3.2 vs 3.3 modules; you'd just have the latest 3.x which is shared by 
everyone, and maybe someday you might also have a 4.x; doing so would 
require this same trick though.

-- 
- DML