Hi Christopher,
This is basicly the way I have implemented my proposed
change.
However there is one problem. At the moment we are
encouraging people to use typedef's to implement
conditions, filters etc however for 1.6, the std conditions
etc are not implemented in this way. For 1.7 we hope
to i
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);
}
This tas
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:
blab ...
blab..
Assuming Ant's core URI was assoc
On Wed, 29 Oct 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> On Wednesday 29 October 2003 10:42, Stefan Bodewig wrote:
>> On Fri, 24 Oct 2003, peter reilly <[EMAIL PROTECTED]> wrote:
>> >
>> >
>> >
>> > blab ...
>> >
>> >
>> > blab..
>> >
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:
> > It would be Ant's core URI if that was the URI of the default
> > namespace in the current scope and AntContrib's
On Wednesday 29 October 2003 10:42, Stefan Bodewig wrote:
> On Fri, 24 Oct 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > On Friday 24 October 2003 12:36, Stefan Bodewig wrote:
> >> On Thu, 23 Oct 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> >> >- should the uris of introspection discover
On Fri, 24 Oct 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> On Friday 24 October 2003 12:36, Stefan Bodewig wrote:
>> On Thu, 23 Oct 2003, peter reilly <[EMAIL PROTECTED]> wrote:
>> >- should the uris of introspection discovered nested elements
>> >be the same as the containing task
>
On Friday 24 October 2003 14:20, Jose Alberto Fernandez wrote:
> >
> > We would have to suppress loading this antlib.xml as all the
> > tasks and types would already have been loaded.
>
> Why keep the old mechanism? Just make the core load this antlib.xml.
> There is no need for the property files
> From: peter reilly [mailto:[EMAIL PROTECTED]
>
>
> On Friday 24 October 2003 12:36, Stefan Bodewig wrote:
> > On Thu, 23 Oct 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > >- should the default uri be "antlib:org.apache.tools.ant" to
> > > be consistent with other antlib uri's
> >
On Friday 24 October 2003 12:36, Stefan Bodewig wrote:
> On Thu, 23 Oct 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> >- should the default uri be "antlib:org.apache.tools.ant" to
> > be consistent with other antlib uri's
>
> it would only be consistent if there was an antlib.xml in the
On Thu, 23 Oct 2003, peter reilly <[EMAIL PROTECTED]> wrote:
>- should the default uri be "antlib:org.apache.tools.ant" to
> be consistent with other antlib uri's
it would only be consistent if there was an antlib.xml in the ant
package. I wouldn't mind having one that was restricted to
On Thursday 23 October 2003 15:42, Jose Alberto Fernandez wrote:
> Notice that following this path (not making locals visible) means
> that defined tasks will behave differently than java written
> tasks, more over it means that macrodef is not really the same as having
> the code in place. Ex:
Y
> From: peter reilly [mailto:[EMAIL PROTECTED]
>
> On Thursday 23 October 2003 13:44, Stefan Bodewig wrote:
> > On Thu, 23 Oct 2003, Jose Alberto Fernandez
> >
>
> This is my point. The should be visible for both or for none.
>
> >
> > You have a compelling example here
> >
> > >
> > > ${p
On Thursday 23 October 2003 14:09, Stefan Bodewig wrote:
> On Thu, 23 Oct 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > The following does the same ..
> >
> >
> >
> >
> >
> >
>
> It doesn't - if build.sysclasspath is a user property of course. Try
> it with ant -Dbui
Hi Costin,
The idea is to make local properties appear
like normal properties.
Using something like "local:foo" to designate
local properties could be possible, however one
whould need to handle scoping issues like:
? new local here ?
local:x is ${local:x}
local:y is
On Thu, 23 Oct 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> The following does the same ..
>
>
>
>
>
>
It doesn't - if build.sysclasspath is a user property of course. Try
it with ant -Dbuild.sysclasspath=only and you'll see.
Stefan
--
On Thursday 23 October 2003 13:39, Stefan Bodewig wrote:
> On Thu, 23 Oct 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > On Thursday 23 October 2003 12:31, Stefan Bodewig wrote:
> >> I haven't checked, but does you current implementation allow
> >> to shadow use properties? IMHO it shouldn't.
On Thursday 23 October 2003 13:44, Stefan Bodewig wrote:
> On Thu, 23 Oct 2003, Jose Alberto Fernandez
>
> <[EMAIL PROTECTED]> wrote:
> >> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> >>
> >> If you have several nested s, you'd have to check each level
> >> for a that was in place shadowing yo
On Thu, 23 Oct 2003, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:
>> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>> If you have several nested s, you'd have to check each level
>> for a that was in place shadowing your global value.
>
> But this is no more or less shadowing than me maki
On Thu, 23 Oct 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> On Thursday 23 October 2003 12:31, Stefan Bodewig wrote:
>> I haven't checked, but does you current implementation allow
>> to shadow use properties? IMHO it shouldn't.
>
> It does shadow user properties. The reason is to support
>
On Thu, 23 Oct 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> One example would be the way lisp does things.
>
> (let ((here (point))
> (ignore-depth 0)
> (tag-info context))
> bla.. bla..
> )
At least Emacs Lisp uses dynamic extent here, i.e. with
(setq here bar)
(let
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> On Thu, 23 Oct 2003, Jose Alberto Fernandez
> <[EMAIL PROTECTED]> wrote:
>
> > I cannot see what is the real situation that you were referring to,
> > when would you be in a case where you "find a
> task and will
> > have to search all po
On Thursday 23 October 2003 12:31, Stefan Bodewig wrote:
> On Wed, 22 Oct 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > On Wednesday 22 October 2003 15:04, Stefan Bodewig wrote:
> >> What is the benefit of making adhere to the scoping set
> >> up by ?
> >
> > The point is that all tasks includ
>
> > -----Original Message-
> > From: peter reilly [mailto:[EMAIL PROTECTED]
> > Sent: 22 October 2003 18:36
> > To: Ant Developers List
> > Subject: Re: Vote: for 1.6
> >
> > On Wednesday 22 October 2003 15:04, Stefan Bodewig wrote:
On Thu, 23 Oct 2003, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:
> I cannot see what is the real situation that you were referring to,
> when would you be in a case where you "find a task and
> will have to search all possible scopes for a local" what are all
> these possible scopes. Can yo
On Wed, 22 Oct 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> On Wednesday 22 October 2003 15:04, Stefan Bodewig wrote:
>> What is the benefit of making adhere to the scoping set
>> up by ?
>
> The point is that all tasks including see the local
> properties as normal properties.
So it is sup
to:[EMAIL PROTECTED]
> Sent: 22 October 2003 18:36
> To: Ant Developers List
> Subject: Re: Vote: for 1.6
>
>
> On Wednesday 22 October 2003 15:04, Stefan Bodewig wrote:
> > On 22 Oct 2003, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> > > I haven't made up
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> On 22 Oct 2003, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>
> > I haven't made up my mind on the feature itself
>
> OK, re-reading the description first, I don't like the
>
> ,
> | The value part of is optional, and the local
> proper
On Wed, 22 Oct 2003, Steve Loughran <[EMAIL PROTECTED]> wrote:
> How about we make the sshexec timeouts seconds instead of ms?
We are inconsistent with the timeout attribute between different
tasks. , , and use milliseconds,
uses seconds.
I understand that some people may migrate from to
a
I agree that doesn't work well with and some other
use cases.
I'm +1 on if we can keep it separated from , so the
behavior of doesn't change. I think it may be a good idea to
even throw an exception if some name is used with both local and property.
I wouldn't mind even a that is local + mod
On Wednesday 22 October 2003 15:04, Stefan Bodewig wrote:
> On 22 Oct 2003, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> > I haven't made up my mind on the feature itself
>
> OK, re-reading the description first, I don't like the
>
> ,
>
> | The value part of is optional, and the local
> | pro
Stefan Bodewig wrote:
On Wed, 22 Oct 2003, Antoine Lévy-Lambert <[EMAIL PROTECTED]>
wrote:
In the third beta we should have:
- a new xml-apis.jar (probably the one which is distributed with
Xerces-Java 2.5)
+1 - and replace it with an xml-commons version as soon as one is
available. Which may b
On 22 Oct 2003, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> I haven't made up my mind on the feature itself
OK, re-reading the description first, I don't like the
,
| The value part of is optional, and the local
| property may be set by a subsequent ,
| will only set it if the value is no
3 00:04
> To: 'Ant Developers List'
> Subject: RE: Vote: for 1.6
>
>
> Since I am not a commiter, my vote won't count, but I am +1
> for this. It solves my original problem perfectly.
>
> -- Larry
>
> > -Original Message-
> > From:
On Wed, 22 Oct 2003, Antoine Lévy-Lambert <[EMAIL PROTECTED]>
wrote:
> In the third beta we should have:
> - a new xml-apis.jar (probably the one which is distributed with
> Xerces-Java 2.5)
+1 - and replace it with an xml-commons version as soon as one is
available. Which may be in 1.6.1.
> -
On Tue, 21 Oct 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> I would like to put the local property patch into ant 1.6.
I haven't made up my mind on the feature itself (will try to do so
today). If it's going to be included in 1.6 (and the BC problem says
it should), we must have a third beta
On Wed, 22 Oct 2003 01:35 am, peter reilly wrote:
> Hi all,
>
> I would like to put the local property patch into ant 1.6.
>
> Normally I would wait for 1.7 for this, but it has a big
> and (I think) beneficial impact on .
>
> The changes to macrodef are not Backward Compatible
> with the current i
Since I am not a commiter, my vote won't count, but I am +1 for this. It
solves my original problem perfectly.
-- Larry
> -Original Message-
> From: peter reilly [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 21, 2003 8:36 AM
> To: [EMAIL PROTECTED]
> Subject: Vote: for 1.6
>
>
> H
peter reilly wrote:
Hi all,
I would like to put the local property patch into ant 1.6.
I am 0 on this; my sole concern being with no RCs planned from now to
1.6 shipping, we dont have the beta testing scheduled to find details.
Normally I would wait for 1.7 for this, but it has a big
and (I think
39 matches
Mail list logo
