Hi all,
jumping in...
Conor MacNeill wrote:
Costin Manolache wrote:3. If you don't need namespaces, you'll not have to use them. I.e. if you have a simple project and use few libs - you can still use the simpler syntax.
what is the "simpler syntax"? You mean no namespace qualifiers? How do you see both these mechanisms working at once? - defining all tasks in the default namespace and ignoring collisions?
This means the build file depends on the user's config to some extent. One user has no colision and uses <deploy> whilst another does and get the wrong <deploy> defined first. Not sure this is good.
I would say that tasks defined "behind the scenes" through the antlib mechanism should always be defined in namespaces. However, users can still define tasks manually using <taskdef>, and such tasks will by default be available in the default namespace - this would provide the required backwards compatibility, and users who don't want to deal with namespaces just need to <taskdef> all required tasks manually.
I agree that antlib defining external tasks in the default namespace is not a good idea.
The xmlns syntax is well defined - the only issue is the semantics of the
URI. Some people have strong opinions on that. My (strong:-) preference is for a URI that does have some semantics - i.e. it can be resolved to a java package. Some form of catalog can resolve this to URLs or something
else.
We need to have some mechanism to match the URI to a jar, whatever the URI format is. At this stage my pref would be to use a standard HTTP URL from which the library may be downloaded (not necessarily directly).
Why not use a mechanism similar to JSP1.2 taglibs?
Every JAR in $ANT_HOME/lib would be scanned for a descriptor in META-INF (for example; be it some XML format or a properties file), and that descriptor would contain a URI that needs to be used as XML namespace URI in the build file.
Hope I'm not totally off here... haven't followed much of the discussion before this thread.
-- Christopher Lenz /=/ cmlenz at gmx.de
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
