I would agree with XML namespace usage like this.
There are however some major and minor consequences
- in no particular order.
1) the code to handle XML namespaces in ProjectHelper2 is
not yet complete.
- namespaces of attributes is not handled yet - the
code uses getQName() on the attributes and does
not pass the URI of the attributes to the attribute list given
to
- the uris for project/target elements/attributes are not checked.
- the ns standard allows different types of software processing
for the different namespaces, if this is to be supported
ProjectHelper2 would need to look at the uri before handing the
element to the "ElementHandler" object (see my previous e-mail
on the subject)
2) The usage of Project#createTask/DataType(name) will not work for
tasks loaded as a result of XML namespaces, a Project#createTask/DataType(
uri, name) method will need to be added.
3) In what ns will the introspected attributes and nested elements of the new
elements reside? Some of the previous e-mails assume that they belong
in the antlib's namespace - but what about datatypes that extend ant's
datatypes - e.g mypath. (This is assuming that the attributes/nested
elements are found by introspection - for jmx:... this may not be the
case - or a different Class than IntrospectionHelper may be used).
4) the proposed polymorphic element type substitution
<element type="newtype"/> will need to be made ns-aware. either
<newtype for-element="element"/> or the ns prefix -> ns uri mapping at
the parse time when processing type="newtype" will need to be maintained.
5) Use of the ns form <project xmlns:myxyz="ant:net.sf.antcontrib/> means that
there is no need for antlibs. Indeed having them would be confusing. To
mis-quote the perl mantra, there should be only one way to do things.
There is no "lib", just a definition file in the classpath.
6) The current usage of <typedef resource="..."/> will still
be maintained. One of the ideas floating about in discussion for
antlib is that one can have <typedef name=.. classname=...
adaptor=.."/>. To allow third party add-ons to do this without using
ns or antlibs, one would need to load the xml definition file with
for example <typedef resource="net/sf/antcontrib/antdefintions.xml"/>
or <typedef defresource="net/sf/antcontrib/../"> or provide a new
task to process the definition file/resource.
To support this I would propose the following:
1: define the xml format of the definition file.
I would propose a root element of "antdef" and nested elements of
"typedef" and "taskdef" and a possible "description" nested element
and/or attribute.
2: either extend the <typedef/> task to use the definition file in the
same way as property files are deal with at the moment or provide
a task - <antdef [resource="..." | file ="..."] [classpath attributes
and nested elements from typedef/>
3: release/document the <classloader/> task to manipulate the classpath.
4: Implement the XML ns changes to use the xml definition file possibly
using a predefined filename and using a package name.
Peter
On Wednesday 07 May 2003 06:14, Costin Manolache wrote:
> Let's not reinvent the wheel here.
>
> The solution for names conflicts is namespaces - not rewriting.
>
> If we use a prefix, let's stick with what everyone else is using. Inventing
> some "original" solution ( that may or may not be easier or more flexible
> than the W3C solution ) won't make things better for the user.
>
> <antlib location="antcontrib.jar" prefix="myxyz-" />
> <myxyx-if ...>
>
> is not easier than
>
> <project xmlns:myxyz="ant:net.sf.antcontrib" >
> <myxyz:if ... >
>
>
>
> Costin
>
> Jose Alberto Fernandez wrote:
> > Hi guys,
> >
> > I was away on vacation so hasn't been around to make comments about the
> > entire discussion. I will try to sumarize here some comments that go
> > across several messages I have read today.
> >
> > The current <antlib> provides a way for the user of a particular antlib
> > to rename one or more elements that are in conflict with elements of some
> > other antlib it tries to use. As the renaming is local to the project
> > there is no problem; it is up to the user of the antlib to decide what
> > names to use to refer to the loaded things. For example I may use the
> > <foreach> class of antcontrib but for reasons of my project being in need
> > to also use a <foreach> defined by some other third party which works
> > diferently. So I could just load it and rename it lets say to <forall>
> > and use it in my project using that name.
> > It is up to me as the user of the antlib.
> >
> > From the discussion this last few days I like the idea from (I think)
> > Peter/Nicola of having short and long names where the long names are form
> > by adding a prefix defined not by the antlib writer, but by the antlib
> > user:
> >
> > <antlib location="antcontrib.jar" prefix="myxyz-" />
> >
> > which would allowme to use either:
> >
> > <if/> or <myxyz-if>
> >
> > it is upto the user to decide what to use. Of course the same would be
> > for the tasks (i.e., <taskdef>) that allows loading individual tasks into
> > roles. The same rules of collisions and conflict resolution apply.
> >
> > The important point is for the user (which is the one who has to
> > deal with name clashes) to have control of the final naming scheme used
> > in his/her buildfile. And we are not impossing any wierd semantics or
> > making assumptions, if I decide to use the same prefix for two antlibs it
> > is up to me to make sure there are no conflicts.
> >
> >> -----Original Message-----
> >> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> >> Sent: 02 May 2003 14:35
> >> To: [EMAIL PROTECTED]
> >> Subject: Re: Roles (was: antlib)
> >>
> >>
> >> On Wed, 30 Apr 2003, Jose Alberto Fernandez
> >>
> >> <[EMAIL PROTECTED]> wrote:
> >> > The problem you are overlooking is the case of <weblogic> element
> >> > in <ejbjar>, <jspc>, <serverdeploy>, etc.
> >>
> >> Maybe not really overlooking but understimating.
> >>
> >> The alternative would be to use <weblogicjspc> and <weblogicdeploy>
> >> for the different interfaces. If they come from different antlibs, we
> >> really should use XML namespaces to resolve this.
> >>
> >> But I now understand that having a table per interface may be
> >> convenient (though not strictly necessary).
> >>
> >> Stefan
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
