> -----Original Message----- > From: Peter Donald [mailto:[EMAIL PROTECTED]
> > > * Probably some light-weight mechanism for bundling up a set of > jars as an > > extension, without needing to mess with their manifests. Maybe > add them to > > a subdirectory of ext/ and use the subdir name as the extension name. > > This starts to make things feel a bit icky for me because it > means the person > who installs the products has to know how the implementors wanted it laid > out. Compare this to current mechanism where you cna just drop in a jar > anywhere on extensions on path and it just works. > Yep, fair enough. We can skip this one as a default. The point is simply that we should allow different types of extension repositories to be used, under the user's control, and provide a few useful implementations. If someone wants to use a non-standard implementation with their particular install, well, that's fine. > > As far as the classloader hierarchy goes, I'd like to try using > > multi-parent classloaders, to see what grief that causes. > > I have some code for that over in phoenix land - not checked in but ... I > coul dpossibly refactor it or at lkeast give it as an example of > how to do > things. I may check it in today if not then just go ahead and do > it whichever > way you please ;) (I say this because I may find out phoenixs one > is a mess ;) > If you can check something it, cool. No rush, though. I'm still trying to get Path untangled enough to turn it into an interface. Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
