Proposal: #VersionedDependences

[Ali Ebrahimi]

Hi,

On Fri, Jan 27, 2017 at 2:06 AM, <mark.reinhold at oracle.com> wrote:

> 2016/12/15 9:20:51 -0800, forax at univ-mlv.fr:
> > I do not like this proposal for several (good) reasons.
>
> (Well, of course they're good reasons!)
>
> > The issue asks to be able to store a version strings or a constraints.
> > It can be interpreted as two different things.
> >  - the configuration used by example by Maven which uses constraints
> > that will be resolved,
> >  - the other is the effectively resolved versions which is what this
> > proposal do.
> > In my opinion, storing the former info maybe more interesting for a
> > language (the actual configuration) than storing the later.
>
> Storing version constraints might be more interesting, but we can't
> do that in JPMS since JPMS (intentionally) does not have a concept of
> version constraints.
>
> > We already agree that we support annotations (and obviously classfile
> > attributes) so any languages are free to store this kind of information
> > in it's own annotation/at
> >  - you often need to compile several modules together, if a module A
> > requires a module B and the module B uses a service from module A, but
> > --module-version can only specify one version for all the modules
> > compiled together.
>
> The expectation is that if you're compiling a set of modules together
> then they're all related, and hence likely all have the same version
> string.  The workaround is to invoke the compiler more than once.  If
> this really becomes a problem then a compiler could accept a more complex
> flag that specifies a map of module names to version strings, but that
> seems like overkill at this stage.
>

Why we don't add source code support for version string in module
declaration?
module foo at 1.0{
....
}

module bar at 2.0{
....
}

This way when code reviewing we know what is version of module.
 Also, we don't have Remi's mentioned problem of multi-module code bases.

-- 

Best Regards,
Ali Ebrahimi