Niclas Hedhman wrote:
Class loading is not a goal. IMHO it is orthogonal, to depot. Depot gets/manages a repository of artifacts.On Sunday 20 June 2004 07:16, Markus M. May wrote:
Depot offers a little more. The current design covers Maven repositories
as well as flat file repositories (for the local repository e.g.).
Ok. Avalon Repository has a SPI model in place, but code is currently required, since we cater to our own needs first :o)
But111`11`1`1 Depot has nothing to do with the classloading itself. It is like
already state right now, only for the build dependencies. The chained
dependencies are resolved via the dependencies of the dependencies. The
design therefor is not yet clear, because the needed meta-data for this
is not saved in the repository.
Yes, you will need to define or use server-side meta-data. The immediate effect after solving that is the Classloader (not classloading) establishment, since the 'type' of classloader the dependency belongs to, MUST be managed by the repository system, or you have missed a major goal.
For classloading, once you have the right jar in a known place on the local file system, then something else can handle classloading.
I am -1 for directly handling classloading.
Handling dependencies is a goal. Adam describes this as version constraints http://incubator.apache.org/depot/version/constraints.html
R, Nick
