Wannheden, Knut wrote: >> 1. I hate using schema for validation. XML is not the only way to use >> ant - there are already projects using ant tasks as beans, >> and it's a good >> code reuse. >> Besides, schema is still slow ( and will allways be - due to it's >> complexity). Even Relax or simpler schemas can't ever beat the if() >> in the task, which also cover the use of the beans.
> If not schemas should be used for validation for the reasons you mention I > still think there should be some other mechansim. Ideally this mechanism > would ensure proper usage, allow consistent documentation to be generated > and simplify the code inside a task. As it is now task code gets very > cluttered with validation code, which is sometimes even wrong (because of > lack of a good mechanism). IMHO having a set of setXXX(), createXXX(), > addXXX(), addConfiguredXXX(), setDynamicAttribute(), and > createDynamicElement() methods just isn't the right way to express how a > task is to be used. Documentation is one issue - and schema may be the right way to document a task. Or javadoc and xdoclet ( which could generate a schema ? ). Having a method validate its parameters remains IMO the right way to write code. And is far cleaner ( and faster ) than any alternative. It is true - there is a duplication between the code checking if( param>10 ) throw InvalidArgumentException and the documentations or eventually schema. However having a 'validation' mechanism ( and there are few ) is more complex ( at least IMO ). I don't thing it's clutter to validate your params - just good programming. > And what you say about beans is probably not entirely true, at least not > if the tasks haven't been implemented with beans in mind. When used as beans > the client still has to mimic the behaviour of the Ant core somehow to set > up the task for usage. AFAIK that's how ant was designed - so that tasks are beans. Of course a client needs to instantiate a Project and do a bit of setup. Jasper is curently using javac task - and I think it is the right thing. >> 2. However schemas are good for documenting the task and for possible >> tools. As long as we don't use them for validation ( which >> I'll -1 as strong >> as I can ). >> > > Yes, they would provide a good means to document tasks. But they could > also > be used for validation. If the tasks should be possible to use > differently (e.g. as beans) I think there should be a mechanism which > allows for validation in both modes. So instead of a task checking its params, you would prefer some external mechanism. I think we should agree to disagree on this. But even if a majority would prefer external validation, schema is one of the worse possible solutions. There are some tools ( aspectj ? ) that are doing this at the code level ( or bytecode ?), but again I personally prefer explicit java code. > If I understand you correctly you would use the namespace as an ID for set > (library) of tasks and types. This is what I've been thinking, too. > > BTW, what kind of information did you have in mind for the task > descriptors? I would like 2 possible descriptors. The 'simple' case will be just the properties file that we curently use, that proved to work fine so far. I feel pretty strongly that having something 'simple' is important. Given that tasks/types are treated the same - and the distinction is getting small, we need to declare 'project components' and use class data ( instanceof, introspection ) to extract all other info. For more complex cases - an XML file containing the same info ( task name, class name ) plus documentation - for the first step. Then be conservative ( and have a majority vote ) for each added item. In any case I'm strongly against a kitchen sink aproach - of putting in everything we can dream of. The XML should use ns to allow extensibility and 'experimental' elements. >> 4. A very tricky issue is the syntax of the ID. We can use a >> meaning-less >> string, or a URL that can be used to download the lib. Even >> in the first >> case ( arbitrary string ) we can have a 'antlib registry' - >> but it would >> be extra overhead. I know there are many (strong) opinions on this. >> > > Well to use namespaces you would have to use IDs which can be interpreted > as > URIs. And at a later stage you could map that URI to an arbitrary string > with some "antlib registry". I was talking about URLs. A URL is a URI - but many people are against this because the URL can also be used to locate resources on the net. But I don't see why it would hurt - and why having a redirection stage ( CATALOG or a web service ) is absolutely needed ( it can be done with URLs ). Given the very different opinions - it would be best to keep this item separated from the discussion on the other issues. >> 6. Namespaces should be used instead of 'taskdef' whenever possible >> ( i.e. the descriptor ). >> > > I was thinking that namespaces would primarily be used to clearly separate > Ant core tasks from the custom loaded tasks and let the user use any name > for the task. To load custom tasks the buildfile writer would then either > do a <taskdef> or an <antlib>. E.g. > > <taskdef name="copy" ns="urn:abc-namespace" > classname="com.xyz.MyCopyTask"/> > <bla:copy xmlns:bla="urn:abc-namespace"/> > > This would not require that a descriptor exists for every task. The can be used for tasks that don't have descriptors. But if a task has a descriptor, there is absolutely no reason to require the use of taskdef ( unless the user wants to - for example to change a task name, which should be strongly discouraged and is no longer needed with ns ). > For <antlib> you would require that there be a descriptor which is located > with the encoded namespace URI as you say. Then you'd probably do > something like: > > <antlib resource="com.xyz.MyAntlib"/> > <bla:copy xmlns:bla="urn:abc-namespace"/> Yes, that's the main use case. However I would like to also use 'discovery' mechanisms. That may gain majority or not - but what I hope is that the hook will be accepted allowing user-components to support extensions ( just like ant-contrib defines procedural tasks, or embed defines alternate XML processors ). > where the antlib property would define the namespace URI it uses. (In all > examples the namespace attributes could of course also be declared in an > enclosing element, like <project>.) As I said, for myself I would rather use: <foo:bar xmlns:foo="http://foo.com/foo-antlib"; >...</foo:bar> And a discovery mechanism will locate META-INF/ant/foo-com-foo-antlib.properties|xml inside the classpath, or display a message that I need to download a library from that location - and not require use of taskdef. Again: this is my preference, it may or may not be what the majority wants. What I want is that regardless of the majority opinion on how this should work in the standard ant, the minority should have a hook to implement extensions, just like we allow procedural extensions or other things that didn't get accepted in the standard distro. ( or just like the ProjectHelper hook is used to plug in different processors like embed, even if SAX2 and various other features haven't been yet voted in ) Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
