the addition
of a DynamicConfiguratorNS interface to a later release, thus the
interface could be designed properly from the start (if there is such a
thing ;-) ).
Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de
Am 12.12.2003 um 15:40 schrieb Peter Reilly:
Christopher Lenz wrote:
Personally, I prefer DOM style as it is higher-level. The
qualifiedName parameter makes sense (well, sort of) when you can
enable/disable namespace support. When namespace support is always
enabled (as it is in Ant 1.6
be passed in instead?
public interface NamesapceContext {
public String getPrefix(String namespaceURI);
public String getURI(String namespacePrefix);
}
What do you think?
Chris
-Original Message-
From: Christopher Lenz
To: Ant Developers List
Sent: 12/12/2003 4:12 AM
Subject: Re
Am 12.12.2003 um 13:44 schrieb Peter Reilly:
Christopher Lenz wrote:
Same here. Proposed interface:
public class DynamicConfiguratorNS {
public Object createDynamicElement(
String namespaceURI,
String prefix,
String localName);
public void setDynamicAttribute
?
--
Christopher Lenz
/=/ cmlenz at gmx.de
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
/
XmlNamespaceSupport
Cheers,
Chris
--
Christopher Lenz
/=/ cmlenz at gmx.de
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Peter reilly wrote:
The rule is as is in the ant namespace documentation, opps
the to be written documentation, is that
if the element name is in ant's xmlns, then
the componentname of the element is the local name,
otherwise it is uri:localname.
This is to be backward compatible with previous
Peter reilly wrote:
On Fri, 2003-11-28 at 11:54, Christopher Lenz wrote:
Peter reilly wrote:
The rule is as is in the ant namespace documentation, opps
the to be written documentation, is that
if the element name is in ant's xmlns, then
the componentname of the element is the local name,
otherwise
Hi Stefan,
sounds cool. Some comments inline:
Stefan Bodewig wrote:
Hi,
I've just added a utility class to CVS HEAD that can be used to turn
nested content into a DOMFragment (not necessarily a tree). I.e., if
you use it as your nested element like
public void addContext(XMLFragment f)
you
Stefan Bodewig wrote:
On 27 Nov 2003, Stefan Bodewig [EMAIL PROTECTED] wrote:
On Thu, 27 Nov 2003, Christopher Lenz [EMAIL PROTECTED] wrote:
So the namespace URI and the local name are currently actually
passed to the DynamicConfigurator in the form
namespace-uri:local-name?
Actually, I thought so
Christopher Lenz wrote:
Stefan Bodewig wrote:
On 27 Nov 2003, Stefan Bodewig [EMAIL PROTECTED] wrote:
On Thu, 27 Nov 2003, Christopher Lenz [EMAIL PROTECTED] wrote:
So the namespace URI and the local name are currently actually
passed to the DynamicConfigurator in the form
namespace-uri:local-name
Stefan Bodewig wrote:
On Thu, 27 Nov 2003, Christopher Lenz [EMAIL PROTECTED] wrote:
Any reason why the introspection doesn't look for that interface
directly, instead of XMLFragment?
XMLFragment doesn't implement DocumentFragment, it just builds one.
Ah, I hadn't actually looked at the code
;-) ), and I can't think
of many use cases for this functionality. If neither the Ant core nor a
builtin Task requires this functionality, it shouldn't go in. But that's
just my opinion, and I may very well be missing something ;-)
--
Christopher Lenz
/=/ cmlenz at gmx.de
namespace processing to ignore attributes not in the
right namespace.
See above.
-chris
--
Christopher Lenz
/=/ cmlenz at gmx.de
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
It should be much more efficient (and probably simpler) to just traverse the
DOM and replace properties in-place:
public void replaceProperties(Node n) throws DOMException {
switch (n.getNodeType()) {
case Node.ATTR_NODE:
case Node.CDATA_SECTION_NODE:
case Node.TEXT_NODE:
Matt Benson wrote:
--- peter reilly [EMAIL PROTECTED] wrote:
For example:
project xmlns:antcontrib=antlib:net.sf.antcontrib
xmlns:acme=antlib:org.acme.anttasks
target name=show
antcontrib:if
antcontrib:or
antcontrib:equals arg1=yes arg2=${prop}/
Dominique Devienne wrote:
From: peter reilly [mailto:[EMAIL PROTECTED]
On Monday 17 November 2003 17:01, Dominique Devienne wrote:
So the NS for project and target does not matter?
Conceptually they are part of the Ant XML dialect to me,
so seeing them in no namespace at all seems weird??? --DD
If
Dominique Devienne wrote:
From: Christopher Lenz [mailto:[EMAIL PROTECTED]
Dominique Devienne wrote:
From: peter reilly [mailto:[EMAIL PROTECTED]
On Monday 17 November 2003 17:01, Dominique Devienne wrote:
So the NS for project and target does not matter?
Conceptually they are part of the Ant XML
peter reilly wrote:
There are some other issues, in ant 1.7 we hope to move
from staticly adding conditions, filters etc to using typedef/ for
them. Using the new namespace rules would mean that this is obvious.
For example:
antcontrib:if
antcontrib:or
antcontrib:equals arg1=a
peter reilly wrote:
On Wednesday 29 October 2003 12:06, peter reilly wrote:
On Wednesday 29 October 2003 10:42, Stefan Bodewig wrote:
On Fri, 24 Oct 2003, peter reilly [EMAIL PROTECTED] wrote:
ac:if
equals arg1=a arg2=${prop}/
then
blab ...
/then
else
blab..
Christopher Lenz wrote:
In an earlier thread I proposed the general rule that if a namespace'd
task or type defines the names of introspection-discovered elements,
those elements inherits the namespace from its parent.
Consider this pseudo task class:
MyTask {
addFoo(Bar foo
peter reilly wrote:
Note that introspection discovered elements are
in the ant:core namespace. This does make some
things a little difficult to use/explain:
ac:switch value=${foo}
ant:case value=bar
echo message=The value of property foo is bar /
/ant:case
ant:case
peter reilly wrote:
On Monday 20 October 2003 10:53, Christopher Lenz wrote:
peter reilly wrote:
Note that introspection discovered elements are
in the ant:core namespace. This does make some
things a little difficult to use/explain:
ac:switch value=${foo}
ant:case value=bar
echo
Stefan Bodewig wrote:
On Sun, 19 Oct 2003, Christopher Lenz [EMAIL PROTECTED] wrote:
The corresponding junit invocation does not specifiy the
includeantruntime attribute, which defaults to true. So the Ant
runtime should be included in the classpath. However, the
ant-launcher.jar doesn't seem
Hi Peter,
this looks really cool, but I'd suggest adding an attribute like
scope=local|global to the property task instead of adding a completely
new task.
-chris
peter reilly wrote:
I have written the code to support local properties.
While I was doing this, I realized that the attributes
of a
[EMAIL PROTECTED] wrote:
aha, with ssh-agent. That is the deamon which serves the right
passphrase/password for a server, right?
Exactly there is the problem (I think) - cvs opens a ssh (but not with
a command line interface) and I can´t type my passphrase in it.
It seems that ssh on your
Stefan Bodewig wrote:
Hi,
I just stumbled over findbugs[1] (via Cafe au lait) and ran it over
Ant's sources.
Some of the reported problems are non-issues, but it also detected
some things that checkstyle doesn't[2]. Some examples:
* BaseFilterReader line 88 should use instead of new String().
*
27 matches
Mail list logo
