incubator-depot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <aj...@trysybase.com>
Subject Re: classloader was: Moving forward or letting go
Date Mon, 21 Jun 2004 00:15:31 GMT
> >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.
> Class loading is not a goal.
> IMHO it is orthogonal, to depot.   Depot  gets/manages a repository of
> artifacts.
> 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.

Depot Update has nothing to do with Class Loading, but is there any reason
we couldn't allow a separate Depot project to do that (using Depot Update or
some core called Depot Download)?

I'm not advocating that Depot try to be all things to all people, but I
think that CL is a extension that folks will want.  (If/when I get version
constraints off the ground, then maybe I could attempt to persuade this
project to work with it, but that is a future conversation.)

regards,

Adam


Mime
View raw message