I guess the local repo or system repo is not a big deal (after all both can be used as maven repo in pax so it is only different for startup jars) but the key point for me is: can the resolver be dynamic and compute anything or is it just an ordered deployment with precomputed start+refreshes - should likely impact the underlying OSGi framework too. If this last concept is reached with a state (OSGi state) computed at build time then Karaf would become a real cloud killer option IMHO.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 6 mai 2020 à 20:06, Matt Pavlovich <mattr...@gmail.com> a écrit : > > > > On May 6, 2020, at 10:45 AM, Steinar Bang <s...@dod.no> wrote: > > > >> 2. Improve build tool (part of devx) for build time resolution > > > > Hm... can this be used to fill up the system directory when creating a > > docker image on top of the official image? > > > > Have you looked at using local-repo? We’ve had good success copying > artifacts into the local-repo to ship an all-in-one, vs applying on top of > system. Not married to one way or the other, but might be good to talk it > through as far as the default tooling behavior and if there is a suggested > convention on what should be in “system/“ vs “local-repo/“. > > etc/org.ops4j.pax.url.mvn.cfg: > ... > file:${karaf.home}/local-repo@snapshots@id=karaf.local-repo > > >
