On Thu, 7 Mar 2002, Peter Donald wrote: > I vaguely remember we voted against URI namespace support in ant2 and instead > voted for namespace support similar to javas "import" namespace. I am not > sure if that is changed.
I vaguely remember W3C voted for namespace support in XML :-) I'm not sugesting that ant should require namespaces, or get into the religious discussion about the meaning of a namespace. I'm just saying they are part of the xml standard, and it's a good idea to design the task factory API with namespace ( in the generic sense ) in mind. If it's going to be a java-style package name or something else - it doesn't matter from the point of view of the factory interface. > > BTW, a 'namespace' is not an XML thing - it's a way to group > > tasks ( same as a package name in java, etc ). Having a flat > > naming for tasks doesn't scale very well. > > Nope - but we don't have to couple to URI directly. Reverse DNS naming of > java packages or C#s namespace seems to work well and is reasonably familiar > to most developers using ant. I agree, the semantic of the namespace is not my issue. The default for ant1 is clearly no namespace, and that should continue to be supported, but for user-defined components ( some maybe using the task factory ) it's important to leave the door open. > > Yes, the factory should return a ProjectComponent - be it a Task or > > DataType. It may return an adapter - i.e. TaskAdapter, or a DataType > > adapter. > > But all adapters extend ProjectComponent, right? Right. I'll change the interface. > > Regarding classloader - there is no need to modify anything else in ant. > > You can plug in a TaskFactory that implements/uses whatever class loader > > and policy it wants - no other piece of ant cares about this as long > > as it is consistent. > > You sure. Thats what I thought until I started to implement it ;) I'm very sure, no need to worry about that. > > It would be very good to have myrmidon and mutant factories wrapped and > > usable with ant1.5 - and I think making this work is essential, so > > if there's anything missing let me know. > > The factory interface as it stands is fine - the tricky bit will be how the > factorys are registered. I don't think your proposal addresses that just yet? Oh, that's trivial. Just 1 method in Project - addProjectComponentHelper(), and all helpers will be called before defaulting the Class. It's exaclty how normal task registation take place - a task like taskdef can register new tasks - or task factories. Well, probably a better solution would be to move all the code from createTask/createType in a DefaultProjectComponentHelper, so Project code will be cleaner and simpler - I'll try this out. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
