Re: [VOTE] macrodef - do attributes as properties or substitutions
My (non-committer) oppion coincides with Stefan here, with a slight
preference for
@{x}
because it looks like put the substitution AT this location when I
read it to myself.
However I can understand that $ escaping is already done and well tested
so reusing that code has value. $(x) is good enough for me if that is a
priorety (you will note I am not offering to code @{x} :) ).
(or we could make it (:x:) so that mozilla can turn them all into
smilies when we paste it to the list :) )
-Gus
Stefan Bodewig wrote:
On Mon, 17 Nov 2003, peter reilly [EMAIL PROTECTED] wrote:
OK, how do we want to implement macrodef attributes:
current
[ ] as textual substitution~ 4
[ ] as real Ant properties ~ 2
undecided ~ 1
only counting the binding votes would result in 1/2/1, so neither
choice has received enough binding votes by now. Dominique, Jose
Alberto and Steve know that I'm not ignoring their votes, but
technically they are non-binding.
If macrodef attribute are to be implements as substitutions, what
should be the notation? (where x is the attribute name)
[ ] as ${x} (look like ant properties)
-1, too confusing.
[ ] as @x
-1 doesn't work if you want to concatenate an expanded attribute and
some other text, i.e.
attribute name=foo/
attribute name=foobar/
is @foobarbaz the expansion of foo plus the literal text barbaz or is
it the attribute foobar plus the literal text baz - or something
completely different?
[ ] as ${attribute:x}
-1 - still looks too much like a property and collides with existing
properties that's name starts with attribute: (unlikely but
possible).
[ ] as $(x)
[ ] as @{x}
either one works for me - as well as [EMAIL PROTECTED]
Stefan
-
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]
DO NOT REPLY [Bug 24806] New: - Add merge as valid option for vssget writablefiles attribute
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24806. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24806 Add merge as valid option for vssget writablefiles attribute Summary: Add merge as valid option for vssget writablefiles attribute Product: Ant Version: 1.6Beta Platform: PC OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Optional Tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] The merge option would be extremely helpful to our group. We currently have ant scripts that pull to empty directories for nightly builds and for release builds. These scripts pull from many different components in our VSS tree. It would be helpful if we could use the same ant scripts to support our development enviroment by pulling from all these different components and merging where appropriate. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: My itches with local (was Re: [VOTE] local for 1.6)
On Tue, 18 Nov 2003, peter reilly [EMAIL PROTECTED] wrote: On Tuesday 18 November 2003 15:53, peter reilly wrote: me) more natural. However, I can see benefits ;- my code may not Opps that should of course be the code and not my code. Don't worry 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: In case you haven't seen this yet
On Tue, 18 Nov 2003, Alex Kipman [EMAIL PROTECTED] wrote: You will note Brent re-wrote the entire section about Why not Ant/NAnt, and what you see on this link is what you will see printed on the book when it hits your local bookstore. Thanks Alex, both for the pointer and for the nudging into the right direction you've done. Stefan -- http://stefanbodewig.blogger.de/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] local for 1.6
From: Steve Loughran [mailto:[EMAIL PROTECTED] It would seem better to get this right before we ship, as then things stay broken. Holding stuff over to 1.7 lets us experiment with the model more before we actually ship. But I agree, without it, macrodef is more limited. Well, it is no more or less limited than cutting and pasting tasks. And if the implementation is circumscribed enough, it should be able to be added as an add-on on a point-release of 1.6. I.e., we do not need to wait for a year to get it. Jose Alberto - 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: [VOTE] macrodef - do attributes as properties or substitutions
From: Gus Heck [mailto:[EMAIL PROTECTED]
My (non-committer) oppion coincides with Stefan here, with a slight
preference for
@{x}
because it looks like put the substitution AT this location when I
read it to myself.
Actually if we go for reading value, the advantage of @{x} notation is
that sounds like AT(tribute) x :-)
I think I can live with that.
Jose Alberto
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: macrodef - do attributes as properties or substitutions
From: Steve Cohen [mailto:[EMAIL PROTECTED] I have used a similar idea with a build file full of template targets that use a fileset reference. The reference must be defined globally or the build will break, but only some of the users of the file of templates actually need the reference. So, since references can be overridden, the solution is, similar to Stefan's, fileset id=globaltlds dir=. include name=no.real.file/ /fileset Later, a user of this buildfile can redefine the globaltlds reference, if it needs to, to something real. Yeah, this sounds a lot like the Null Object idiom you can read about in Martin Fowler's Refactoring book. OTOH, now that there is the isreference condition, a cleaner approach might be to conditionaly execute the target only of the reference is defined at all, rather than defining a null/dummy one. Probably not applicable all the time, but still. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: macrodef - do attributes as properties or substitutions
True, that was from the 1.4/1.5 days. -Original Message- From: Dominique Devienne [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 8:52 AM To: 'Ant Developers List' Subject: RE: macrodef - do attributes as properties or substitutions From: Steve Cohen [mailto:[EMAIL PROTECTED] I have used a similar idea with a build file full of template targets that use a fileset reference. The reference must be defined globally or the build will break, but only some of the users of the file of templates actually need the reference. So, since references can be overridden, the solution is, similar to Stefan's, fileset id=globaltlds dir=. include name=no.real.file/ /fileset Later, a user of this buildfile can redefine the globaltlds reference, if it needs to, to something real. Yeah, this sounds a lot like the Null Object idiom you can read about in Martin Fowler's Refactoring book. OTOH, now that there is the isreference condition, a cleaner approach might be to conditionaly execute the target only of the reference is defined at all, rather than defining a null/dummy one. Probably not applicable all the time, but still. --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: [VOTE] macrodef - do attributes as properties or substitution s
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
From: Gus Heck [mailto:[EMAIL PROTECTED]
My (non-committer) oppion coincides with Stefan here, with a slight
preference for @{x}
because it looks like put the substitution AT this location when I
read it to myself.
Actually if we go for reading value, the advantage of @{x} notation is
that sounds like AT(tribute) x :-)
I think I can live with that.
Unlike Jose Alberto, I think it's a 'good' thing than referencing an
declared attribute of a macrodef in its body/impl resembles the XSLT
referencing of a attribute of the current XML element!
The similarities are striking, and the syntax is well known and clearly
documented. The macrodef attribute *will* be an XML element attribute
when it's used actually!!!
[EMAIL PROTECTED] feels very natural, and avoids any confusion with ${x}.
It can be easily escaped using the double symbol people like,
so that {@@x} passes thru as the [EMAIL PROTECTED] literal. (After all, I don't
think it's valid to have an XML attribute starting with an @, so
it's free of conflict too.)
The point is not to resemble the existing notation for dereferencing Ant
properties, since that's what it's supposed to be distinct from, which is
why @{x} feels wrong to me (and looks ugly IMHO ;-).
The point is to use a widely used notation for a widely similar purpose,
i.e. the XSLT notation, which as I noted above is so similar to the semantic
of what's being done.
I'm not a committer and all, but to me [EMAIL PROTECTED] is the clear choice for
macrodef attribute dereferencing. I'm sure others will disagree ;-)
But no one can escape getting my opinion on the matter ;- --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] macrodef - do attributes as properties or substitutions
From: Dominique Devienne [mailto:[EMAIL PROTECTED]
Unlike Jose Alberto, I think it's a 'good' thing than
referencing an declared attribute of a macrodef in its
body/impl resembles the XSLT referencing of a attribute of
the current XML element!
The similarities are striking, and the syntax is well known
and clearly documented. The macrodef attribute *will* be an
XML element attribute when it's used actually!!!
Well just remember that in XSLT we are talking about XPATH.
The actual parameters here are @x (an attribute) or $x
(a variable) or x an element. The {} is just syntax sugar
so you can write expressions easily inside XSLT attribute values.
In XSLT you can write:
myelement param={concat(@name, '=', @value)}/
which results in the concatenation of the three values.
But you can also write that more verbose:
myelement
xsl:attribute name=param
xsl:value-of select=concat(@name, '=', @value)/
/xsl:attribute
/myelement
XSLT has a very specific syntax for variable/attribute names.
The point is not to resemble the existing notation for
dereferencing Ant properties, since that's what it's supposed
to be distinct from, which is why @{x} feels wrong to me (and
looks ugly IMHO ;-).
The point is to use a widely used notation for a widely
similar purpose, i.e. the XSLT notation, which as I noted
above is so similar to the semantic of what's being done.
Your proposal selection is not XPATH nor the XSLT expression language,
yes it has some simillarities, but on the other hand that may add to
confusion.
Jose Alberto
PS: my current choice is @{x} before was $(x), hum
maybe should pick @(x) humm, oh well, somebody, just pick
something!!!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] macrodef - do attributes as properties or substitutions
Actually if we go for reading value, the advantage
of @{x} notation is
that sounds like AT(tribute) x :-)
Yeah, add another non-committer vote for @{x}...
__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] macrodef - do attributes as properties or substitution s
On Wednesday 19 November 2003 16:13, Ken Gentle wrote:
Just to be contrarian (but not really), the [EMAIL PROTECTED] notation
looks weird to
me! @{x} is familiar enough, although I can't say why at the moment --
oh, yeah, doesn't Perl have a similar construct?
If not today then some day.
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] macrodef - do attributes as properties or substitution s
On Wed, 19 Nov 2003, Ken Gentle [EMAIL PROTECTED] wrote:
@{x} is familiar enough, although I can't say why at the moment
It's a grid bug (or a xorn, dunno without colors) between a moat and a
fountain with an adventurer/human/elf next to it.
8-)
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] macrodef - do attributes as properties or substitution s
LOL!
This got the office rolling on the floor.
-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 19, 2003 11:40 AM
To: [EMAIL PROTECTED]
Subject: Re: [VOTE] macrodef - do attributes as properties or
substitution s
On Wed, 19 Nov 2003, Ken Gentle [EMAIL PROTECTED] wrote:
@{x} is familiar enough, although I can't say why at the moment
It's a grid bug (or a xorn, dunno without colors) between a moat and a
fountain with an adventurer/human/elf next to it.
8-)
Stefan
-
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]
DO NOT REPLY [Bug 24837] New: - Availability of VB6 tasks for ant
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24837. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24837 Availability of VB6 tasks for ant Summary: Availability of VB6 tasks for ant Product: Ant Version: 1.5.4 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Optional Tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Maybe a slightly odd request! I use Java at home (among other things) and VB6 at work. I'm fed up of with the lack of decent tools for VB6 compared to what is available for other languages. Has anyone written a task that will automate VB6 builds and deployments (and possibly unit tests via vbUnit3)? I would be quite happy to write the Ant Tasks myself then contribute them to the main tree if it was felt that they were suitable, but I thought I'd check here first before getting cracking on it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
