moditect / layrry

A Runner and API for Layered Java Applications
Apache License 2.0
332 stars 33 forks source link

Consider resolving artifacts with transitivity enabled #92

Open aalmiray opened 3 years ago

aalmiray commented 3 years ago

As of 1.0.0.Alpha1 layers must have all pertaining artifacts defined explicitly.

Consider adding an option to allow transitivity during artifact resolution (will work for Maven compatible repositories, not for local repositories (flat, default)). This option could be global (affects all layers) or perhaps activated per layer.

aalmiray commented 3 years ago

This may be trickier than I thought. Enabling global transitivity may result in duplicate modules that need not be loaded again, for example

layers:
  log:
    modules:
      # - "org.apache.logging.log4j:log4j-api:2.14.0"
      - "org.apache.logging.log4j:log4j-core:2.14.0"
      - "org.moditect.layrry.it:it-logconfig:1.0.0"
  foo:
    parents:
      - "log"
    modules:
      # - "org.moditect.layrry.it:it-greeter:1.0.0"
      - "org.moditect.layrry.it:it-foo:1.0.0"
  bar:
    parents:
      - "log"
    modules:
      # - "org.moditect.layrry.it:it-greeter:2.0.0"
      - "org.moditect.layrry.it:it-bar:1.0.0"
  app:
    parents:
      - "foo"
      - "bar"
    modules:
      - "org.moditect.layrry.it:it-app:1.0.0"
main:
  module: org.moditect.layrry.it.app
  class: org.moditect.layrry.it.app.App

The log layer brings log4j-api transitively because log4j-core requires it. OK The foo layer brings it-greeter:1.0.0 (OK) and logj-api (NOT OK). The bar layer brings it-greeter:2.0.0 (OK) and logj-api (NOT OK). The app layer brings both foo and bar, which bring log4j-api (NOT OK) and their respective greeter modules (BOMB!)

If transitivity is enabled then duplicate entries (found in parent layers) must be purged from the list of JAR paths before creating the current layer. This also means we have to keep track of JAR paths per layer. Currently we only keep track of ModuleLayer to find the parent(s) of a given layer.