Re: ant 1.6.1 [was: Pb with namespaces in Ant 1.6 official]
On Tue, 06 Jan 2004, Antoine Lévy-Lambert [EMAIL PROTECTED] wrote: Dominique Devienne wrote: Does this warrant a 1.6.1? I'm actually quite stuck because of this bug This bug is impacting the most salient feature of ant 1.6.0, in the core of ant, so it is important. +1 Do we want to fix other bugs in 1.6.1 ? So far every commit to HEAD has been merged to the branch AFAICT. Has anything major come up so far? Sorry, I haven't had time to browse bugzilla so far. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant 1.6.1 [was: Pb with namespaces in Ant 1.6 official]
Stefan Bodewig wrote: On Tue, 06 Jan 2004, Antoine Lévy-Lambert [EMAIL PROTECTED] wrote: Dominique Devienne wrote: Does this warrant a 1.6.1? I'm actually quite stuck because of this bug This bug is impacting the most salient feature of ant 1.6.0, in the core of ant, so it is important. +1 Do we want to fix other bugs in 1.6.1 ? So far every commit to HEAD has been merged to the branch AFAICT. Has anything major come up so far? Sorry, I haven't had time to browse bugzilla so far. The two that are fairly serious is the filter fix (just now) and the jboss element for the ejb task (not in bugzilla). Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ant 1.6.1 [was: Pb with namespaces in Ant 1.6 official]
From: Antoine Lévy-Lambert [mailto:[EMAIL PROTECTED] Dominique : can you use a patched version of ant 1.6.0 until we provide an official new release ? Actually, thanks to Peter's answer I'm not stuck any more. At first I thought I couldn't use namespaces at all to turn around the bug, which would have stuck me, but in fact I still can use namespaces, just not assign a default namespace on the root element, thus leaving NCNames in NO namespace instead of the (default) Ant namespace. So in short I can do: project xmlns:ac=antlib:net.sf.antcontrib xmlns:bm=antlib:com.lgc.buildmagic ... / instead of project xmlns=antlib:org.apache.tools.ant xmlns:ac=antlib:net.sf.antcontrib xmlns:bm=antlib:com.lgc.buildmagic ... / which does not work with Ant 1.6. The only consequence this had for me was to change an XSL stylesheet processing the build.xml (to extract some meta-data from it) to match elements in no namespace instead of the Ant namespace (I was still using ant:core, so I had to change something anyhow.) That said, I'd welcome a 1.6.1 release, but I think it's not as much a priority for me now that I have a turn around. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Pb with namespaces in Ant 1.6 official
Just starting updating from Ant 1.6 beta1 to 1.6 official, and I've having a bad surprise. It seems there's a problem handling the default Ant namespace when explicitly specified, or when used as the default namespace, at least for the tstamp task. Have I doing something wrong??? --DD P:\com_lgc\10.0.7\tahoeC:\pro\ant1.6\bin\ant -f build16.xml Buildfile: build16.xml BUILD FAILED P:\com_lgc\10.0.7\tahoe\build16.xml:4: The tstamp type doesn't support the nested format element . Total time: 0 seconds P:\com_lgc\10.0.7\tahoetype build16.xml ?xml version=1.0? project xmlns=antlib:org.apache.tools.ant tstamp format property=TIME_NOW pattern=hh:mm:ss a z / format property=MMdd pattern=MMdd / /tstamp /project P:\com_lgc\10.0.7\tahoe P:\com_lgc\10.0.7\tahoe P:\com_lgc\10.0.7\tahoeC:\pro\ant1.6\bin\ant -f build16.xml Buildfile: build16.xml BUILD SUCCESSFUL Total time: 0 seconds P:\com_lgc\10.0.7\tahoetype build16.xml ?xml version=1.0? project tstamp format property=TIME_NOW pattern=hh:mm:ss a z / format property=MMdd pattern=MMdd / /tstamp /project P:\com_lgc\10.0.7\tahoe P:\com_lgc\10.0.7\tahoe P:\com_lgc\10.0.7\tahoeC:\pro\ant1.6\bin\ant -f build16.xml Buildfile: build16.xml BUILD FAILED P:\com_lgc\10.0.7\tahoe\build16.xml:4: The tstamp type doesn't support the nested format element . Total time: 0 seconds P:\com_lgc\10.0.7\tahoetype build16.xml ?xml version=1.0? project tstamp xmlns=antlib:org.apache.tools.ant format property=TIME_NOW pattern=hh:mm:ss a z / format property=MMdd pattern=MMdd / /tstamp /project P:\com_lgc\10.0.7\tahoe P:\com_lgc\10.0.7\tahoeC:\pro\ant1.6\bin\ant -f build16.xml Buildfile: build16.xml BUILD FAILED P:\com_lgc\10.0.7\tahoe\build16.xml:4: The tstamp type doesn't support the nested format element . Total time: 0 seconds P:\com_lgc\10.0.7\tahoetype build16.xml ?xml version=1.0? project ant:tstamp xmlns:ant=antlib:org.apache.tools.ant ant:format property=TIME_NOW pattern=hh:mm:ss a z / ant:format property=MMdd pattern=MMdd / /ant:tstamp /project - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pb with namespaces in Ant 1.6 official
Thanks for the report. Yes, the handling of the ant namespace is incorrect due to a change between 1.6beta3 and 1.6.0. I have placed a fix now. Peter Dominique Devienne wrote: Just starting updating from Ant 1.6 beta1 to 1.6 official, and I've having a bad surprise. It seems there's a problem handling the default Ant namespace when explicitly specified, or when used as the default namespace, at least for the tstamp task. Have I doing something wrong??? --DD P:\com_lgc\10.0.7\tahoeC:\pro\ant1.6\bin\ant -f build16.xml Buildfile: build16.xml BUILD FAILED P:\com_lgc\10.0.7\tahoe\build16.xml:4: The tstamp type doesn't support the nested format element . Total time: 0 seconds P:\com_lgc\10.0.7\tahoetype build16.xml ?xml version=1.0? project xmlns=antlib:org.apache.tools.ant tstamp format property=TIME_NOW pattern=hh:mm:ss a z / format property=MMdd pattern=MMdd / /tstamp /project P:\com_lgc\10.0.7\tahoe P:\com_lgc\10.0.7\tahoe P:\com_lgc\10.0.7\tahoeC:\pro\ant1.6\bin\ant -f build16.xml Buildfile: build16.xml BUILD SUCCESSFUL Total time: 0 seconds P:\com_lgc\10.0.7\tahoetype build16.xml ?xml version=1.0? project tstamp format property=TIME_NOW pattern=hh:mm:ss a z / format property=MMdd pattern=MMdd / /tstamp /project P:\com_lgc\10.0.7\tahoe P:\com_lgc\10.0.7\tahoe P:\com_lgc\10.0.7\tahoeC:\pro\ant1.6\bin\ant -f build16.xml Buildfile: build16.xml BUILD FAILED P:\com_lgc\10.0.7\tahoe\build16.xml:4: The tstamp type doesn't support the nested format element . Total time: 0 seconds P:\com_lgc\10.0.7\tahoetype build16.xml ?xml version=1.0? project tstamp xmlns=antlib:org.apache.tools.ant format property=TIME_NOW pattern=hh:mm:ss a z / format property=MMdd pattern=MMdd / /tstamp /project P:\com_lgc\10.0.7\tahoe P:\com_lgc\10.0.7\tahoeC:\pro\ant1.6\bin\ant -f build16.xml Buildfile: build16.xml BUILD FAILED P:\com_lgc\10.0.7\tahoe\build16.xml:4: The tstamp type doesn't support the nested format element . Total time: 0 seconds P:\com_lgc\10.0.7\tahoetype build16.xml ?xml version=1.0? project ant:tstamp xmlns:ant=antlib:org.apache.tools.ant ant:format property=TIME_NOW pattern=hh:mm:ss a z / ant:format property=MMdd pattern=MMdd / /ant:tstamp /project - 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]
RE: Pb with namespaces in Ant 1.6 official
Does this warrant a 1.6.1? I'm actually quite stuck because of this bug I've been making extensive use of namespaces in my builds based on beta1! --DD -Original Message- From: Peter Reilly [mailto:[EMAIL PROTECTED] Thanks for the report. Yes, the handling of the ant namespace is incorrect due to a change between 1.6beta3 and 1.6.0. I have placed a fix now. Peter Dominique Devienne wrote: Just starting updating from Ant 1.6 beta1 to 1.6 official, and I've having a bad surprise. It seems there's a problem handling the default Ant namespace when explicitly specified, or when used as the default namespace, at least for the tstamp task. Have I doing something wrong??? --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pb with namespaces in Ant 1.6 official
The easiest fix until 1.6.1 is to remove the antlib:org.apache.tools.ant declarations. Peter Dominique Devienne wrote: Does this warrant a 1.6.1? I'm actually quite stuck because of this bug I've been making extensive use of namespaces in my builds based on beta1! --DD -Original Message- From: Peter Reilly [mailto:[EMAIL PROTECTED] Thanks for the report. Yes, the handling of the ant namespace is incorrect due to a change between 1.6beta3 and 1.6.0. I have placed a fix now. Peter Dominique Devienne wrote: Just starting updating from Ant 1.6 beta1 to 1.6 official, and I've having a bad surprise. It seems there's a problem handling the default Ant namespace when explicitly specified, or when used as the default namespace, at least for the tstamp task. Have I doing something wrong??? --DD - 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]
Re: ant 1.6.1 [was: Pb with namespaces in Ant 1.6 official]
Dominique Devienne wrote: Does this warrant a 1.6.1? I'm actually quite stuck because of this bug This bug is impacting the most salient feature of ant 1.6.0, in the core of ant, so it is important. Do we want to fix other bugs in 1.6.1 ? What do you think ? Dominique : can you use a patched version of ant 1.6.0 until we provide an official new release ? Antoine I've been making extensive use of namespaces in my builds based on beta1 --DD -Original Message- From: Peter Reilly [mailto:[EMAIL PROTECTED] Thanks for the report. Yes, the handling of the ant namespace is incorrect due to a change between 1.6beta3 and 1.6.0. I have placed a fix now. Peter Dominique Devienne wrote: Just starting updating from Ant 1.6 beta1 to 1.6 official, and I've having a bad surprise. It seems there's a problem handling the default Ant namespace when explicitly specified, or when used as the default namespace, at least for the tstamp task. Have I doing something wrong??? --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Namespaces in Ant
On Monday 05 May 2003 20:20, J.Pietschmann wrote: peter reilly wrote: I would agree with most of what Nicola says. I think that XML ns is a heavy solution for name clashing of names defined in a antlib. Moreover I do not think that the antlib needs to define a qualified name. The prefix attribute idea of the property/ task could be used - even with the current typedef/ command. typedef resource=net/sf/antcontrib/antcontrib.properties prefix=antcontrib/ Hm. How do you ensure that prefixes wont clash? The build script author has control over the prefixes. This also pretty much rules out validation or schema-directed editing with a standard tool. True. Peter
Re: Namespaces in Ant
Nicola Ken Barozzi wrote:
This seems interestig, and brings up what XML namespaces can be used for.
XML namespaces are indented to disambiguate short local element
and attribute names. Any sematic associated to XML namespaces
beside this has to be weighted carefully.
Lets take an example. There are two projects, Foo and Bar,
each providing a taske, lets call them foo and bar
respectively. Both tasks take a part child, by coincidence.
Of course, because the projects act uncoordinated, the part
child element has a different semantic. In order to make this
clearer, let's say the Foo part takes an optional mumble
child while the Bar part takes three mandatory xonx
children.
Someone finds both the foo and the bar task exciting and
wants to use both in an Ant build file. No problem so far:
because ot the way Ant elements get their child elements and
create associated Java objects, this should work.
Now said someone got a super-duper schema directed XML editor
and wants to use it for editing the build.xml file. He asks
all projects for a schema (DTD, XSD, RNG, whatever) for this
purpose and merges them in order to get a schema for his build
file. At this point the two part elements are likely to clash
(at least for DTDs, where element names are global). While
it is possible to merge the content models so that part now
takes either an optional mumble or three xonx children, this
would allow the user to put xonx childre into the part of
the foo task. This is only a minor inconvenience for most
people, but an unthinkable horror for true purists.
Introduce namespaces: the Foo projects names its namespace
http://www.fooproject.org/anttask; while the Bar project uses
URI:bar or whatever. For the XML parser it is only really
important that two different strings are used. You see, the
longer the strings the less tha chance they will clash, and
they probably won't clash if they start with the URLs of the
project's homepages (the intent behind the recommendation to
use URLs, because it's the closest thing to a global registry
you can get short of actually creating a global registry).
Anyway, because the expanded names of the part elements are
now {http://www.fooproject.org/anttask}part; and {URI:bar}part
respectively they obviously no longer clash.
BTW you can write this as
target name=foo
foo xmlns=http://www.fooproject.org/anttask;
part
mumble
/part
/foo
bar xmlns=URI:bar
partxonx/xonx/xonx//part
/bar
target
or as
target name=foo
xmlns:foo=http://www.fooproject.org/anttask;
xmlns:bar=URI:bar
foo:foo
foo:part
foo:mumble
/foo:part
/foo:foo
bar:bar
bar:partbar:xonx/bar:xonx/bar:xonx//bar:part
/bar:bar
target
take your pick (if you think the foo and bar prefixes are too
long, use a and b instead, it doesn't matter).
So far, the namespace names should only be different for different
projects, so why is it dangerous to associate some semantic with it,
like letting them point to a jar file? The problem is again that
general purpose XML tools, like the above mentioned super-duper XML
editor may associate their own semantics with the namespace, like
how to auto-format certain elements. This information will be stored
in some config files, and it requires that the namespace name is
the same until the semantics of the elements in it have changed
enough that it warrants assigning a new namespace name.
Summary:
1. XML namespaces are there to facilitate aggregation of XML adhering
to schemas (content models) of different, uncoordinated origin.
2. XML Namespaces should be used in a way that no end user action
can result in two namespace names becoming unintentionally the
same.
3. XML Namespace names should preferably be assigned by the people
or project which specifies the semantics of the XML elemnets and
attributes therein.
4. XML Namespace names should be kept unchanged until a change of
the semantic of the elements warrants a change.
5. Good tools should not monopolize XML namespace syntax for its
own semantics.
The schema directed editor should provide an example hoe tools
can take advantage of XML namespaces: use them as a key into a
DB/config to get it's own associated semantic.
In particular for Ant/Antlib I can imagine that each library
provides a factory object associated to the XML namespace for
the library.
The FOP parser uses such a two stage lookup: first the namespace
is used to get a factory object from a hash table, then the factory
is used with the local XML element name to create a Java object
which is inserted into the FO tree. The hash table with the factories
is initialized at startup, the associations between namespace name
and factory class name is read from a Services file. Want to add
a FOP extension? Get the default Services file, add a line with
your namespace-to-factoryclassname mapping put it into the jar with
all the classes and drop the jar as first into the classpath. If the
user wants to use multiple extensions,
Re: Namespaces in Ant
Costin Manolache wrote, On 03/05/2003 16.14: Nicola Ken Barozzi wrote: ... I think that XML namespaces really make things much more difficult to write and understand. One thing I don't like in Jelly is just this use of namespaces, where all scripts seem cluttered and simply difficult to read. I agree - in most small build files, with few libraries and no conflicting names it is simpler to not use ns. I don't think anyone is sugesting to make ns required for 1.6 ( we need to keep backward compat ). Even for antlibs, I think the ns should be an option. Ok, but namespaces are a heavy way of doing separation. ATM I don't think that that it's good if they are not always used (and I don't like much to see them used). This is why I favor that Antlibs work similarly to java imports, where there are no prefixes *except* when specified, and then I would *not* make prefixes free, but use the standars full name for that Antlib. Can you give an example ? Sure. Every antlib descriptor should contain not only the names of the tasks but also the namespace of the antlib. When Ant loads the tasks, it does it with two names, so that the task can be called with short or the fully qualified name. Example: antlib location=antcontrib.jar/ !-- I can call it on both ways -- if/ antcontrib.if/ In the case that a library declares a task with the same name of one already loaded, Ant should load the fully qualified name version and change the short-name version to output an error about clashing names. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
