The baby and the bathwater

[Cédric Champeau]

>
> You keep mixing up the perspective of an application (and application
> assembler) with the perspective of a library/module.
>
>
It's interesting that you say this because we precisely value modeling
applications and libraries differently, using different plugins. However
not everybody does that and while we can think of _ideal_ ways to model
things. the truth is that most people don't reason like that. They use
Maven (or Ant), templates that generate projects for them, use `+` as their
dependency versions, BOMs to "suggest versions". or think that there's no
difference between a "compile" and "test" scope so we can put all
dependencies in a single json file shared by the whole company. So we're
not arguing about what the _ideal_ solution should be. We're arguing about
the interpretation of version numbers, and what people expect.


>
>
As a library developer I should pick the lowest version of my dependencies
> that my library can build against. When assembling an application you pick
> the highest version of each module such that you have a graph that will
> resolve.
>
> Version ranges in a library indicate compatibility, they say nothing about
> buggy point versions of the dependency. Yes you still need a mechanism for
> locking buggy versions but you store that information outside the module
> descriptor (because we cannot know about buggy versions that may be
> released in the future). That locking mechanism is in the domain of
> application assembly.
>

That's precisely the point. When, as a library author, you write: [1.0,
2.0), did you mean:

- I tested all versions from 1.0 to 2.0 (excluded), and they work (they are
_compatible_) or
- I tested all versions from 1.0 to 1.4, because 1.4 was the latest
available, and they work, and I suppose it's going to be true for anything
up to 2.0 or
- I tested with 1.0, and hopefully any higher version should work (most
likely what you intend to say) or
- You can build me with any version between 1.0 and 2, and it should
compile fine or
- You can build me with 1.0, and run with any superior version, should run
fine
- ...

The reality is that 99% of developers don't make any difference between all
this, they just took the latest version available, and built against it.


>
>>
>>
>
> Good to know. And how do you transform that information into module-info?
> You talked about generating module-info but it sounds like you would need
> two of them... one with foo.bar for compile (otherwise javac will barf) and
> the other with foo.baz for runtime (otherwise the runtime resolver will
> barf).
>

Currently we don't do any generation. It's an option to do it, and I
wouldn't say that it's the best one, I think it's still too soon to make
the decision. Especially, module info contains _additional_ information,
like services, that the build tool probably doesn't care about (again
arguable, we could potentially model services too). Another option is to
source dependencies from module-info, but it's not that simple (parsing,
mapping to the appropriate configurations, ...). So while it's a bit
annoying to have redundancy between dependencies declared in the build file
and those declared in the module-info file, there *is* interest for both.
In particular, what you build might not just be a single library. You might
want to share dependencies between modules, and make sure they use the same
versions. You might want to produce a platform definition (BOM) too. The
things we produce are different from the things we need.

>
> I love being told that I don't live in the real world, and that the
> problems I (and many others) have been solving for over a decade are
> insoluble :-)
>
>
It's not about not living in the real world or not. It's about the horrible
truth of the hundreds of modules published on Maven Central that use
hundreds of different conventions, both in versioning or publishing. And
recognizing things like "you shouldn't have 2 slf4 bindings on your
classpath". There's no silver bullet, so I don't think putting versions in
module info would solve this, on the contrary, it would probably make
things much harder for lots of people.