ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter reilly <>
Subject Re: Roles (was: antlib)
Date Wed, 07 May 2003 09:09:54 GMT
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
      - 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.


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 []
> >> Sent: 02 May 2003 14:35
> >> To:
> >> Subject: Re: Roles (was: antlib)
> >>
> >>
> >> On Wed, 30 Apr 2003, Jose Alberto Fernandez
> >>
> >> <> 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:
> >> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message