Replying to myself ;-)
On Thursday 01 May 2003 09:55, peter reilly wrote:
>
> The concept was introduced in the ant lib proposal.
>
> I propose to add it to Definer (and hence to typedef and taskdef). This
> is to allow the use-case of optional tasks. Currently all the types/tasks
> in ant core ar
On Wednesday 30 April 2003 18:28, Costin Manolache wrote:
> peter reilly wrote:
> > I think that agreement is very close.
> >
> > What about this proposal:
> >
> > The current types and tasks properties files may be combined
> > into a antdef.xml file of the form:
> >
> > >
Jose Alberto Fernandez wrote:
>> That means more filesystem specific code. You can't use
>> getResource() to
>> get META-INF/antlib.xml from a specific jar - unless you're
>> sure that's
>> the only jar with that res. in the classloader. So you either
>> operate on the
>> jar with Zip, or you hav
> From: Costin Manolache [mailto:[EMAIL PROTECTED]
>
> Jose Alberto Fernandez wrote:
>
> > What I thought was to have a separate directory ANT/antlib
> (or something)
> > where people can put libraries which they can load easily on demand.
> > Something like:
> >
> >
> >
> > which will just l
peter reilly wrote:
> I think that agreement is very close.
>
> What about this proposal:
>
> The current types and tasks properties files may be combined
> into a antdef.xml file of the form:
>
>onerror="fail/report/ignore"/>
> ...
> ...
>
What is the "onerr
I think that agreement is very close.
What about this proposal:
The current types and tasks properties files may be combined
into a antdef.xml file of the form:
...
...
Definer (in the form of or ) can use
this either as a file or as a resource.
or
or
(if antcontib-xyz.jar
Jose Alberto Fernandez wrote:
>> From: Costin Manolache [mailto:[EMAIL PROTECTED]
>>
>>
>> My concerns with getResources() as oposed to
>> getResource( PACKAGE/antlib.xml):
>>
>> 1. startup time. In order to load one library you need to process all
>> of them. It can be resolved with caching th
> From: Costin Manolache [mailto:[EMAIL PROTECTED]
>
>
> My concerns with getResources() as oposed to
> getResource( PACKAGE/antlib.xml):
>
> 1. startup time. In order to load one library you need to process all
> of them. It can be resolved with caching the result and
> looking at .jar
> mo
Nicola Ken Barozzi wrote:
> ...
>> The proposal provides a task which can be used to
>> load libraries manually. Al the same time there are hooks on the code
>> for an autoloading mechanism to be supported. In escence, it would
>> allow ANT's main() to do something like:
>>
>> - get all antlib
Jose Alberto Fernandez wrote, On 29/04/2003 12.03:
...
The proposal provides a task which can be used to
load libraries manually. Al the same time there are hooks on the code
for an autoloading mechanism to be supported. In escence, it would
allow ANT's main() to do something like:
- get
Finally some body with sense :-)
> From: Wannheden, Knut [mailto:[EMAIL PROTECTED]
>
> The question I think is more important is whether antlibs
> should be loaded
> explicitly with something like an task (similar to
> ) or
> if it should be more automagical like in Jelly where the
> namespac
Two points
1)
Using /org/apache/.../anlib.xml defeats the purpose of the antlib
proposal.
However it is in keeping with current ant practice.
it could be supported using
or using nested elements
antlibs would still have the fix
>
> peter reilly wrote:
> > True. It seems quite difficult to use namespaces in a nice way.
>
> You are not supposed to "use namespaces in a nice way".
> XML Namespaces are there so that you can avoid name clashes
> for XML element and attribute names if you want to use XML
> vocabularies from va
J.Pietschmann wrote:
> Costin Manolache wrote:
>> There are working and valid systems ( Axis, Xslt ) that use the namespace
>> with associated meaning.
>
> The expanded XML element/attribute names get a meaning through an
> processing model, nobody denies this. The problems start if someone
> ass
Costin Manolache wrote:
There are working and valid systems ( Axis, Xslt ) that use the namespace
with associated meaning.
The expanded XML element/attribute names get a meaning through an
processing model, nobody denies this. The problems start if someone
associates a specific semantic with the f
J.Pietschmann wrote:
> peter reilly wrote:
>> True. It seems quite difficult to use namespaces in a nice way.
>
> You are not supposed to "use namespaces in a nice way".
That's a matter of taste. Some people like "nice way", some people
like UUIDs. There is nothing in the namespace definition th
peter reilly wrote:
True. It seems quite difficult to use namespaces in a nice way.
You are not supposed to "use namespaces in a nice way".
XML Namespaces are there so that you can avoid name clashes
for XML element and attribute names if you want to use XML
vocabularies from various uncoordinated
peter reilly wrote, On 28/04/2003 19.53:
On Monday 28 April 2003 18:41, Nicola Ken Barozzi wrote:
peter reilly wrote, On 28/04/2003 19.37:
On Sunday 27 April 2003 22:14, Wannheden, Knut wrote:
...
but maybe the buildfile author wants/needs to specify the namespace URI
(anything really), in which c
On Monday 28 April 2003 18:41, Nicola Ken Barozzi wrote:
> peter reilly wrote, On 28/04/2003 19.37:
> > On Sunday 27 April 2003 22:14, Wannheden, Knut wrote:
>
> ...
>
> >>but maybe the buildfile author wants/needs to specify the namespace URI
> >>(anything really), in which case an additional "ns"
peter reilly wrote, On 28/04/2003 19.37:
On Sunday 27 April 2003 22:14, Wannheden, Knut wrote:
...
but maybe the buildfile author wants/needs to specify the namespace URI
(anything really), in which case an additional "ns" attribute could be
used:
This is fine.
This is *v
On Sunday 27 April 2003 22:14, Wannheden, Knut wrote:
> > Or even:
> >
>
> That syntax abuses the purpose of XML Namespaces, IMO. Although a
> namespace is identified by an URI, I don't think attaching semantics to it
> is correct.
I am no expert in xml ns usage (my only experiance with xml is
21 matches
Mail list logo
