On 16 Jul 2002, Stefan Bodewig wrote: > > IMHO the biggest problem at this moment is the fact that > > optional.jar is loaded in the system class loader. > > We probably all agree on this. 8-) We could dramatically improve the > situation by a very simple step though, splitting up optional.jar > along its dependencies.
That would be great - it could also be a first step in modularising ant task library. I think we should also discuss namespace issues in this context - but one step at a time. However, as I mentioned in one of the many mails, I would also like a solution that can be aplied to ant1.5. ProjectHelper hook allow someone to install a 1.5+ 'extension' that provide parsing. This can be used to enable some other things, like the reverse loader or the <import>. I think it would be very valuable to have all the new stuff that we're going to put into 1.6 tried out - we have a very long release cycle and projects can't use the cvs head. Having small groups of tasks available as a separate 'library' that works in 1.5+, and keeping them as a separate entity ( like a commons sub-project ) would have the most benefit IMHO. If everyone agrees that smaller libs are the way to go - we can start eventually using a different namespace and releasing the components one by one ( without conflicts with the old ones - so Peter can't complain too much :-) > Combine this with a new class loader scheme for antlibs only. > Further, make it possible to use the now split up parts of > optional.jar as antlibs, if the user asks for it - but keep them on > the system classpath by default. Finally, provide all new tasks as > antlibs. We can keep the old libs in the system classpath, and release tasks in a new package ( org.apache.ant.something ) - as antlibs. This will insure maximum backward compatibility ( i.e. 100% ), and will give users a very easy migration path and imediate access to the new tasks. Instead of waiting until 1.6 to get user feedback on import, we can get it now - by releasing first an aplha, beta and then freezing the <import> semantics ( again, the current model is to release the whole 1.6 - and get feedback and freezing few dozens new tasks ). > > There are 2 solutions for that - one is to use a tomcat-like loader > > hierarchy. The other is to do a small hack > > +1 on a non-hacky clean hierarchy. I agree - if we can release a junit antlib there is no need for the hack. I'll still try to make the hack work - as a short-term solution for 1.5 users ( because in the process I want more testing on the sax2 processing ). Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
