It would be good to have a James plugins directory, but I think the way Phoenix manages the ClassLoaders for the application (James) makes this difficuly, in fact I think the application plugin concept would need to be implemented inside Phoenix. It is easy to create a ClassLoader that will allow James to load matchers and mailets from a plugins directory, but if you also want to add Avalon Components (as I do), these need to be visible to the ClassLoader that Phoenix uses to load Avalon components, and Phoenix would not be able to see the James plugins directory. I guess if we restrict plugins to matchers/mailets though this would work fine.
Steve > -----Original Message----- > From: Danny Angus [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 19, 2002 9:07 AM > To: James Developers List > Subject: New "latest" > > > Hi, > > I've made a new latest build, because I just noticed that it > isn't currently possible for end-users to "drop" mailet jars > into /lib/ and have them picked up by the mailet loader. > > This is something that I got concerned about if we're going > to try to kick start a 3rd party mailet community at www.mailet.org, something that seems to be generating its own inertia, so I've moved some jars, in particularly Mailet and Mail into phoenix-lib. I also moved some commonly used avalon ones; cornerstone, excalibur-datasource. And activation which just wanted to be there. This now means that any mailet packages in a jar archive can be simply dropped into ~installdir/lib/ and the classes will be found by the mailet/matcher loader, either with appropriate <mailetpackages> and <matcherpackages> elements, or as fully qualified classnames. d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
