On Sat, 23 Feb 2002, Jose Alberto Fernandez wrote: > From: "Stefan Bodewig" <[EMAIL PROTECTED]> > > > On Thu, 21 Feb 2002, Jose Alberto Fernandez <[EMAIL PROTECTED]> > > wrote: > > > > Let's take the example of the <style> task, how can we solve the > > scenario "I don't want Xalan in my system classpath" without breaking > > backwards compatibility in your opinion? > > > > I think I must be misunderstanding something of your proposal. > > > > <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: - you declare a named loader that includes xalan.jar ( and all other files you need ). - you use <antlib> or a <taskdef> to (re)declare style and associate it with the named loader. - you create the loader and it should work. 2 options for the loader: either ignore the delegation, or make it's parent the system classloader ( that would require a small change in the loading, with a different launcher like the one in either tomcat ). Obviously this will not work in ant1.4 - but that's a new feature. Ant1.4 files will have the same limitation as today ( require putting things in CLASSPATH ), but will continue to work - so it's a backward compatible. > 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. > ./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). > 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 ). I love this proposal - I hope you finish it before 1.5 ! 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 ). Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
