Erik Hatcher wrote: >> - maybe we want antlibs to have some initialization. This can be >> easily done >> by allowing more ant elements in the descriptor >> - maybe we'll want to allow antlib to declare targets - that could be >> used >> in depends or antcall ( <target name="foo" >> depends="myAntLib:antlibTarget"/> ). > > Wow.... ok, still pondering....
Please - don't take this as "we should do this". It may be the worst idea ever. What I'm trying to say is that a lot of things we might want later will be simpler, and we won't have to bloat the antlib SAX processor to implement such features. I'm sure there are some valid uses cases and extensions that we may add - even if those 2 use cases are completely wrong. It is very unlikely antlib will never change. >> Again - those are just examples, there are a lot of things that could >> be >> done easily. Even if you don't need any of this - it would be nice to >> not have to repeat the long and painfull evolution of the main xml >> processor. > > It'll take some thinking and convincing for me to see why antlib needs > descriptors that get processed like Ant build files. Something as > simple as Digester would seem to do the trick (bootstrap craziness?!) > but as I said, I want to see what others think and let myself consider > your idea a bit more. - consistency. I think it would be a bad idea to use Digester in antlib and another mechanism in ProjectHelper. Plus digester would add dependencies on beanutils, collections - we already have introspection code. I can accept replacing ProjectHelper with Digester - but I would like we use the same mechanism. - same kind of extensibility as ant. It may not be perfect - but at least will be consistent and most people understand it. - We can just use the same ( or almost ) code for taskdef, roles and whatever else we want to allow to be defined in antlib. - very easy to implement ( minor changes in ProjectHelper to parse <antlib> at top and restrict the childs ). Actually, antlib could be a task ( so antlib elements could be used in a build file - another stupid idea ), and we can just change PH to start with a different root. - easier to maintain. I know we're all SAX experts, but we've seen a lot of tricky aspects in ProjectHelper long evolution. This way we maintain a single parser - and a single behavior. - all the wonderful features that may be easily enabled ( if they prove to not be very bad ideas ). I can add more to the list. Costin
