Thanks Jose Alberto for the clear use-case of using the AntLib. I do like it a lot more now that I understand it better ;-)
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 24, 2003 7:04 AM > > * antlib needs a way to define mappings between names and classes. > > Costin prefers a properties file. Most others prefer XML. +1 to XML > My argument for XML is the extensibility. We will need versioning, we > will need some statement of pre-reqs (like this antlib requires > log4j), we will need additional capabilities we do not see now. I'm not fond of this pre-req thing you're describing, for the reason that it requires to be able to map a pre-req like log4j to an actual jar, which usually implies a centralized info center of some sort associating a pre-req name with a given JAR (versioned how? Manifest? In the jar name?). Versioning if often more than one can chew, and would endanger AntLib. So for the same reason you want to start with just tasks/types below, I'd prefer to start *without* versioning. > Let's make a version of antlib that knows about two predefined roles, > task and data-type. I think this is already feature complete in the > proposal (which does even more). An AntLib restricted to tasks/types is of no use to me, and I suspect others... But for the sake of getting AntLib in, I'll follow your pragmatic approach ;-) > Let's move this code with the restriction to tasks and types into the > main branch ASAP. Let's sort out the classloading requirements as > well as the interplay of antlib with taskdef and typedef here. I think classloading issues would be greatly simplified if Ant loaded only its core in the system CL, and everything else in child AntLoaders. The current loaderref attribute is enough to deal with having AntLibs sharing classes IMHO, and can be very easily retrofitter to AntLib. I even think it's OK to load several time AntLib dependencies like Log4j, if two AntLibs both depend on them, but were not declared to use the same CL. Keeps everything simple CL wise, and properly delegating, without going into CL that dynamically add JARs to lookup classes (I share Connor's concerns about this), or some graph of loaders (one per jar), or whatever else (ClassRealm?). > After this flies, I'd expect us to get roles sorted out. If we feel > like removing the difference between tasks and types, we can do so > then as well. BIG +1 to getting to roles quickly ;-) Overall, I agree with Stefan that we are all real close on the principles discussed in this thread, and their tremendous value to Ant. It's more the actual rolling out of this new functionality that's problematic. If I had only one feature I wanted out of Ant 1.6, I'd pick AntLib, even over <import> (partly cause I have a flexible resource: based XML entity include system). So a BUG (non-binding ;-) +1 to AntLib getting into Ant! --DD
