From: <[EMAIL PROTECTED]> > On Sat, 23 Feb 2002, Jose Alberto Fernandez wrote: > > > From: "Stefan Bodewig" <[EMAIL PROTECTED]> > > > > <style> is a little special because it is (I think) the only task in the > > core packages > > that requires things outside ANT's core. See all the discussion about moving > > <style> to optional. > > > I don't think style is any special: >
See my comment below, to see what I mean. > > > Here is a sketch og the directory structure for ANT_HOME: > > > > ./bin/ > > ./lib/ > > ant.jar (loaded in the CLASSPATH) > > I would make it 'antcore.jar', i.e the current ant minus taskdefs. > Notice that, in my proposal, I do not think we should as far. I was thinking to just leave the core classes in the CLASSPATH at least at the begining. That is why I said that <style> is in special cathegory. Because I may not want that one in there. Not sure. > > > ./autolib/ > > some-opt.jar > > some-more-opt.jar (this two jars are loaded in the in the loader > > named: "" at startup) > > xalan/ > > some-xalan-opt.jar (this jar will be loaded in loader named: > > "xalan") > > junit/ > > some-junit-opt.jar (this jar will be loaded in loader named: > > "junit") > > In addition ( or instead ), build.xml can define explicitely a loader > named 'xalan'. If autolib is used, ant1.4 files will work better, > with explicit declaration you have more flexibility ( can place whatever > version in your own path/project). > Sure. It is upto the user. > > > Now for the old things that create their own AntClassLoader. > > I would like to be able to instruct AntClassLoader to attach itself to a > > particular > > loaderid (the default being ""). And would also like to add to <classpath> > > the ability > > to specify a loaderid to use for its parent. This is how one passes the > > information > > to AntClassLoader of what to do. > > Or just leave AntClassLoader unmodified, things that use AntClassLoader > will work as before ( and have the old limitations ), new things > will use the named loaders. > > Backward compat. means old build.xml/tasks will work as before, if > they can benefit from the enhancements without too much work > or stretch that's perfect, but I don't think this is essential > ( and it's not backward, but 'forward' compatibility ). > True. > I love this proposal - I hope you finish it before 1.5 ! Thanks. > BTW, it would be _great_ if this mechanism would be 'componentisable', > and maybe with a bit of refactoring expose an API and be used > independently of ant. Even moved to a 'commons-loader', and maybe > merged with the 2 tomcat loaders ( which are very similar, > except the 'name' is the webapp, with a predefined hierarchy ). > Well I have been coding some of it today. Let see what damage I can do this weekend. I need to go clubing now IT'S SATURDAY NIGHT!!!! Cheers, Jose Alberto -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
