On Tue, Mar 27, 2018 at 4:07 PM, Cédric Champeau <cedric.champ...@gmail.com> wrote:
> > Version ranges solve this problem. >> > > They don't. They introduce new categories of problems (reproducibility, > boundaries) and don't account for the fact that liveliness of a version is > post-publication (a vulnerability is rarely discovered before releasing, > typically). > They do. The fact that they create further (solvable) challenges does not mean that they are not a solution to the initial problem. The second point is also incorrect - indeed, this is exactly the point of using a range rather than a point version. If I depend on a range "[1.4, 2.0)", this is because I need a *feature* that was released in version 1.4 of the dependency. My module is compatible with version 1.4.0 and if there is a bugfix called 1.4.1 then my module is also compatible with that. My version range does not imply anything about vulnerabilities that may exist in version 1.4.0, and nobody is suggesting that it should. > > > >> Whether or not JPMS enforces version constraints, the inability to even >> state a dependency upon a version of a module has created duplication.You >> have to state "require module" in module-info, and you have to repeat it >> with additional version information in the build descriptor (pom.xml, >> build.gradle, etc). >> > > You don't have to repeat. There's nothing that says that _you_ should > write the module file. Also, the build tool _may_ source the dependencies > from the module info file (but it wouldn't be enough, because you want > different dependencies for test, compile, API, ...). > You keep making my point for me! Dependencies are different at compile time from runtime... not just in terms of versions but also identities. For example it's common practice to compile against a pure API but deploy with an implementation of the API. The module-info in JPMS, which is enforced at both compile time and runtime, works against that practical insight. > Also a version is often misleading. What does it mean when you write "I > depend on 1.0.4". > Well what does it mean when you write "compile 'foo:bar:1.0.4'" in your build.gradle file? It means you have compiled against that version of the API, and your module will be compatible with that version up to the next breaking change (2.0 if the dependency is using semver). If you wanted your module to be compatible with 1.0.3 then you would have compiled against 1.0.3. Unless you do that, there is no way for any tooling to infer that you are indeed compatible with 1.0.3. > Does it mean that it doesn't work on 1.0.3, or does it mean that it was > the latest version that was available when you built? Or does it mean that > actually this version is provided by your runtime environment, so it's a > strict dependency? We're currently tackling all these problems, which are > real world problems on medium to large scale applications. A single version > number is often not enough: you need constraints, and sometimes variants > (think classifiers). > > >> >> >> >> In what sense is module-info focused on the runtime aspect? It is >> enforced at both compile time and runtime, and yet it does not provide >> sufficient information for either the build tooling OR the runtime to >> assemble a consistent set of modules that work together. >> >> The module info file defines the module graph, and is enforced at compile > and runtime. However, it doesn't account for what you need: > > - when you build your library: API and implementation dependencies > - when someone builds against your library: only API dependencies > - when you run the library (API, implementation and "runtime only" > dependencies) > > Nor does it know which of does are provided by the runtime environment, or > compile tools. It only knows they are required, but barely knows who > provides them, and for what use. > If a module knows what it needs, it is not necessary to know "who" provides it.
