On 11/05/2016 15:14, David M. Lloyd wrote:
We package several hundred JARs in our modular environment today, only
some of which originate in-house. The dependency information for
these modules is established not by the author of these JARs, but by
us. The Maven artifact for such a JAR might stipulate certain things,
like Log4j or a certain version of ASM. When we distribute that JAR
though, we don't package the exact artifacts and versions of the
dependencies that were stipulated in the Maven POM; instead we package
single consistent versions which are ABI-compatible with all of its
dependents, or maybe even a completely different artifact that meets
the same ABI but performs its functions in a different manner.
Over time the environment we distribute evolves, and we split or join
modules, or we rename old modules to introduce a new major version of
the same module in parallel, or we replace one implementation with
another. When we do this we may chose to deprecate or eliminate a
module from our environment. Thus we update all the module
descriptors that reference the deprecated module, and set new
dependencies on them, and after a certain amount of time, we delete
the old module name.
None of the artifacts that we package are impacted by this process,
and generally no recompilation is necessary: after all, many of these
artifacts come directly from Maven or are otherwise built
independently at an earlier time outside of the context of our target
environment. It's the ABI that matters; as long as that doesn't change
(in an incompatible way), recompilation should never be necessary. I
think "recompile just to be safe" puts us squarely into "turn it off
and on again" territory, logically speaking.
Thanks for the context. So I'm curious what will happen when you
download JAR that is a modular JAR where the author have put in the
effort to declare their dependences and exports, maybe services too. Are
you going to override that too?
-Alan
