Dominique Devienne wrote: > Frankly, this sounds great Costin. But, from what you are writing below, > it sounds that you have thought a lot on the issue of antlibs and use of > namespaces in Ant, yet I haven't read anything about this prior to this > particular message... Did I miss the discussions on it?
Well, I did write about this several times in the past. I don't have any formal proposal and no code to check in yet ( except for a hook that I'm still testing ). > I'm afraid that once more a big chunk of good code will get vetoed because > not thoroughly discussed by the community before-hand, and not easily > digestible by pieces. Sure, having something already implemented that > works is a great base for discussions, but looking back at what happened > not too long ago with the Ant2 proposals, maybe it isn't enough after all. There is no chunk of code - all I have as code is a single class with a single method ( and 2-3 lines of changes in ProjectHelper to call the hook). > In summary, I'd like to be able to hear more from you about how you want > to tackle antlibs, imports, etc... so that maybe I get my views / use > cases in from the users perspective, and also (and maybe foremost) so that > some kind of consensus agrees it's the right direction. For imports - my proposal is in proposal/embed. It has been discussed a lot, and I think this piece is ready for majority vote ( and I'll do that soon ). The 'dynamic properties' are stable, but I still want to try other languages and BSF. For antlibs - I just want to propose a hook ( ProjectComponentFactory ) to be called by RuntimeConfigurable/UnknownElement/ProjectHelper before calling the default method. That will allow diferent user-defined task factories to be defined. I'm also working on a particular factory, using commons-discovery and a simple properties file - but I don't plan to propose it soon, it's just experimental code to test some ideas. For each 'feature' I plan to propose a separate majority vote for the API ( or behavior ) and a separate vote for the implementation ( which may be the one in embed or modifications on the existing ProjectHelper ). In case a feature is rejected, I plan to do the same thing as ant-contrib - i.e. treat the feature as a separate add-on. I don't see anything wrong with this aproach - all of the features I'm interested on have been discussed ( or at least I posted my intentions and requests for comments - see thy 'my itches' thread ). While embed is becoming a 'large chunk' and includes a lot of features, each feature is relatively independent of the others. Costin > But maybe I'm just ignorant of how Open Source project work again... --DD > > -----Original Message----- > From: Costin Manolache [mailto:[EMAIL PROTECTED] > Sent: Monday, September 30, 2002 12:33 PM > To: [EMAIL PROTECTED] > Subject: RE: xml namespace support in ant2 > > My opinion: > > 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. > > 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 ). > > 3. The embed proposal uses SAX2, but it is not doing anything ( yet ) with > the namespaces. My original plan was ( and still is ) to use the namespace > as an ID, and use it to locate the task definition using getResource(). > For a task in NS, I would look up META-INF/ant/encoded(NS)/SOMETHING - and > locate the description of the tasks in that namespace and additional > metadata. The descriptor should support both properties (for simple cases) > and an XML form. > > 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. > > 5. Even if ns is added, most people will still prefer to use the default > namespace. It's just much easier to type and use ( at least IMO - and from > what I've seen ). Should we restrict the default ns to ant core tasks and > force everyone to use ns for extensions ? I don't think so. > > 6. Namespaces should be used instead of 'taskdef' whenever possible > ( i.e. the descriptor ). > > > Costin > > Wannheden, Knut wrote: > >> This reply is a little bit late (just got back from holiday) but I think >> it's an important topic and I was wondering if anybody has given this >> more thought in the meantime. >> >> With some minor adaptions I think your general description of the usage >> of XML namespaces sounds very good. >> >>> -----Original Message----- >>> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED] >>> Sent: Freitag, 6. September 2002 23:54 >>> To: Ant Developers List >>> Subject: Re: xml namespace support in ant2 >>> >>> So instead we could say that >>> 1) all ant: namespace elements are core ant. >>> >> >> Well, what the namespace prefix is in the buildfile is really up to the >> user. It's just the URI that matters. So all of thw following should >> work: >> >> <project xmlns="urn:ant-namespace"> >> <target name="test"/> >> </project> >> >> <xyz:project xmlns:xyz="urn:ant-namespace"/> >> >> But specifying it as the default namespace as in the first example or >> using "ant" as the prefix will probably be the most common usages. >> >> When you say "core ant" I assume you're talking about <project>, >> <target>, all core and optional tasks and types in the distribution. >> >>> 2) different namespaced elements have to be defined before use as >>> taskdefs, typedefs or antlibs, and ant treats them accordingly >>> >> >> I think saying it the other way around would be more correct. I.e. >> Custom tasks and types have to be declared to use a different XML >> namespace. >> >>> 3) all namespaced tags that are not declared as in (2) must >>> be declared >>> beforehand as <namespacedef namespace="nms" handler="..."/>, >>> so that the >>> Ant ProjectHelper can use that particular Handler to process the >>> extension. A convenient nullHandler is created when the >>> handler is not >>> specified. >>> >> >> What would this be used for? Isn't it enough with task and type >> extenstions? Other extensions would certainly raise confusion... >> >> The primary benefits I see of using XML namespaces the described way are: >> >> - Mechanism to avoid name clashes of different tasks and types >> - Schemas (grammars) could be written for Ant buildfiles covering the Ant >> core elements and external tasks and types. >> >> The schemas in turn would allow the validation of tasks and types to take >> place externally and at an earlier stage. With externally I mean that >> the tasks and types wouldn't need code to do the validation themselves. >> >> At a later stage the schemas could maybe even be the basis for the >> documentation. Also, the different usages of a task could maybe be bound >> to the different processing modes somehow. >> >> Playing some with RELAX NG and Sun's MSV validator I found that it was >> quite >> easy to specify grammars for the different Ant tasks and types. Even >> writing grammars that support other namespaces isn't very hard. That way >> a grammar which validates buildfiles using other namespaces for external >> tasks >> and types can be constructed easily. It should also be quite easy to >> allow external tasks to specify their own grammar for validation. >> >> Any thoughts? >> >> Cheers, >> >> -- >> knut > -- Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
