ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter reilly <peter.rei...@corvil.com>
Subject Re: antlib / proposal of Peter Reilly
Date Wed, 21 May 2003 07:56:22 GMT
Ok fair enough.

I still think that the URI specified at the "typedef"
task should be restricted, if only to allow
future versions of ant to support other forms
of processing based on URIs without affecting
build scripts that specify URIs using "typedef".
I do not see that this is a big restriction (but I could
be mistaken!). The restriction needs to be specified -
it could be that the uri must start with "antdef:", as the
typedef is defining ant types, but I am happy with
any restriction.

So I think that at least initially, the uri should be
restricted until feedback is received from the
community.

Peter

On Tuesday 20 May 2003 08:34, Costin Manolache wrote:
> peter reilly wrote:
> > There are a number of issues here.
> >
> > 1) are build script authors allowed to specify arbitary
> >     URIs for ant type definitions?
> >     I do not think this is a good idea.
>
> I agree - I also preffer URIs that are interpreted in a certain way (
> package names ), however we could support both.
>
> A URI that starts with "antlib:" will be parsed and the package used.
> Other URIs will be treated in a different way - either as arbitrary strings
> and matched against an explicit definition ( like the xml catalog ), or
> we may discover better things in future.
>
> > 2) what should ant do with URIs that it does not recognize?
> >
> >     a) use current method - unknown elements
>
> That seems the most reasonable and safe - it is what it does with unknown
> elements ( in no-namespace case ), I don't see why it should be different.
>
> >     b) ignore them
> >     c) explicty say that the ns uri is not supported
> >     d) convert them to Text in task/typedefs (the suggestion below)
> >
> >     I would prefer b) as it allows other processing of the xml content -
> >     say in an xml processing pipeline.  d) is also nice.
> >
> >
> >
> > 3) Should all processing outside Project/Target be done by
> > PH2#ElementHandler?
> >     I think one should be able to plug in handlers for different URIs, or
> >     URI patterns. My UnknownUriHandler is an (possibly not very good)
> >     example.
>
> My preference would be to not put any more functionality in ProjectHelper2,
> but operate on the tree. PH2 should just create the tree.
>
>
> Costin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message