Re: DO NOT REPLY [Bug 22227] - available task should support references IMO

[Matt Benson]

My apologies for having missed this new condition. 
Thanks!

-Matt

--- [EMAIL PROTECTED] wrote:
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> 
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE
> AT
>
.
> 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=7
> 
> available task should support references IMO
> 
> [EMAIL PROTECTED] changed:
> 
>What|Removed
> |Added
>

>  Status|NEW
> |RESOLVED
>  Resolution|   
> |INVALID
> 
> 
> 
> --- Additional Comments From [EMAIL PROTECTED] 
> 2003-08-08 15:39 ---
> There is already a  Condition.


__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

beating the dead Ant 1.6 horse

[Matt Benson]

I know the quote is "there is no timeframe yet on this
release".  But is there a ballpark?  2003?  Some
particular half of 2004?

Thanks,
Matt

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

LineTokenizer

[Matt Benson]

Or you could just strike that last question... I get
it now.  :)

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

LineTokenizer

[Matt Benson]

Peter (Reilly):  I will direct this question to you. 
What is the purpose of the LineTokenizer class, and
how does it compare to java.io.BufferedReader?

Thanks,
Matt

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Retry task container pt2

[Matt Benson]

--- Peter Reilly <[EMAIL PROTECTED]> wrote:

> I think that we should wait for the ant 1.7.1 branch
> to
> be made.
> 
> The retry task container is similar to containers in
> ant-contrib (limit, outofdate, for and if).
> 
> There is actually a task called "relentless" that
> executes a sequence of nested tasks, retrying the
> sequence until all the tasks have succeeded.
> 

Should I wonder why the manpage of  does
not mention any retry capabilities?  :(

-Matt

> 
> Peter
> 
> 
> 
> On 5/17/07, Steve Loughran <[EMAIL PROTECTED]>
> wrote:
> > Kevin Jackson wrote:
> > > Hi all,
> > >
> > > Does anyone object to adding a retry task
> container to ant core?
> > >
> > > I've made a few alterations to the code I
> attached to the previous email.
> > >
> > > The only worry I have is if it's too
> 'workflowy', if you know what I mean.
> > >
> >
> > I'm happy-ish with it...its probably simpler if
> you only handle one
> > nested task (rather than a sequence), as people
> may have more
> > expectations of rollback in such a situation.
> >
> >
>
-
> > 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]
> 
> 



  

Park yourself in front of a world of choices in alternative vehicles. Visit the 
Yahoo! Auto Green Center.
http://autos.yahoo.com/green_center/ 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Retry task container pt2

[Matt Benson]

--- Peter Reilly <[EMAIL PROTECTED]> wrote:

> Actaully, I did not see the manual page ;-)
> I just looked at the code - and misread it 
> 
> It does not do what I said,
> the task just ignores any failures until
> the end and then throws an exception
> if any failed.
> 
> I guess the name of the task confused me.

That's okay, I was only trying to eliminate confusion
on the whole.  Sounds like a miniaturization of Ant's
basic keep-going option, no?

-Matt

> 
> Peter
> 
> 
> On 5/17/07, Matt Benson <[EMAIL PROTECTED]>
> wrote:
> >
> > --- Peter Reilly <[EMAIL PROTECTED]>
> wrote:
> >
> > > I think that we should wait for the ant 1.7.1
> branch
> > > to
> > > be made.
> > >
> > > The retry task container is similar to
> containers in
> > > ant-contrib (limit, outofdate, for and if).
> > >
> > > There is actually a task called "relentless"
> that
> > > executes a sequence of nested tasks, retrying
> the
> > > sequence until all the tasks have succeeded.
> > >
> >
> > Should I wonder why the manpage of 
> does
> > not mention any retry capabilities?  :(
> >
> > -Matt
> >
> > >
> > > Peter
> > >
> > >
> > >
> > > On 5/17/07, Steve Loughran <[EMAIL PROTECTED]>
> > > wrote:
> > > > Kevin Jackson wrote:
> > > > > Hi all,
> > > > >
> > > > > Does anyone object to adding a retry task
> > > container to ant core?
> > > > >
> > > > > I've made a few alterations to the code I
> > > attached to the previous email.
> > > > >
> > > > > The only worry I have is if it's too
> > > 'workflowy', if you know what I mean.
> > > > >
> > > >
> > > > I'm happy-ish with it...its probably simpler
> if
> > > you only handle one
> > > > nested task (rather than a sequence), as
> people
> > > may have more
> > > > expectations of rollback in such a situation.
> > > >
> > > >
> > >
> >
>
-
> > > > 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]
> > >
> > >
> >
> >
> >
> >  
>

> > Park yourself in front of a world of choices in
> alternative vehicles. Visit the Yahoo! Auto Green
> Center.
> > http://autos.yahoo.com/green_center/
> >
> >
>
-
> > 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]
> 
> 



   
Ready
 for the edge of your seat? 
Check out tonight's top picks on Yahoo! TV. 
http://tv.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

applyjava

[Matt Benson]

Example name for the task we've talked about before
but have not written for inclusion, the
counter-argument being that the correct thing to do
here would be write a custom task.  But there are Java
programs (which shall remain nameless) that are
ridiculously complicated to call API-style due to the
fact that they are meant to be invoked by means of a
main() method, period.  I can't say that I see a
reason we can't include such a task in the near
future... anyone offering a different opinion had best
speak up sooner than that.  ;)

-Matt


   
Be
 a better Heartthrob. Get better relationship answers from someone who knows. 
Yahoo! Answers - Check it out. 
http://answers.yahoo.com/dir/?link=list&sid=396545433

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: applyjava

[Matt Benson]

--- Dominique Devienne <[EMAIL PROTECTED]> wrote:

> On 5/17/07, Matt Benson <[EMAIL PROTECTED]>
> wrote:
> > Example name for the task we've talked about
> before
> > but have not written for inclusion, the
> > counter-argument being that the correct thing to
> do
> > here would be write a custom task.  But there are
> Java
> > programs (which shall remain nameless) that are
> > ridiculously complicated to call API-style due to
> the
> > fact that they are meant to be invoked by means of
> a
> > main() method, period.  I can't say that I see a
> > reason we can't include such a task in the near
> > future... anyone offering a different opinion had
> best
> > speak up sooner than that.  ;)
> 
> How does that relate to  or 

Re: svn commit: r537344 - /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition/ResourceContains.java

[Matt Benson]

--- Kevin Jackson <[EMAIL PROTECTED]> wrote:

> > Hi guys.  Sorry I've been having trouble keeping
> up
> > lately.  Saw this stuff but missed the intervening
> > discussion.  Started playing today with adding
> refid
> > support, etc., but after awhile it occurred to me
> that
> > we already had this covered, e.g.:
> >
> > 
> >   
> > 
> >  >
> >
>
xmlns="antlib:org.apache.tools.ant.types.resources.selectors"
> > />
> >   
> > 
> >
> > Note that this approach supports any resource type
> > right off the bat.  Actually with the suggested
> "add"
> > idiom,  should be rewritten as a
> > macrodef.  :|
> 
> Well that's definitely simpler than having a custom
> task in Java! I
> think that's probably the way to go as we already
> have the basic
> building blocks available.

Back to this... do we plan to replace
au:assertResourceContains with some usage of the
 selector as I demonstrated, then remove the
ResourceContains java condition?

-Matt

> 
> Kev
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



  

Park yourself in front of a world of choices in alternative vehicles. Visit the 
Yahoo! Auto Green Center.
http://autos.yahoo.com/green_center/ 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r540950 - in /ant: core/trunk/dist/ core/trunk/dist/lib/ sandbox/antlibs/debian/trunk/src/main/org/apache/ant/debian/ sandbox/antlibs/debian/trunk/src/tests/antunit/

[Matt Benson]

;)  I assumed that was accidental and removed them.

-Matt

--- Peter Reilly <[EMAIL PROTECTED]> wrote:

> Why are you adding the dist and dist/lib directories
> to
> source code code, they should only get
> created as part of the build process.
> 
> Peter
> 
> On 5/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Author: kevj
> > Date: Wed May 23 06:28:05 2007
> > New Revision: 540950
> >
> > URL:
> http://svn.apache.org/viewvc?view=rev&rev=540950
> > Log:
> > -can now install created package, missing md5 &
> more config
> >
> > Added:
> > ant/core/trunk/dist/
> > ant/core/trunk/dist/lib/
> > Modified:
> >
>
ant/sandbox/antlibs/debian/trunk/src/main/org/apache/ant/debian/ControlFile.java
> >
>
ant/sandbox/antlibs/debian/trunk/src/main/org/apache/ant/debian/ControlFileTask.java
> >
>
ant/sandbox/antlibs/debian/trunk/src/tests/antunit/build-test.xml
> >
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



   
Boardwalk
 for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's 
economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: LocationLogger

[Matt Benson]

--- Kevin Jackson <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> I've just had time to play around with this :
> 
>
http://issues.apache.org/bugzilla/show_bug.cgi?id=32897
> 
> It seems to work quite well producing the desired
> output etc.
> 
> Any problems putting this in 1.7.1?  Anyone else had
> chance to try it
> out (especially those who use emacs to properly test
> the -e mode?)
> 
> I'm +0 on adding it, but if someone objects...

My personal opinion:  +0

However, given Steve's stated need for some of the
content of this contribution in other loggers, and my
good experience with Kevin Greiner's fixcrlf filter,
I'd upgrade to a +0.5 or so.  :)

-Matt

> 
> Kev
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



  

Park yourself in front of a world of choices in alternative vehicles. Visit the 
Yahoo! Auto Green Center.
http://autos.yahoo.com/green_center/ 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Seeing log output when running tests with AntUnit

[Matt Benson]

--- [EMAIL PROTECTED] wrote:

>  >It's being saved to a log where you can make
> assertions about 
> >output text, using 
> assertion, which 
> >itself uses the the  condition
> 
> How would I print the content of that log?
> 
> >Maybe we could tweak antunit also print the buffer
> on an 
> >assertion failure, but generally I just run the
> target by hand 
> >when I want to see the output.
> 
> My issue is that from the test target I get this
> output:
> 
>   [antunit] Target: test-foo  caused an ERROR
>   [antunit] at line 9, column 15
>   [antunit] Message: condition satisfied
>   [antunit] took 0.031 sec
> 
> The test has a complex condition in it, it would be
> useful to get more
> output on what the condition evaluation is.
> 

Suggestions:
  1.  make use of au:assertTrue's message attribute.
  2.  decompose your condition as much as possible
(replace s with multiple assertions).

HTH,
Matt

P.S. these really seem like questions for the user
list.  :|

> paul
> >-Original Message-
> >From: ext Steve Loughran [mailto:[EMAIL PROTECTED]
> 
> >Sent: Monday, June 04, 2007 4:44 AM
> >To: Ant Developers List
> >Subject: Re: Seeing log output when running tests
> with AntUnit
> >
> >[EMAIL PROTECTED] wrote:
> >> Hello,
> >> 
> >> I've been trying to use AntUnit and cannot see a
> way to view the 
> >> typical Ant output of the Ant targets being
> tested. The only 
> >output is 
> >> that which AntUnit generates, describing the
> tests executed, 
> >etc. If a 
> >> test fails it is important to view the log of the
> steps that 
> >happened.
> >> 
> >> Can anyone suggest how AntUnit is expected to be
> used to access this 
> >> logging information?
> >> 
> >> Thanks
> >> 
> >> paul
> >> 
> >
> >It's being saved to a log where you can make
> assertions about 
> >output text, using 
> assertion, which 
> >itself uses the the  condition
> >
> >Maybe we could tweak antunit also print the buffer
> on an 
> >assertion failure, but generally I just run the
> target by hand 
> >when I want to see the output.
> >
> >
> >-steve
> >
>
>-
> >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]
> 
> 



   

Moody friends. Drama queens. Your life? Nope! - their life, your story. Play 
Sims Stories at Yahoo! Games.
http://sims.yahoo.com/  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Task for substringing?

[Matt Benson]

--- Kevin Jackson <[EMAIL PROTECTED]> wrote:

> Hi all,
> 
> In the project I'm working on I have a need to be
> able to substring an
> expanded property value
> 
> 
>  property="new">
> ${new}
> 
> -> 23
> 
> Is there a way of achieving this already?  Looking
> through the manual
> I don't see a way of doing this without using
> scriptdef + script
> language du jour and for my current project I cannot
> use that.
> 
> If there currently isn't a way of achieving this,
> then I can put
> something together for it (and get paid for it :)

Hi Kev-
  It seems like some combination of string resources,
tokens resource collections, and regex filters might
give you substringing capabilities.  Beyond that,
another idea that occurs to me is that, if you're
being paid to develop this... ;), PropertyHelpers have
been for quite some time in need of refinement as to
how a user can easily register a custom
PropertyHelper.  If we could ever get this off our
plate we could close e.g. the myriad requests for
nested property resolution.  How does this relate?  In
that it strikes me as a natural idea that there be a
custom PropertyHelper that implements the
substringing, defaulting, etc. extensions found in the
bash shell (probably came from some other shell but I
don't feel like researching the origin just to make my
point).

HTH,
Matt


> 
> Kev
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



   

Get the free Yahoo! toolbar and rest assured with the added security of spyware 
protection.
http://new.toolbar.yahoo.com/toolbar/features/norton/index.php

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PropertyHelper thoughts

[Matt Benson]

Thoughts inline:

--- Kevin Jackson <[EMAIL PROTECTED]> wrote:

> Hi all,
> 
> After throwing together a quick hack to support my
> substring
> properties use case, Matt suggested instead
> significant changes to the
> property helper class.

Sorry!  :)

> 
> After looking through the code this afternoon here
> are my thoughts on
> a possible way to implement a configurable
> propertyHelper
> 

A Project uses the PropertyHelper registered under the
ant.PropertyHelper reference, so the pluggability is
already supported.  Note additionally that the
existing PropertyHelper supports a PropertyHelper
delegate which, if set, will be given the opportunity
to resolve a given property.  Note also that
PropertyHelper is a class, so any delegate
PropertyHelper will itself support a delegate.  You
may now recognize the Chain of Responsibility pattern.
 :)  This feature was added by Costin Manolache, who
has since left us forever, so we'll get no help there.
 :(

> 1 - Make the current PropertyHelper pluggable and
> allow users to
> specify which one to use at cli
[SNIP]

Personally I do see value in being able to have
multiple PropertyHelpers in action, but as the
alternative already exists between chaining and
outright replacement that's neither here nor there. 
What is important here is that because the properties
"syntax" available in a given buildfile is completely
dependent on what PropertyHelper(s) is/are configured,
I think it's necessary that the mechanism for
registering a custom PH (by chaining or by
replacement) be available from within the buildfile,
and not so necessary that it be externally
configurable.

> 2 - Make a new task which is pluggable
> 
> This would allow users the same benefits as a
> pluggable
> propertyhelper, but as it's a task, it can be
> configured entirely via
> xml
> 
> This xml based config is perfect for my needs

To be honest, I'm not sure why we've not already
included a task to do the job.  I first experimented
with replacing the PropertyHelper like:




But I believe this ran into weird timing problems due
to how heavily the active PropertyHelper is used. 
This has been a couple of years ago, so I don't
remember perfectly.  :(  If this (still) doesn't work,
a specialized task might; a task would/could obviously
also be less verbose and error-prone.  A custom e.g.
"registerpropertyhelper" task could support chaining
and replacement by different options.

(I'm getting itchy to code this but am trying to
contain myself... :) )

Looking at the PropertyHelper code it might be useful
to add something like:

public void chain(PropertyHelper ph) {
  if (next == null) {
next = ph;
  } else {
next.chain(ph);
  }
}

Probably synchronization should also be added to all
relevant methods here.  Then 
could support different child elements: (root)? and
(chain)* .   would replace the ref'd
ant.PropertyHelper while each  element would
add its object to the root (including the preexisting
root PH if  not specified) via the new chain()
method.

> 
> 3 - Stick with my quick hack of a task and ignore
> the wider issues of
> how properties are handled
> 
> This is basically throwing in the towel with respect
> to building a
> decent solution :)

And you can do that too.  :|

> 
> I'd love to hear feedback from anyone who has
> modified the
> PropertyHelper (I guess via a task as there doesn't
> seem to be any
> other way of getting custom behaviour implemented)
> 
> What do you think with respect to how much effort is
> involved & what
> possible solutions exist? (I'm sure the 3 I listed
> are basically the
> tip of the iceberg)
> 

The solution I outlined above MAY work-- :) --and if
so, doesn't _seem_ to be that terribly complicated. 
Makes me wonder why we haven't already done it. 
Finally, note that the class-level javadoc in PH
begins with "NOT FINAL. API MAY CHANGE" so if some
much more sensible solution arises that includes
drastic modification to the current PH API, that would
be an option (subject to a vote IMO) as well.

Hoping for input from others besides myself.

-Matt

> Kev
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



 

The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PropertyHelper thoughts

[Matt Benson]

Urgh, looking over the PropertyHelper stuff, I wonder
if we shouldn't refactor it somewhat.  It seems to be
overly complex to allow full PropertyHelper delegates.
 It seems that we might be better off using a single
PropertyHelper (still replaceable) and adding Lists of
getPropertyResolvers and setPropertyResolvers.  One
obvious problem of the current implementation seems to
be that you can't do this:



  

  

${foo:1,1}

Because the PH that knows how to handle the extended
syntax wasn't around when "foo" was set and thus won't
know about the foo property (I could be wrong but this
is my impression of what the code is doing).  This
seems broken and extremely counter-intuitive to me.  I
am going to look into an extensive refactor of PH and
if we determine that necessitates 1.8, well, so be it.
 :|

-Matt

[SNIP]



   

Be a better Heartthrob. Get better relationship answers from someone who knows. 
Yahoo! Answers - Check it out. 
http://answers.yahoo.com/dir/?link=list&sid=396545433

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PropertyHelper thoughts

[Matt Benson]

--- Peter Reilly <[EMAIL PROTECTED]> wrote:

> On 6/14/07, Matt Benson <[EMAIL PROTECTED]>
> wrote:
> > Urgh, looking over the PropertyHelper stuff, I
> wonder
> > if we shouldn't refactor it somewhat.  It seems to
> be
> > overly complex to allow full PropertyHelper
> delegates.
> Yes it is overly complex.
> (and full of bugs - esp with regard to child
> projects)
> 
> >  It seems that we might be better off using a
> single
> > PropertyHelper (still replaceable) and adding
> Lists of
> > getPropertyResolvers and setPropertyResolvers.
> This would be the way to go.
> 
> Perhaps something like:
> 
> interface GetPropertyResolver {
> String resolve(Project a, String property);
> // return null if not resolved
> }
> 
> interface SetPropertyResolver {
> boolean setProperty(Project a, String property,
> String value)
> returns true if property consumed
> return false if not
> }

WRT the getPR interface, I am thinking something
exactly like this.  I'm not sure if we need any such
on the set.  Parsing properties for string expansion
is the other pluggable thing.  I'm thinking provide
interfaces for resolution and parsing, and register
delegates that are objects, check for instanceof at
runtime and add to the appropriate list, so a delegate
may implement either or both interfaces.  WDYT?

-Matt

> 
> Peter
> 
> >  One
> > obvious problem of the current implementation
> seems to
> > be that you can't do this:
> >
> > 
> > 
> >   
> > 
> >   
> > 
> > ${foo:1,1}
> >
> > Because the PH that knows how to handle the
> extended
> > syntax wasn't around when "foo" was set and thus
> won't
> > know about the foo property (I could be wrong but
> this
> > is my impression of what the code is doing).  This
> > seems broken and extremely counter-intuitive to
> me.  I
> > am going to look into an extensive refactor of PH
> and
> > if we determine that necessitates 1.8, well, so be
> it.
> >  :|
> >
> > -Matt
> >
> > [SNIP]
> >
> >
> >
> >
> >
>

> > Be a better Heartthrob. Get better relationship
> answers from someone who knows. Yahoo! Answers -
> Check it out.
> >
>
http://answers.yahoo.com/dir/?link=list&sid=396545433
> >
> >
>
-
> > 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]
> 
> 



  

Park yourself in front of a world of choices in alternative vehicles. Visit the 
Yahoo! Auto Green Center.
http://autos.yahoo.com/green_center/ 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PropertyHelper thoughts

[Matt Benson]

--- Dominique Devienne <[EMAIL PROTECTED]> wrote:

> On 6/14/07, Peter Reilly
> <[EMAIL PROTECTED]> wrote:
> > interface SetPropertyResolver {
> > boolean setProperty(Project a, String
> property, String value)
> > returns true if property consumed
> > return false if not
> > }
> 
> I don't understand the SetPropertyResolver aspect. I
> like the GetPR,
> although I'd call it PropertyEvaluator maybe, or
> PropertyExpander, but
> I don't get the Set part. How would that be used?
> The GetPR comes into
> play in a ${scheme:...} expansion, but how would the
> SetPR work? --DD
> 

On further reflection, the Set* interface does make
sense, but only as an extension to the Get* interface.
 This would be the correct way to set anything that
couldn't be stuffed into the basic String-to-Object
property map (whatever that might be) and would imply
that the entity in question could get anything it
could set.  This also implies that the existing
namespace concept that exists but is unused in
PropertyHelper needs to go away.  The
setter-that-can-get would parse its own
pseudo-namespace if applicable.  Since this would
extend the Get version, I would think it could wait
until the main two interfaces were handled.

-Matt

>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



 

8:00? 8:25? 8:40? Find a flick in no time 
with the Yahoo! Search movie showtime shortcut.
http://tools.search.yahoo.com/shortcuts/#news

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PropertyHelper thoughts

[Matt Benson]

--- Dominique Devienne <[EMAIL PROTECTED]> wrote:

> On 6/14/07, Matt Benson <[EMAIL PROTECTED]>
> wrote:
> > --- Dominique Devienne <[EMAIL PROTECTED]>
> wrote:
> > > I don't understand the SetPropertyResolver
> aspect.
> >
> > On further reflection, the Set* interface does
> make
> > sense, but only as an extension to the Get*
> interface.
> >  This would be the correct way to set anything
> that
> > couldn't be stuffed into the basic
> String-to-Object
> > property map (whatever that might be) and would
> imply
> > that the entity in question could get anything it
> > could set.  This also implies that the existing
> > namespace concept that exists but is unused in
> > PropertyHelper needs to go away.  The
> > setter-that-can-get would parse its own
> > pseudo-namespace if applicable.  Since this would
> > extend the Get version, I would think it could
> wait
> > until the main two interfaces were handled.
> 
> Sorry to be a bit thick, but I still don't
> understand. I don't want
> properties to be anything but Strings. We use
> references to refer to
> something else that Strings. I'm still not buying
> the SetPR given what
> I've read so far ;-) --DD
> 

Okay, I'll give you points for seeing the forest in
this case.  Here's Costin's commit message from the
initial add of PropertyHelper:


"Dynamic properties" and a bit more.

This is "slightly" different from embed - if dynamic
properties will be
accepted in 1.6, it is better to do it right. Embed
uses few hacks to
trick the ProjectHelper.

PropertyHelper includes all the code related with
property manipulation
from Project (cut&paste). I added a very simple hook
mechanism ( Filter/Valve
like ) for the most common operations.

The API is obviously far from final - someone who
really understand "user"
and "inherited" properties should review it and make
few changes.

In Project, all properties fields are private - so all
can be removed.
The methods related with properties will just delegate
to PropertyHelper.
>From a user point of view - no visible change (
hopefully :-). Even grant
will continue to work ( but won't be able to use the
new features ).

Benefits:
- cleanup of Project. Less code and better organised.
- Property handling will hopefully be cleaner too
- we get to add APIs for namespace support, and maybe
support non-string
properties ( JSP-EL like - that needs to be disussed,
but IMO it would
be very helpfull ). While refs are Objects, the main
distinction is imutability.

Also:
- apps embeding or extending ant can fully customize
_all_ aspects of
property processing, including ${} replacement and
even the syntax.
- it should be very easy to hook a different storage
mechanism ( i.e.
integrated with the embeding app, without requiring
copy of properties ).
- it should be possible to avoid copy when creating
execution frames
( by using a chain that keeps changes and delegates
getters ).
- dynamic properties support ( my original itch :-)


Whether object properties are desirable can be up for
debate.  We are planning here to massacre the existing
API, but for inertia's sake I would leave some things
intact, like the use of Hashtable as opposed to
Properties; that being the case it may be easier to
continue to support Object properties than to withdraw
that support.

Finally, take the toString: extension.  This is a
perfect example of a PropertyEvaluator implementation.
 What does it do?  It renders a ref as a String.  So
it may be that a StoringPropertyEvaluator would set an
Object reference on the Project created from a String
representation, no?  Again, this is something we could
keep in mind but leave unimplemented for the time
being.  :)

Finally, if any of the old-timers has any more
information on Costin's mention of "dynamic
properties" without my having to search the archives
(lazy), feel free.  :)

-Matt

>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



 

TV dinner still cooling? 
Check out "Tonight's Picks" on Yahoo! TV.
http://tv.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PropertyHelper thoughts

[Matt Benson]

--- Dominique Devienne <[EMAIL PROTECTED]> wrote:

> On 6/15/07, Peter Reilly
> <[EMAIL PROTECTED]> wrote:
> > > I don't get the Set part. How would that be
> used? The GetPR comes into
> > > play in a ${scheme:...} expansion, but how would
> the SetPR work? --DD
> 
> Thanks for the example Peter. That's what I was
> waiting for.
> 
> > There could be a number of uses for example:
> >
> > 
> > count="10"/>
> > 
> 
> Hmm, I notice you've used an id, so we have a
> reference here ;-)
> 
> >  classname="org.example.BeanPropertyResolver"
> >prefix="bean" (?)
> />
> 
> So far, so good, although I'd like to be able to
> have an antlib with a
> single property resolver, and have the prefix used
> for that antlib
> automatically be used as the custom PH prefix. In
> other words, I want
> to auto-magic xmlns:bean="antlib:..." to reserve the
> PH prefix bean
> for my PH (possibly even if the antlib doesn't
> declare one. Otherwise
> would could have a XML NS prefix mapping to an
> antlib, and a PH prefix
> mapping to something coming from elsewhere, which is
> confusing.)
> 
> > 
> 
> This is what I don't like... Property names have
> currently no "rules"
> as far as syntax, so first of all this is not BC,
> and we're talking BC
> at the build file level, not the API level, the
> former being even more
> important. And second of all, this would be better
> handled by a custom
> task, like .
> 
> So I contend that assignment (your SetPH) is better
> done in custom
> ways, using custom tasks, which is then completely
> BC.
> 
> > 
> >
> >
> >  Set the bean value property
> successfully!
> >
> > 
> 
> Here OTOH its an read access, a bit in disguise
> since the ${} is
> implicit in this context, and I'm all for it! The
> reason we need this
> is that you can't use a task in the particular
> context, thus the
> syntax extension to access *String* only *values* of
> *something*,
> which can be a pure property (string,string
> key/value pair) and an
> arbitrary *object* which can be resolved using a
> scheme/PH-specific
> *key* string.
> 
> So I still don't buy SetPH ;-)
> 
> And just like Stefan, let me finish that I'm also in
> favor of fixing /
> enhancing / redoing PH, or whatever is necessary,
> but only to extend
> the property dereference syntax (read access).
> 
> Overloading the meaning of  for write
> access to arbitrary
> "things" is not a good idea IMHO. --DD
> 

I am actively working on this as we speak, actually,
and I'm pleased so far with my results.  I actually
have a cut of PH with refactored get and parse
functionality working but I'm seeing other test
failures that I want to get resolved so I know I'm not
breaking anything

Anyway, I wanted to throw out a few thoughts: 
Consumers of the functionality will be pissed if we
break BC.  Looking over AntXtras source I see comments
to the effect that PH is broken, so I imagine users
would forgive us if we broke BC to replace something
clearly broken.  And, we always have the API not final
comments to fall back on.  We _could_ try to preserve
compatibility with the current code by adapting
chained PropertyHelpers to the various subinterfaces
(using reflection to determine which base extension
points have been overridden!?), but that sounds like a
nightmare, frankly.  One final observation is that if
we break BC without providing alternate means to
accomplish everything users might already have been
doing (i.e. removing property setting functionality or
allowing only Strings), this is where we could really
annoy people.  :)  I would not go so far as to say we
will alienate them, only annoy them.

I hope to analyze the current uses of PH in the wild
and possibly start an antlib to provide comparable
functionality in terms of the refactored API.

That said, it wouldn't be the first antlib I've hoped
to start and haven't (yet).  :|

-Matt

>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



   

Looking for a deal? Find great prices on flights and hotels with Yahoo! 
FareChase.
http://farechase.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PropertyHelper thoughts

[Matt Benson]

--- Dominique Devienne <[EMAIL PROTECTED]> wrote:

> On 6/15/07, Matt Benson <[EMAIL PROTECTED]>
> wrote:
> > I am actively working on this as we speak,
> actually,
> > and I'm pleased so far with my results.
> 
> FTR Matt, I still haven't read anything to convince
> me that write
> access via  is desirable, needed, and
> good. I'm not trying
> to put a damper on your efforts, but so far the use
> cases I've seen
> for "write" are better handled by custom tasks.

Okay, first to be more clear:  I determined that the
natural extension points for properties handling would
be, reading them, expanding them from a string (the
use case that kicked off this discussion), and setting
them.  I did and do recognize that changing how
properties are set was weird, and as such have still
not even written the interface for how that would
happen.  Even if the final group consensus is to allow
for them, I am putting them last, and who knows?  I
might not even be the one to implement them in the
event we do go forth with them.  :)

> 
> What about the <*ant> tasks? These "things" which
> are not string
> properties, how do they percolate to sub-Projects?
> We have clear
> semantic for properties and references passing, so
> it would be much
> clearer and "The Ant Way"(tm) to have them as
> references, manipulated
> using custom tasks, and passed using reference
> semantic, and which
> unlike properties are not fully compartmented
> between Projects, which
> the parent and child project share the same
> referenced-object.
> 

Here you've simplified "pluggable property setting" to
"supporting non-String properties" and I suppose
that's fair enough from a buildfile-only standpoint. 
But the current design of PropertyHelper allows for a
given property to be set as an arbitrary object via
Ant's API.  I think, even if we don't recognize that
we should allow a hook for setting properties, that
this is harmless enough, despite your well-founded
arguments regarding references.  That said, it's no
concern of mine if we reduce properties to Strings--it
would simplify some things, certainly--but the user
community might feel otherwise.  Then again, (1) if
we're already giving them breaking changes we can
certainly go whole-hog with those if we so choose, and
(2) I sent Wascally Wabbit from AntXtras (who seem to
be the greatest consumer of PropertyHelpers from the
list Peter sent out) a personal message inviting him
to this conversation and we still haven't seen him. 
I'll follow up with a similar message to the other
admin on the project in case he's on vacation or
something.  Meanwhile I'll try restricting properties
to strings and see if we break anything internal.

> Would installed PH instanced percolate to
> sub-Project automatically?

I'm not sure.  I think we need more discussion of
this:

> Because if they do, Peter's argument that the
> explicit declaration of
> the PH ensures BC falls flat if one uses "external"
> reusable build
> files which would happen to use the same syntax as
> the PH prefix
> installed in another build file. That would be bad
> encapsulation.
> 
> So the more I think about this, the more I feel it's
> wrong at several level.
> 

I don't necessarily agree that the PropertyHelper
should be externally configurable (via, I assume,
magic properties).  I think we'll be in better shape,
personally, to simply provide a reasonable set of
tasks to replace PropertyHelpers and add handling
delegates to the currently installed PH, all from
within the buildfile.  It's a similar argument to why
externally declared namespace prefixes are wrong, and
so I am confident you and I will (for once) be in
agreement on this point.

> Let's stick with read access. As toString:
> demonstrates already,
> what's to the right of the PH scheme doesn't have to
> reference a
> property name, so it's flexible enough. --DD
> 

Final thought wrt not allowing for setter delegates: 
Because we plan to continue to allow a user to install
an arbitrary subclass of PropertyHelper we would have
to make setXXX final operations to stop a determined
user from doing I-can't-foresee-what kind of things
with property setting.  Are we prepared to do this?

-Matt
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



  
___
You snooze, you lose. Get messages ASAP with AutoCheck
in the all-new Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_html.html

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PropertyHelper thoughts

[Matt Benson]

--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:

> On Sat, 16 Jun 2007, Matt Benson
> <[EMAIL PROTECTED]> wrote:
> 
> > Meanwhile I'll try restricting properties to
> strings and see if we
> > break anything internal.
> 
> We have had bug reports when some places in Ant
> assumed that all
> properties would be strings.

Funnily enough I did restrict Properties to Strings
and all the tests passed.  :)

> 
> One I could find with a quick search stems from the
> fact that system
> properties are ant properties as well and people
> pushed objects into
> system properties:
>
<http://issues.apache.org/bugzilla/show_bug.cgi?id=904>
> 

Actually I had already arrived back at leaving
Properties as objects for other reasons stay
tuned!

-Matt

> Stefan
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



   

Need a vacation? Get great deals
to amazing places on Yahoo! Travel.
http://travel.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PropertyHelper thoughts

[Matt Benson]

--- Peter Reilly <[EMAIL PROTECTED]> wrote:

> On 6/22/07, Dominique Devienne <[EMAIL PROTECTED]>
> wrote:
> > On 6/22/07, Stefan Bodewig <[EMAIL PROTECTED]>
> wrote:
> > > > Funnily enough I did restrict Properties to
> Strings
> > > > and all the tests passed.  :)
> > >
> > > You mean I didn't write a unit test when I fixed
> Bugzilla Issue 904?
> > > OK, what can I say? hmm, trying to come up with
> a cheap excuse, March
> > > 2001, ah yes, Ant 2 and all that.  I must have
> been too busy with
> > > politics.
> > >
> > > Actually your change would be totally unrelated
> to the bug in question
> > > which involved Ant assuming that System
> properties were all strings
> > > when copying them over to the Ant properties.
> >
> > Did I say that I want Ant properties to be Strings
> only?
> >
> > For System properties which are not Strings, they
> could be either (1)
> > ignored, with a warning or not, and (2) pushed in
> the reference map
> > instead (which a warning or not).
> They should be ignored.
> The Property javadoc page explicitly says that is it
> incorrect
> to use the underlying data structure directly .
> """
>  Because Properties inherits from Hashtable, the put
> and putAll
> methods can be applied to a Properties object. Their
> use is strongly
> discouraged
> """
> >
> > But for Ant properties, they should *always* be
> Strings!!! ;-) --DD

Can we keep this discussion afloat?  I've done a lot
of thinking on this issue over the past week and a few
days ago I had the epiphany that an Object-enabled
PropertyHelper is legitimate if we think of the
"Property" part of the name as having a double
meaning:  yes, it manages a Projects
Properties-as-in-Hashtable, but it
could be made to assist the IntrospectionHelper
further if it can be configured with delegates who
know how to generate an object from a notation.  Can
you see it coming?  We've arrived at my other pet
issue:  decoding a Resource from a String.  Change the
behavior of replaceProperties such that a string which
begins with a property and is completely consumed
after that property has been parsed returns the object
directly.  If some delegate returned e.g. a Resource,
the IH would first try to assign that directly before
reverting to its existing String configuration
behavior.  Once I made this realization I looked back
at Costin's comments and saw this was exactly where he
was headed.

Bearing all the above in mind, it seems useful at the
very least for property retrieval and string parsing
(related but separate concerns) to have the potential
to return an Object.  Given this, the concern over
System.properties having Objects shoved in, and the
momentum of PropertyHelper having at least
theoretically supported Object properties for all this
time, I don't think there's much reason to stop Object
properties cold, even if we vocally discourage their
use.

-Matt

> >
> >
>
-
> > 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]
> 
> 



   

Looking for a deal? Find great prices on flights and hotels with Yahoo! 
FareChase.
http://farechase.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PropertyHelper thoughts

[Matt Benson]

--- Dominique Devienne <[EMAIL PROTECTED]> wrote:

> On 6/22/07, Matt Benson <[EMAIL PROTECTED]>
> wrote:
> > Can we keep this discussion afloat?  I've done a
> lot
> > of thinking on this issue over the past week and a
> few
> > days ago I had the epiphany that an Object-enabled
> > PropertyHelper is legitimate if we think of the
> > "Property" part of the name as having a double
> > meaning:  yes, it manages a Projects
> > Properties-as-in-Hashtable, but it
> > could be made to assist the IntrospectionHelper
> > further if it can be configured with delegates who
> > know how to generate an object from a notation. 
> Can
> > you see it coming?  We've arrived at my other pet
> > issue:  decoding a Resource from a String.  Change
> the
> > behavior of replaceProperties such that a string
> which
> > begins with a property and is completely consumed
> > after that property has been parsed returns the
> object
> > directly.  If some delegate returned e.g. a
> Resource,
> > the IH would first try to assign that directly
> before
> > reverting to its existing String configuration
> > behavior.  Once I made this realization I looked
> back
> > at Costin's comments and saw this was exactly
> where he
> > was headed.
> >
> > Bearing all the above in mind, it seems useful at
> the
> > very least for property retrieval and string
> parsing
> > (related but separate concerns) to have the
> potential
> > to return an Object.  Given this, the concern over
> > System.properties having Objects shoved in, and
> the
> > momentum of PropertyHelper having at least
> > theoretically supported Object properties for all
> this
> > time, I don't think there's much reason to stop
> Object
> > properties cold, even if we vocally discourage
> their
> > use.
> 
> I'm sorry Matt, but I read your email carefully, and
> I'm not sure I
> got much out of it. Maybe it's doing C++ now that
> slows down my brain,
> but I'm not following. What's that IH connection you
> talk about? What
> string parsing?
> 

Okay, RuntimeConfigurable performs property
replacement on attribute strings and calls
IH.setAttribute with the substituted string.  PH uses
a basic set of parsing rules: ignore $$, ${ marks the
beginning of a property, the next encountered } marks
the end.  Because we know that nested property
evaluation is a highly requested property-related
capability, it becomes easy to see that the parsing
approach to use is a natural extension of property
handling.  The related interface is PropertyExpander. 
If the entire content of a string, e.g. "${src.dir}"
is a property, you can see there is a difference
between this type of attribute value as opposed to
"text ${property} text".

Let me divert the topic for a moment--the other of the
two most important property handling extension points
can be expressed with a PropertyEvaluator interface. 
A perfect example is Ant's built-in toString:refid
property "syntax".  Basically that's an example of a
custom PropertyEvaluator that interprets a string
beginning with "toString:".  Now imagine a
complementary custom property evaluator that evaluates
"refid:refid" to the Object reference.  Overload
IH.setAttribute to allow Object values.  Change
property replacement such that a string whose entire
contents are a property that evaluates to an Object,
returns the Object.  With the postulated refid:refid
PropertyEvaluator, "${refid:myclasspath}" would return
the Path at refid myclasspath.  If RuntimeConfigurable
calls the PH method that is capable of returning an
Object, then passes that Object (or String) to the
overloaded IH.setAttribute(), we have just rendered
all classpathref attributes obsolete; rather, any task
can support ref'd types in attributes without having
to support the foo|fooref paradigm.  If the attribute
isn't settable as the returned Object, convert the
Object to a String and pass it to the original
IH.setAttribute() implementation.

>From all this it actually becomes evident that the
parsing mechanisms are, or should be, secondary to
this issue.  :)

> Right now, property references in attributes or text
> elements are
> expanded to strings (which I like ;-) and then IH
> does it's thing and
> converts that string to whatever type the task or
> type needs. Clear
> separation of concerns. Furthermore, these property
> "de-references"
> can be mixed with litteral text and/or other
> property "de-references",
> so if de-refin

Re: svn commit: r549684 - /ant/core/trunk/src/main/org/apache/tools/ant/util/FileUtils.java

[Matt Benson]

--- Steve Loughran <[EMAIL PROTECTED]> wrote:

> Peter Reilly wrote:
> > On 6/22/07, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
> >> Author: mbenson
> >> Date: Thu Jun 21 20:10:20 2007
> >> New Revision: 549684
> >>
> >> URL:
> http://svn.apache.org/viewvc?view=rev&rev=549684
> >> Log:
> >> detect cs
> >>
> >> Modified:
> >>
>
ant/core/trunk/src/main/org/apache/tools/ant/util/FileUtils.java
> >>
> >> Modified: 
> >>
>
ant/core/trunk/src/main/org/apache/tools/ant/util/FileUtils.java
> >> URL: 
> >>
>
http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/util/FileUtils.java?view=diff&rev=549684&r1=549683&r2=549684
> 
> >>
> >>
>
==
> 
> >>
> >> ---
>
ant/core/trunk/src/main/org/apache/tools/ant/util/FileUtils.java
> 
> >> (original)
> >> +++
>
ant/core/trunk/src/main/org/apache/tools/ant/util/FileUtils.java
> 
> >> Thu Jun 21 20:10:20 2007
> >> @@ -15,7 +15,6 @@
> >>   *  limitations under the License.
> >>   *
> >>   */
> >> -
> >>  package org.apache.tools.ant.util;
> >>
> >>  import java.io.File;
> >> @@ -62,10 +61,13 @@
> >>  private static Random rand = new
> Random(System.currentTimeMillis()
> >>  +
> Runtime.getRuntime().freeMemory());
> >>
> >> -private static boolean onNetWare =
> Os.isFamily("netware");
> >> -private static boolean onDos =
> Os.isFamily("dos");
> >> -private static boolean onWin9x =
> Os.isFamily("win9x");
> >> -private static boolean onWindows =
> Os.isFamily("windows");
> >> +private static final boolean onNetWare =
> Os.isFamily("netware");
> >> +private static final boolean onDos =
> Os.isFamily("dos");
> >> +private static final boolean onWin9x =
> Os.isFamily("win9x");
> >> +private static final boolean onWindows =
> Os.isFamily("windows");
> >> +private static final boolean onMac =
> Os.isFamily("mac");
> >> +
> >> +private static boolean
> caseSensitiveFileSystem;
> >>
> >>  static final int BUF_SIZE = 8192;
> >>
> >> @@ -87,6 +89,23 @@
> >>   */
> >>  public static final long
> NTFS_FILE_TIMESTAMP_GRANULARITY = 1;
> >>
> >> +static {
> >> +try {
> >> +   File tmpdir = new
> File(System.getProperty("java.io.tmpdir"));
> >> +final String filename =
> "ant-casesensitivity.tst";
> >> +new File(tmpdir,
> filename).createNewFile();
> >> +new File(tmpdir,
> filename.toUpperCase()).createNewFile();
> >> +String[] files = tmpdir.list(new
> FilenameFilter() {
> >> +public boolean accept(File dir,
> String name) {
> >> +return
> filename.equalsIgnoreCase(name);
> >> +}
> >> +});
> >> +caseSensitiveFileSystem =
> files.length == 2;
> >> +} catch (IOException e) {
> >> +//default as well as possible:
> >> +caseSensitiveFileSystem = !onWin9x
> && !onWindows && 
> >> !onDos && !onMac;
> >> +}
> >> +}
> >>
> > Do we really want to do this each time ANT starts
> up?
> > Also, on Unix, one may have a mixture of
> filesystems, some of
> > which are case insensitive and some (well nearly
> all) not.
> > These may be mounted or symbolically linked to the
> anywhere in
> > the directory tree.
> > 
> 
> 
> Windows goes case sensitive if you mount samba FS or
> use clearcase. so 
> its a directory-by-directory feature

Good point.  Guess I will revert; I just hate doing
all these massive mods I'm working on with test
failures, and I suppose we can call it a bug in the OS
X JVM that files "foo" and "FOO" are considered
non-equal on a non-cs fs.  WinXP, in contrast, says
the files are equal.  Having only had my MBP for a
short while, I wasn't even aware the fs was non-cs
until yesterday.  I was kind of disappointed but from
what I see on the web I might end up sorry if I
convert to the cs fs from an app interoperability
perspective.  The fact remains we need a workaround
for this bug on non-cs filesystems where the JVM can't
give us the accurate info that "foo" and "FOO" are
equal.  Does anyone have any better ideas?  :(

-Matt

> 
> -steve
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



   
Ready
 for the edge of your seat? 
Check out tonight's top picks on Yahoo! TV. 
http://tv.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PropertyHelper thoughts

[Matt Benson]

--- Dominique Devienne <[EMAIL PROTECTED]> wrote:

> On 6/22/07, Matt Benson <[EMAIL PROTECTED]>
> wrote:
> > Let me divert the topic for a moment--the other of
> the
> > two most important property handling extension
> points
> > can be expressed with a PropertyEvaluator
> interface.
> > A perfect example is Ant's built-in toString:refid
> > property "syntax".  Basically that's an example of
> a
> > custom PropertyEvaluator that interprets a string
> > beginning with "toString:".  Now imagine a
> > complementary custom property evaluator that
> evaluates
> > "refid:refid" to the Object reference.  Overload
> > IH.setAttribute to allow Object values.  Change
> > property replacement such that a string whose
> entire
> > contents are a property that evaluates to an
> Object,
> > returns the Object.  With the postulated
> refid:refid
> > PropertyEvaluator, "${refid:myclasspath}" would
> return
> > the Path at refid myclasspath.  If
> RuntimeConfigurable
> > calls the PH method that is capable of returning
> an
> > Object, then passes that Object (or String) to the
> > overloaded IH.setAttribute(), we have just
> rendered
> > all classpathref attributes obsolete; rather, any
> task
> > can support ref'd types in attributes without
> having
> > to support the foo|fooref paradigm.  If the
> attribute
> > isn't settable as the returned Object, convert the
> > Object to a String and pass it to the original
> > IH.setAttribute() implementation.
> 
> This use case I do care about. But I always felt
> refid handling should
> be transparent to the tasks, and handled directly by
> the framework.
> hard to retrofit on the current infrastructure
> though I think. But
> where I'm getting at is that this particular example
> of yours, yes, I
> agree it's a valid use case, but I don't think that
> the way to enable
> it ;-)

I don't know; this is really seeming like a
best-of-both-worlds scenario to me.  Custom pluggable
extensions with the possibility of one that allows
nearly-automatic refid handling among other, some
unforeseeable, specializations.

> 
> I'm not overly fond of "special" handling in IH when
> the attribute
> value is "entirely" a property  deref, but I could
> live with that is
> others accept it. --DD
> 

My plan is to finish the changes I'm working on, along
with a companion antlib for testing, then attach the
core changes to a BZ issue so others can apply the
patch and test if they like; then we'll have something
more tangible to discuss.  Of course I hope for as
much discourse as possible to take place in the
interim.

-Matt

>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



   

Building a website is a piece of cake. Yahoo! Small Business gives you all the 
tools to get online.
http://smallbusiness.yahoo.com/webhosting 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PropertyHelper thoughts

[Matt Benson]

Hi all--
  Just wanted to be sure everyone who cares about this
thread noticed
http://issues.apache.org/bugzilla/show_bug.cgi?id=42736
and the companion antlib at
http://svn.apache.org/repos/asf/ant/sandbox/antlibs/props
.

br,
Matt

--- Matt Benson <[EMAIL PROTECTED]> wrote:

> 
> --- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> 
> > On 6/22/07, Matt Benson <[EMAIL PROTECTED]>
> > wrote:
> > > Let me divert the topic for a moment--the other
> of
> > the
> > > two most important property handling extension
> > points
> > > can be expressed with a PropertyEvaluator
> > interface.
> > > A perfect example is Ant's built-in
> toString:refid
> > > property "syntax".  Basically that's an example
> of
> > a
> > > custom PropertyEvaluator that interprets a
> string
> > > beginning with "toString:".  Now imagine a
> > > complementary custom property evaluator that
> > evaluates
> > > "refid:refid" to the Object reference.  Overload
> > > IH.setAttribute to allow Object values.  Change
> > > property replacement such that a string whose
> > entire
> > > contents are a property that evaluates to an
> > Object,
> > > returns the Object.  With the postulated
> > refid:refid
> > > PropertyEvaluator, "${refid:myclasspath}" would
> > return
> > > the Path at refid myclasspath.  If
> > RuntimeConfigurable
> > > calls the PH method that is capable of returning
> > an
> > > Object, then passes that Object (or String) to
> the
> > > overloaded IH.setAttribute(), we have just
> > rendered
> > > all classpathref attributes obsolete; rather,
> any
> > task
> > > can support ref'd types in attributes without
> > having
> > > to support the foo|fooref paradigm.  If the
> > attribute
> > > isn't settable as the returned Object, convert
> the
> > > Object to a String and pass it to the original
> > > IH.setAttribute() implementation.
> > 
> > This use case I do care about. But I always felt
> > refid handling should
> > be transparent to the tasks, and handled directly
> by
> > the framework.
> > hard to retrofit on the current infrastructure
> > though I think. But
> > where I'm getting at is that this particular
> example
> > of yours, yes, I
> > agree it's a valid use case, but I don't think
> that
> > the way to enable
> > it ;-)
> 
> I don't know; this is really seeming like a
> best-of-both-worlds scenario to me.  Custom
> pluggable
> extensions with the possibility of one that allows
> nearly-automatic refid handling among other, some
> unforeseeable, specializations.
> 
> > 
> > I'm not overly fond of "special" handling in IH
> when
> > the attribute
> > value is "entirely" a property  deref, but I could
> > live with that is
> > others accept it. --DD
> > 
> 
> My plan is to finish the changes I'm working on,
> along
> with a companion antlib for testing, then attach the
> core changes to a BZ issue so others can apply the
> patch and test if they like; then we'll have
> something
> more tangible to discuss.  Of course I hope for as
> much discourse as possible to take place in the
> interim.
> 
> -Matt
> 
> >
>
-
> > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> > 
> > 
> 
> 
> 
>
>

> Building a website is a piece of cake. Yahoo! Small
> Business gives you all the tools to get online.
> http://smallbusiness.yahoo.com/webhosting 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



  

Park yourself in front of a world of choices in alternative vehicles. Visit the 
Yahoo! Auto Green Center.
http://autos.yahoo.com/green_center/ 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PropertyHelper thoughts

[Matt Benson]

--- Peter Reilly <[EMAIL PROTECTED]> wrote:

> Hi Matt,
> this is pretty neat.

Thanks for the compliment, and for checking it out! 
:)
> 
> Just a couple of points:
> 1) the svn does not have the common external pointer
> defined

Oops--I figured out how to do it but forgot that I had
to commit properties changes, should be ok now.

> 2) how do the property helpers work with <*ant*> ?

I am currently working from the perspective that the
availability of a given PropertyHelper delegate is
crucial enough to warrant forcing explicit or imported
invocation.  I am willing to entertain differing
opinions, however.  :)

-Matt
> 
> Peter
> 
> 
> On 6/26/07, Matt Benson <[EMAIL PROTECTED]>
> wrote:
> > Hi all--
> >   Just wanted to be sure everyone who cares about
> this
> > thread noticed
> >
>
http://issues.apache.org/bugzilla/show_bug.cgi?id=42736
> > and the companion antlib at
> >
>
http://svn.apache.org/repos/asf/ant/sandbox/antlibs/props
> > .
> >
> > br,
> > Matt
> >
> > --- Matt Benson <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > --- Dominique Devienne <[EMAIL PROTECTED]>
> wrote:
> > >
> > > > On 6/22/07, Matt Benson <[EMAIL PROTECTED]>
> > > > wrote:
> > > > > Let me divert the topic for a moment--the
> other
> > > of
> > > > the
> > > > > two most important property handling
> extension
> > > > points
> > > > > can be expressed with a PropertyEvaluator
> > > > interface.
> > > > > A perfect example is Ant's built-in
> > > toString:refid
> > > > > property "syntax".  Basically that's an
> example
> > > of
> > > > a
> > > > > custom PropertyEvaluator that interprets a
> > > string
> > > > > beginning with "toString:".  Now imagine a
> > > > > complementary custom property evaluator that
> > > > evaluates
> > > > > "refid:refid" to the Object reference. 
> Overload
> > > > > IH.setAttribute to allow Object values. 
> Change
> > > > > property replacement such that a string
> whose
> > > > entire
> > > > > contents are a property that evaluates to an
> > > > Object,
> > > > > returns the Object.  With the postulated
> > > > refid:refid
> > > > > PropertyEvaluator, "${refid:myclasspath}"
> would
> > > > return
> > > > > the Path at refid myclasspath.  If
> > > > RuntimeConfigurable
> > > > > calls the PH method that is capable of
> returning
> > > > an
> > > > > Object, then passes that Object (or String)
> to
> > > the
> > > > > overloaded IH.setAttribute(), we have just
> > > > rendered
> > > > > all classpathref attributes obsolete;
> rather,
> > > any
> > > > task
> > > > > can support ref'd types in attributes
> without
> > > > having
> > > > > to support the foo|fooref paradigm.  If the
> > > > attribute
> > > > > isn't settable as the returned Object,
> convert
> > > the
> > > > > Object to a String and pass it to the
> original
> > > > > IH.setAttribute() implementation.
> > > >
> > > > This use case I do care about. But I always
> felt
> > > > refid handling should
> > > > be transparent to the tasks, and handled
> directly
> > > by
> > > > the framework.
> > > > hard to retrofit on the current infrastructure
> > > > though I think. But
> > > > where I'm getting at is that this particular
> > > example
> > > > of yours, yes, I
> > > > agree it's a valid use case, but I don't think
> > > that
> > > > the way to enable
> > > > it ;-)
> > >
> > > I don't know; this is really seeming like a
> > > best-of-both-worlds scenario to me.  Custom
> > > pluggable
> > > extensions with the possibility of one that
> allows
> > > nearly-automatic refid handling among other,
> some
> > > unforeseeable, specializations.
> > >
> > > >
> > > > I'm not overly fond of "special" handling in
> IH
> > > when
> > > > the attribute

Re: PropertyHelper thoughts

[Matt Benson]

Sorry for the lag... I was sort of wondering if anyone
else had anything at all to say here.  :)  Not even DD
is talking anymore so I guess it's down to you and me,
Peter, to decide where this is going:  do-ocracy and
all...

--- Peter Reilly <[EMAIL PROTECTED]> wrote:

> Thanks Matt,
> 
> I still think that we need to provide write access
> to the properties.
> 
> Writing to expressions is used a lot for example
> with JSF and EL.

Oh, that was your

example, right?

> 
> It may also be used to provide a "var:" prefix - to
> allow rewrittable
> properties without using the  name="me"/> work-around
> (see ant in action
> (http://www.manning.com/loughran/)),
> 

Given these usecases does it then follow that
PropertySetter extends PropertyEvaluator?  i.e. do you
agree we can call it "proper" that a PropertySetter
would know how to retrieve its own properties?  As for
consensus on the property setting extension point, I
think we stand at:

You (Peter): +1
DD: strong -0?
Me (Matt): +0

So I think we can do this unless DD clarifies his
position as being a full -1.  That's not his customary
behavior however.

-Matt

> Peter
> 
> 
> 
> 
> On 6/26/07, Matt Benson <[EMAIL PROTECTED]>
> wrote:
> >
> > --- Peter Reilly <[EMAIL PROTECTED]>
> wrote:
> >
> > > Hi Matt,
> > > this is pretty neat.
> >
> > Thanks for the compliment, and for checking it
> out!
> > :)
> > >
> > > Just a couple of points:
> > > 1) the svn does not have the common external
> pointer
> > > defined
> >
> > Oops--I figured out how to do it but forgot that I
> had
> > to commit properties changes, should be ok now.
> >
> > > 2) how do the property helpers work with <*ant*>
> ?
> >
> > I am currently working from the perspective that
> the
> > availability of a given PropertyHelper delegate is
> > crucial enough to warrant forcing explicit or
> imported
> > invocation.  I am willing to entertain differing
> > opinions, however.  :)
> >
> > -Matt
> > >
> > > Peter
> > >
> > >
> > > On 6/26/07, Matt Benson <[EMAIL PROTECTED]>
> > > wrote:
> > > > Hi all--
> > > >   Just wanted to be sure everyone who cares
> about
> > > this
> > > > thread noticed
> > > >
> > >
> >
>
http://issues.apache.org/bugzilla/show_bug.cgi?id=42736
> > > > and the companion antlib at
> > > >
> > >
> >
>
http://svn.apache.org/repos/asf/ant/sandbox/antlibs/props
> > > > .
> > > >
> > > > br,
> > > > Matt
> > > >
> > > > --- Matt Benson <[EMAIL PROTECTED]> wrote:
> > > >
> > > > >
> > > > > --- Dominique Devienne <[EMAIL PROTECTED]>
> > > wrote:
> > > > >
> > > > > > On 6/22/07, Matt Benson
> <[EMAIL PROTECTED]>
> > > > > > wrote:
> > > > > > > Let me divert the topic for a
> moment--the
> > > other
> > > > > of
> > > > > > the
> > > > > > > two most important property handling
> > > extension
> > > > > > points
> > > > > > > can be expressed with a
> PropertyEvaluator
> > > > > > interface.
> > > > > > > A perfect example is Ant's built-in
> > > > > toString:refid
> > > > > > > property "syntax".  Basically that's an
> > > example
> > > > > of
> > > > > > a
> > > > > > > custom PropertyEvaluator that interprets
> a
> > > > > string
> > > > > > > beginning with "toString:".  Now imagine
> a
> > > > > > > complementary custom property evaluator
> that
> > > > > > evaluates
> > > > > > > "refid:refid" to the Object reference.
> > > Overload
> > > > > > > IH.setAttribute to allow Object values.
> > > Change
> > > > > > > property replacement such that a string
> > > whose
> > > > > > entire
> > > > > > > contents are a property that evaluates
> to an
> > > > > > Object,
> > > > > > > returns the Object.  With the postulated
> > > > > > refid:refid
> > > > > > > PropertyEvaluator,
> "${refid:

Re: PropertyHelper thoughts

[Matt Benson]

--- Dominique Devienne <[EMAIL PROTECTED]> wrote:

> On 6/28/07, Matt Benson <[EMAIL PROTECTED]>
> wrote:
> > As for consensus on the property setting extension
> point,
> > I think we stand at:
> >
> > You (Peter): +1
> > DD: strong -0?
> > Me (Matt): +0
> 
> I'm +1 for the evaluator, and -0 for the setter,
> although I do see the
> need for a solution to properties being used in
> macros. I'm not

Properties used in macros--i.e., scoped aka "local"
properties?

> convinced the setter is the best approach, but I
> think setter is one
> possible solution indeed, and may be the easiest to
> implement.
> 

I don't know either, but it's on my radar.  :|

> I do respect do-ocracy ;-) --DD
> 

;)

-Matt

>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



   

Moody friends. Drama queens. Your life? Nope! - their life, your story. Play 
Sims Stories at Yahoo! Games.
http://sims.yahoo.com/  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r551592 - in /ant/core/trunk: WHATSNEW src/main/org/apache/tools/ant/types/optional/AbstractScriptComponent.java src/main/org/apache/tools/ant/types/optional/ScriptCondition.java src/t

[Matt Benson]

Steve or anyone else:  Let me know if you feel this
change is too risky; it just seemed intuitive to me.

br,
Matt

--- [EMAIL PROTECTED] wrote:

> Author: mbenson
> Date: Thu Jun 28 08:14:04 2007
> New Revision: 551592
> 
> URL:
> http://svn.apache.org/viewvc?view=rev&rev=551592
> Log:
>  now prefers evaluation
> result/return value over value property.
> 
> Modified:
> ant/core/trunk/WHATSNEW
>
>
ant/core/trunk/src/main/org/apache/tools/ant/types/optional/AbstractScriptComponent.java
>
>
ant/core/trunk/src/main/org/apache/tools/ant/types/optional/ScriptCondition.java
>
>
ant/core/trunk/src/tests/antunit/types/scriptcondition-test.xml
> 
> Modified: ant/core/trunk/WHATSNEW
> URL:
>
http://svn.apache.org/viewvc/ant/core/trunk/WHATSNEW?view=diff&rev=551592&r1=551591&r2=551592
>
==
> --- ant/core/trunk/WHATSNEW (original)
> +++ ant/core/trunk/WHATSNEW Thu Jun 28 08:14:04 2007
> @@ -14,6 +14,8 @@
>been modified to encode outgoing (InputStream)
> content as well as encoding
>incoming (OutputStream) content.
>  
> +*  now prefers evaluation
> result/return value over value property.
> +
>  Fixed bugs:
>  ---
>  * Regression: Locator fails with URI encoding
> problem when spaces in path
> 
> Modified:
>
ant/core/trunk/src/main/org/apache/tools/ant/types/optional/AbstractScriptComponent.java
> URL:
>
http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/types/optional/AbstractScriptComponent.java?view=diff&rev=551592&r1=551591&r2=551592
>
==
> ---
>
ant/core/trunk/src/main/org/apache/tools/ant/types/optional/AbstractScriptComponent.java
> (original)
> +++
>
ant/core/trunk/src/main/org/apache/tools/ant/types/optional/AbstractScriptComponent.java
> Thu Jun 28 08:14:04 2007
> @@ -17,6 +17,8 @@
>   */
>  package org.apache.tools.ant.types.optional;
>  
> +import java.io.File;
> +
>  import org.apache.tools.ant.Project;
>  import org.apache.tools.ant.ProjectComponent;
>  import org.apache.tools.ant.types.Path;
> @@ -24,9 +26,6 @@
>  import org.apache.tools.ant.util.ScriptRunnerBase;
>  import
> org.apache.tools.ant.util.ScriptRunnerHelper;
>  
> -
> -import java.io.File;
> -
>  /**
>   * This is a [EMAIL PROTECTED] ProjectComponent} that has
> script support built in
>   * Use it as a foundation for scriptable things.
> @@ -140,5 +139,14 @@
>   */
>  protected void executeScript(String execName) {
>  getRunner().executeScript(execName);
> +}
> +
> +/**
> + * Evaluate a script.
> + * @param execName name of the script.
> + * @return the result of the evaluation.
> + */
> +protected Object evaluateScript(String
> execName) {
> +return
> getRunner().evaluateScript(execName);
>  }
>  }
> 
> Modified:
>
ant/core/trunk/src/main/org/apache/tools/ant/types/optional/ScriptCondition.java
> URL:
>
http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/types/optional/ScriptCondition.java?view=diff&rev=551592&r1=551591&r2=551592
>
==
> ---
>
ant/core/trunk/src/main/org/apache/tools/ant/types/optional/ScriptCondition.java
> (original)
> +++
>
ant/core/trunk/src/main/org/apache/tools/ant/types/optional/ScriptCondition.java
> Thu Jun 28 08:14:04 2007
> @@ -33,7 +33,6 @@
>   */
>  private boolean value = false;
>  
> -
>  /**
>   * Is this condition true?
>   *
> @@ -44,8 +43,8 @@
>   */
>  public boolean eval() throws BuildException {
>  initScriptRunner();
> -executeScript("ant_condition");
> -return getValue();
> +Object result =
> evaluateScript("ant_condition");
> +return result instanceof Boolean ?
> ((Boolean) result).booleanValue() : getValue();
>  }
>  
>  /**
> 
> Modified:
>
ant/core/trunk/src/tests/antunit/types/scriptcondition-test.xml
> URL:
>
http://svn.apache.org/viewvc/ant/core/trunk/src/tests/antunit/types/scriptcondition-test.xml?view=diff&rev=551592&r1=551591&r2=551592
>
==
> ---
>
ant/core/trunk/src/tests/antunit/types/scriptcondition-test.xml
> (original)
> +++
>
ant/core/trunk/src/tests/antunit/types/scriptcondition-test.xml
> Thu Jun 28 08:14:04 2007
> @@ -70,4 +70,87 @@
>
>  
>
> +
> +  
> +
> +   value="false">
> +return true;
> +  
> +
> +  
> +
> +  
> +
> +   value="true">
> +return false;
> +  
> +
> +  
> +
> +  
> +
> +   value="false">
> +self.setValue(true);
> +return false;
> +  
> +
> +  
> +
> +  
> +
> +   value="true">
> +return null;
> +  
> +
> +  
> +
> +   name="testBeanshellReturnNonBooleanIgnored">
> + message="testBeanshellReturnNonBooleanIgnored">
> +   value="true"

Re: PropertyHelper thoughts

[Matt Benson]

 the new
approach.  Again, our goal is to improve the overall
design, not to take away any abilities you currently
have.

-Matt

> 
> Silly Examples (creativity a bit shot):
> 
> 1. Overlays
> 
>
> mode="local">
>   file="${deployment.d}/deploy.properties">
> ...
>  
>
> 
> 
> 
> 3. Value URIs
> 
>
>
>  
file="${conf.d}/build-${$os:|$lowercase:}.properties"/>
>
>...
> 
> 
> Hope this helps,
> The Wabbit
> 
> Matt Benson wrote:
> > 
> > --- Dominique Devienne <[EMAIL PROTECTED]>
> wrote:
> > 
> >> On 6/15/07, Matt Benson <[EMAIL PROTECTED]>
> >> wrote:
> >> > I am actively working on this as we speak,
> >> actually,
> >> > and I'm pleased so far with my results.
> >>
> >> FTR Matt, I still haven't read anything to
> convince
> >> me that write
> >> access via  is desirable, needed, and
> >> good. I'm not trying
> >> to put a damper on your efforts, but so far the
> use
> >> cases I've seen
> >> for "write" are better handled by custom tasks.
> > 
> > Okay, first to be more clear:  I determined that
> the
> > natural extension points for properties handling
> would
> > be, reading them, expanding them from a string
> (the
> > use case that kicked off this discussion), and
> setting
> > them.  I did and do recognize that changing how
> > properties are set was weird, and as such have
> still
> > not even written the interface for how that would
> > happen.  Even if the final group consensus is to
> allow
> > for them, I am putting them last, and who knows? 
> I
> > might not even be the one to implement them in the
> > event we do go forth with them.  :)
> > 
> >>
> >> What about the <*ant> tasks? These "things" which
> >> are not string
> >> properties, how do they percolate to
> sub-Projects?
> >> We have clear
> >> semantic for properties and references passing,
> so
> >> it would be much
> >> clearer and "The Ant Way"(tm) to have them as
> >> references, manipulated
> >> using custom tasks, and passed using reference
> >> semantic, and which
> >> unlike properties are not fully compartmented
> >> between Projects, which
> >> the parent and child project share the same
> >> referenced-object.
> >>
> > 
> > Here you've simplified "pluggable property
> setting" to
> > "supporting non-String properties" and I suppose
> > that's fair enough from a buildfile-only
> standpoint. But the current 
> > design of PropertyHelper allows for a
> > given property to be set as an arbitrary object
> via
> > Ant's API.  I think, even if we don't recognize
> that
> > we should allow a hook for setting properties,
> that
> > this is harmless enough, despite your well-founded
> > arguments regarding references.  That said, it's
> no
> > concern of mine if we reduce properties to
> Strings--it
> > would simplify some things, certainly--but the
> user
> > community might feel otherwise.  Then again, (1)
> if
> > we're already giving them breaking changes we can
> > certainly go whole-hog with those if we so choose,
> and
> > (2) I sent Wascally Wabbit from AntXtras (who seem
> to
> > be the greatest consumer of PropertyHelpers from
> the
> > list Peter sent out) a personal message inviting
> him
> > to this conversation and we still haven't seen
> him. I'll follow up with 
> > a similar message to the other
> > admin on the project in case he's on vacation or
> > something.  Meanwhile I'll try restricting
> properties
> > to strings and see if we break anything internal.
> > 
> >> Would installed PH instanced percolate to
> >> sub-Project automatically?
> > 
> > I'm not sure.  I think we need more discussion of
> > this:
> > 
> >> Because if they do, Peter's argument that the
> >> explicit declaration of
> >> the PH ensures BC falls flat if one uses
> "external"
> >> reusable build
> >> files which would happen to use the same syntax
> as
> >> the PH prefix
> >> installed in another build file. That would be
> bad
> >> encapsulation.
> >>
> >>

Re: PropertyHelper patch & property changes

[Matt Benson]

--- Kevin Jackson <[EMAIL PROTECTED]> wrote:

> Hi all,
> 
> I'm just testing out the props antlib.
> 
> First, it looks like it will be perfect for my
> usecase, ta Matt ;)
> 
> Second, is the patch at
>
http://issues.apache.org/bugzilla/show_bug.cgi?id=42736
> divisive?  If
> this was a simple antlib, then I could start using
> it straight away,
> but as it requires a patched version of ant too, I'm
> a little wary to
> start using it if there are objections with the
> patch.
> 
> Antunit based tests are passing fine for me here,
> but of course I'm
> not doing anything complicated and I only need
> string based properties
> not objects.
> 
> Has anyone else had a look at this code yet? If so
> is there any chance
> of this being merged into svn trunk for 1.7.1
> timeframe?

My understanding of the current situation wrt my work
so far:

 - Peter has looked at the code.
 - There is an overall vote of between +0 and +1 for
this work.
 - The work is a breaking change for current users of
PH functionality.

I plan to check this stuff in soon--I think I had a
bit more checking over things I wanted to do
first--but it won't be kosher to release it without a
1.8 shift.  This means I probably need to create a
branch before I check it in.

Sorry for the bad news... :(

-Matt

> 
> Thanks,
> Kev
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



 

Get your own web address.  
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Props Antlib

[Matt Benson]

--- Kevin Jackson <[EMAIL PROTECTED]> wrote:

> Hi all,
> 
> I've just got the props antlib working within my odd
> usecase.
> 
> I'm using mvn + antrun plugin and I've installed the
> patched version
> of ant and the props antlib.  Then in a parent pom,
> I've got the
> complete  etc setup for the property helper
> ie
> 
>   
> 
> 
> I munge the property with a regexp (very nice Matt,
> worked perfectly).
>  Finally in the child pom.xml I set the property
> value that will be
> munged.
> 
> Issues I came across.
> 
> 1- Without the ant-nodeps jar, the propertyhelper
> task fails with a
> ClassNotFoundException for ...Jdk14Regexp.Regexp
> 
> I fixed this by installing this jar in my
> ~/.m2/repository, and
> altering the classpath for the typedef

Alternately you could use the ant-apache-oro jar, I
guess.  :)

> 
> 2- Munging the property directly won't work.  I had
> to first copy the
> child property into an intermediate property and
> then perform the
> regexp on that - I guess this has to do with the
> mvn->ant mapping in
> some way - and it's not much of a hassle when you
> know the workaround
> 

Ugh!  You've just discovered one more example of
client code that extends PropertyHelper, in the antrun
plugin... I'd better drop a note over there to read up
on our related threads to get their input and find out
how hard it'll be for them to manage compatibility...
:(

> Anyway, for my use case of removing a hardcoded svn
> repo URL in the
> pom/profile when it's already available in the
>  in
> the pom, this antlib works perfectly.

Glad to hear it.  And ultimately I suppose it's a good
thing we learn about the Maven thing sooner rather
than later.

-Matt

> 
> Ta Matt,
> Kev
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



   

Pinpoint customers who are looking for what you sell. 
http://searchmarketing.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[antrun-plugin] impending PropertyHelper compatibility issues

[Matt Benson]

Forgive my ignorance of the subject line conventions
of this mailing list, and please note in advance that
I personally am not subscribed to any Maven lists (I
believe Kevin Jackson is subscribed to one or more of
them).  At any rate, it has come to the attention of
the Ant developers that Maven's antrun plugin
customizes Ant's PropertyHelper architecture.  A
discussion of drastic refactorings to these APIs is by
this time nearing its conclusion, but we are trying to
reach out to affected parties to gauge impact before
finalizing these changes for an Ant 1.8 version
sometime in the not-too-near future.  A fairly
complete picture of what has happened can be gotten by
reading the e-mail threads at these links:

http://marc.info/?t=11818165307&r=2&w=2
http://marc.info/?t=11835551689&r=1&w=2&n=2
http://marc.info/?t=11837196861&r=1&w=2&n=2

Regards,
Matt


   

Moody friends. Drama queens. Your life? Nope! - their life, your story. Play 
Sims Stories at Yahoo! Games.
http://sims.yahoo.com/  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

1.7.x branch

[Matt Benson]

I'd like to create one.  Any objections?

-Matt


  

Luggage? GPS? Comic books? 
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PathTokenizer

[Matt Benson]

--- Charles McLouth <[EMAIL PROTECTED]> wrote:

> A newbie question:
> Is there a particular reason why the PathTokenizer 
> (src/main/org/apache/tools/ant/PathTokenizer.java)
> isn't coded to handle quoted 
> windows paths?
> ex:
> "C:\a whitespace path\a whitespace file"
> 

Can you give a better example of what you think should
be happening that isn't?  In general, Java IO
implementations are perfectly capable of understanding
individual file paths with embedded whitespace, so
AFAIK quoting paths is considered to be a convenience
for working with shells (for example, in *nix shells
one can simply escape ws chars rather than quoting
them).  Quoting individual components of a larger path
structure would be similarly irrelevant/redundant.

-Matt

> I have a fix, but wanted to know if there was a
> valid reason that I did not see.
> 
> thanks,
> 
> charlie
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



   

Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for 
today's economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r557013 - in /ant/core/trunk/src/main/org/apache/tools/ant: AntClassLoader.java ComponentHelper.java

[Matt Benson]

--- Peter Reilly <[EMAIL PROTECTED]> wrote:

> Hi Matt,
> Is is necessary to apply these formatting changes at
> the
> moment?

I suppose I can revert, read onward:

> Normally when a branch is set up, there will be a
> lot of
> merging from the branch to the MAIN as minor bugs
> get
> fixed and having formatting changes can make it
> difficult
> to manage the merging.

I can concede this...

> 
> Also some of the changes are not directed by
> checkstyle-config.
> - I do not like removing of () as not having these
> can make code
>   difficult to read - my head hurts trying to figure
> out precedence

I didn't notice any that seemed terribly important,
apologies...

> - it not nice to increase line length above 80
> characters.

Then why did we change our checkstyle config to allow
100 max?

> - replacing if with the horrid :? is also not nice.

"horrid" == opinion IMO... I tend to use these to
ruthlessly obliterate duplicate code, but I can revert
these changes if effigy is on the table...

-Matt

> 
> Peter
> 
> 
> On 7/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> wrote:
> > Author: mbenson
> > Date: Tue Jul 17 11:37:53 2007
> > New Revision: 557013
> >
> > URL:
> http://svn.apache.org/viewvc?view=rev&rev=557013
> > Log:
> > fmt/refac
> >
> > Modified:
> >
>
ant/core/trunk/src/main/org/apache/tools/ant/AntClassLoader.java
> >
>
ant/core/trunk/src/main/org/apache/tools/ant/ComponentHelper.java
> >
> > Modified:
>
ant/core/trunk/src/main/org/apache/tools/ant/AntClassLoader.java
> > URL:
>
http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/AntClassLoader.java?view=diff&rev=557013&r1=557012&r2=557013
> >
>
==
> > ---
>
ant/core/trunk/src/main/org/apache/tools/ant/AntClassLoader.java
> (original)
> > +++
>
ant/core/trunk/src/main/org/apache/tools/ant/AntClassLoader.java
> Tue Jul 17 11:37:53 2007
> > @@ -15,7 +15,6 @@
> >   *  limitations under the License.
> >   *
> >   */
> > -
> >  package org.apache.tools.ant;
> >
> >  import java.io.ByteArrayOutputStream;
> > @@ -139,11 +138,9 @@
> >   */
> >  private void findNextResource() {
> >  URL url = null;
> > -while ((pathElementsIndex <
> pathComponents.size())
> > -   && (url == null)) {
> > +while ((pathElementsIndex <
> pathComponents.size()) && (url == null)) {
> >  try {
> > -File pathComponent
> > -= (File)
> pathComponents.elementAt(pathElementsIndex);
> > +File pathComponent = (File)
> pathComponents.elementAt(pathElementsIndex);
> >  url =
> getResourceURL(pathComponent, this.resourceName);
> >  pathElementsIndex++;
> >  } catch (BuildException e) {
> > @@ -159,6 +156,7 @@
> >   * The size of buffers to be used in this
> classloader.
> >   */
> >  private static final int BUFFER_SIZE = 8192;
> > +
> >  /**
> >   * Number of array elements in a test array
> of strings
> >   */
> > @@ -221,6 +219,7 @@
> >   * context loader.
> >   */
> >  private ClassLoader savedContextLoader =
> null;
> > +
> >  /**
> >   * Whether or not the context loader is
> currently saved.
> >   */
> > @@ -235,8 +234,7 @@
> >   *belong.
> >   * @param classpath The classpath to use to
> load classes.
> >   */
> > -public AntClassLoader(
> > -ClassLoader parent, Project project, Path
> classpath) {
> > +public AntClassLoader(ClassLoader parent,
> Project project, Path classpath) {
> >  setParent(parent);
> >  setClassPath(classpath);
> >  setProject(project);
> > @@ -282,8 +280,7 @@
> >   *classloader should be
> consulted  before trying to
> >   *load the a class
> through this loader.
> >   */
> > -public AntClassLoader(ClassLoader parent,
> Project project, Path classpath,
> > -  boolean parentFirst) {
> > +public AntClassLoader(ClassLoader parent,
> Project project, Path classpath, boolean
> parentFirst) {
> >  this(project, classpath);
> >  if (parent != null) {
> >  setParent(parent);
> > @@ -292,7 +289,6 @@
> >  addJavaLibraries();
> >  }
> >
> > -
> >  /**
> >   * Creates a classloader for the given
> project using the classpath given.
> >   *
> > @@ -305,8 +301,7 @@
> >   *classloader should be
> consulted before trying to
> >   *load the a class
> through this loader.
> >   */
> > -public AntClassLoader(Project project, Path
> classpath,
> > -  boolean parentFirst) {
> > +public AntClassLoader(Project project, Path
> classpath, boolean parentFirst) {
> >  this(null, project, classpath,
> parentFirst);
> >  }
> >
> > @@ -3

Re: svn commit: r557025 - /ant/core/trunk/src/main/org/apache/tools/ant/PropertyHelper.java

[Matt Benson]

--- Peter Reilly <[EMAIL PROTECTED]> wrote:

> I think that the cloning is not complete.

Thanks for pointing that out; I certainly need(ed) to
clone the delegates and (*)properties maps.  I am
purposely not doing anything with hooks, etc., since
the operative idea is to discard that whole (sub-)API.

> There is a patch in
>
http://issues.apache.org/bugzilla/attachment.cgi?id=18662
> that tries to get a clone of this horrible class. I

Horrible class?!  With the hook/chain stuff, I can
agree.  :)  Certainly it's a PITA overall.  ;)

> did not apply it
> at the time as I was scared of the potential bugs.

Is it possible you can provide a link to the entire
bugrep rather than just the attachment?  ;)

-Matt

> Peter
> 
> 
> On 7/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> wrote:
> > Author: mbenson
> > Date: Tue Jul 17 11:55:42 2007
> > New Revision: 557025
> >
> > URL:
> http://svn.apache.org/viewvc?view=rev&rev=557025
> > Log:
> > Cloneable; update Delegate order on re-add
> >
> > Modified:
> >
>
ant/core/trunk/src/main/org/apache/tools/ant/PropertyHelper.java
> >
> > Modified:
>
ant/core/trunk/src/main/org/apache/tools/ant/PropertyHelper.java
> > URL:
>
http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/PropertyHelper.java?view=diff&rev=557025&r1=557024&r2=557025
> >
>
==
> > ---
>
ant/core/trunk/src/main/org/apache/tools/ant/PropertyHelper.java
> (original)
> > +++
>
ant/core/trunk/src/main/org/apache/tools/ant/PropertyHelper.java
> Tue Jul 17 11:55:42 2007
> > @@ -57,7 +57,7 @@
> >   *
> >   * @since Ant 1.6
> >   */
> > -public class PropertyHelper {
> > +public class PropertyHelper implements Cloneable
> {
> >
> >  /**
> >   * Marker interface for a PropertyHelper
> delegate.
> > @@ -198,6 +198,7 @@
> >   *  least for non-dynamic properties)
> >   *
> >   * @param next the next property helper in
> the chain.
> > + * @deprecated
> >   */
> >  public void setNext(PropertyHelper next) {
> >  this.next = next;
> > @@ -207,6 +208,7 @@
> >   * Get the next property helper in the chain.
> >   *
> >   * @return the next property helper.
> > + * @deprecated
> >   */
> >  public PropertyHelper getNext() {
> >  return next;
> > @@ -707,7 +709,6 @@
> >   * the return value is also
> null.
> >   * @return the property value, or
> null for no match
> >   * or if a null name is
> provided.
> > - * @deprecated namespaces are unnecessary.
> >   */
> >  public synchronized Object
> getUserProperty(String name) {
> >  if (name == null) {
> > @@ -909,9 +910,10 @@
> >  list = new ArrayList();
> >  delegates.put(key, list);
> >  }
> > -if (!list.contains(delegate)) {
> > -list.add(0, delegate);
> > +if (list.contains(delegate)) {
> > +list.remove(delegate);
> >  }
> > +list.add(0, delegate);
> >  }
> >  }
> >
> > @@ -939,6 +941,21 @@
> >  if
> (Delegate.class.isAssignableFrom(c[i]) &&
> !Delegate.class.equals(c[i])) {
> >  result.add(c[i]);
> >  }
> > +}
> > +return result;
> > +}
> > +
> > +/**
> > + * Make a clone of this PropertyHelper.
> > + * @return the cloned PropertyHelper.
> > + * @since Ant 1.8
> > + */
> > +public Object clone() {
> > +PropertyHelper result;
> > +try {
> > +result = (PropertyHelper)
> super.clone();
> > +} catch (CloneNotSupportedException e) {
> > +throw new BuildException(e);
> >  }
> >  return result;
> >  }
> >
> >
> >
> >
>
-
> > 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]
> 
> 



   

Yahoo! oneSearch: Finally, mobile search 
that gives answers, not web links. 
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r557062 - /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/LoadProperties.java

[Matt Benson]

The refactoring is much bigger than the formatting
here, FYI... wanted to reassure you that I am taking
your comments to heart, Peter.

-Matt

--- [EMAIL PROTECTED] wrote:

> Author: mbenson
> Date: Tue Jul 17 14:35:26 2007
> New Revision: 557062
> 
> URL:
> http://svn.apache.org/viewvc?view=rev&rev=557062
> Log:
> fmt/refac
> 
> Modified:
>
>
ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/LoadProperties.java
> 
> Modified:
>
ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/LoadProperties.java
> URL:
>
http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/LoadProperties.java?view=diff&rev=557062&r1=557061&r2=557062
>
==
> ---
>
ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/LoadProperties.java
> (original)
> +++
>
ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/LoadProperties.java
> Tue Jul 17 14:35:26 2007
> @@ -76,8 +76,7 @@
>   * @param resource resource on classpath
>   */
>  public void setResource(String resource) {
> -assertSrcIsJavaResource();
> -((JavaResource) src).setName(resource);
> +   
> getRequiredJavaResource().setName(resource);
>  }
>  
>  /**
> @@ -100,8 +99,7 @@
>   * @param classpath to add to any existing
> classpath
>   */
>  public void setClasspath(Path classpath) {
> -assertSrcIsJavaResource();
> -((JavaResource)
> src).setClasspath(classpath);
> +   
> getRequiredJavaResource().setClasspath(classpath);
>  }
>  
>  /**
> @@ -109,8 +107,7 @@
>   * @return The classpath to be configured
>   */
>  public Path createClasspath() {
> -assertSrcIsJavaResource();
> -return ((JavaResource)
> src).createClasspath();
> +return
> getRequiredJavaResource().createClasspath();
>  }
>  
>  /**
> @@ -119,8 +116,7 @@
>   * @param r The reference value
>   */
>  public void setClasspathRef(Reference r) {
> -assertSrcIsJavaResource();
> -((JavaResource) src).setClasspathRef(r);
> +   
> getRequiredJavaResource().setClasspathRef(r);
>  }
>  
>  /**
> @@ -128,8 +124,7 @@
>   * @return The classpath
>   */
>  public Path getClasspath() {
> -assertSrcIsJavaResource();
> -return ((JavaResource) src).getClasspath();
> +return
> getRequiredJavaResource().getClasspath();
>  }
>  
>  /**
> @@ -150,7 +145,6 @@
>  }
>  throw new BuildException("Source
> resource does not exist: " + src);
>  }
> -
>  BufferedInputStream bis = null;
>  Reader instream = null;
>  ByteArrayInputStream tis = null;
> @@ -162,7 +156,6 @@
>  } else {
>  instream = new
> InputStreamReader(bis, encoding);
>  }
> -
>  ChainReaderHelper crh = new
> ChainReaderHelper();
>  crh.setPrimaryReader(instream);
>  crh.setFilterChains(filterChains);
> @@ -175,7 +168,6 @@
>  if (!text.endsWith("\n")) {
>  text = text + "\n";
>  }
> -
>  if (encoding == null) {
>  tis = new
> ByteArrayInputStream(text.getBytes());
>  } else {
> @@ -188,10 +180,8 @@
>  propertyTask.bindToOwner(this);
>  propertyTask.addProperties(props);
>  }
> -
>  } catch (final IOException ioe) {
> -final String message = "Unable to load
> file: " + ioe.toString();
> -throw new BuildException(message, ioe,
> getLocation());
> +throw new BuildException("Unable to
> load file: " + ioe, ioe, getLocation());
>  } finally {
>  FileUtils.close(bis);
>  FileUtils.close(tis);
> @@ -211,23 +201,24 @@
>   * @param a the resource to load as a single
> element Resource collection.
>   * @since Ant 1.7
>   */
> -public void addConfigured(ResourceCollection a)
> {
> +public synchronized void
> addConfigured(ResourceCollection a) {
>  if (src != null) {
>  throw new BuildException("only a single
> source is supported");
>  }
>  if (a.size() != 1) {
> -throw new BuildException("only single
> argument resource collections"
> - + " are
> supported");
> +throw new BuildException(
> +"only single-element resource
> collections are supported");
>  }
>  src = (Resource) a.iterator().next();
>  }
>  
> -private void assertSrcIsJavaResource() {
> +private synchronized JavaResource
> getRequiredJavaResource() {
>  if (src == null) {
>  src = new JavaResource();
>  src.setProject(getProject());
>  } else if (!(src instanceof JavaResource))
> {
>  throw new BuildException("expected a
> java resource as source")

Re: svn commit: r559096 - in /ant/core/trunk: WHATSNEW src/main/org/apache/tools/ant/types/Path.java

[Matt Benson]

--- Dominique Devienne <[EMAIL PROTECTED]> wrote:

> Matt, did you test this? You write that derive
> classes can override
> delegateIteratorToList() to return false, but this
> is used to init a
> class member of Path, i.e. the *super* class of the
> one supposed to do
> the overriding...
> 
> Assuming a MyPath extends Path, Path's members and
> Ctors are called
> before MyPath is initialized, so relying on virtual
> dispatch on a
> class that's not been initialized yet is fraught
> with trouble. Perhaps
> it works OK if MyPath.delegateIteratorToList() just
> returns false, but
> why not simply forgo the caching into preserveBC and
> systematically
> call delegateIteratorToList() when needed, at a time
> MyPath is fully
> initialized?
> 

Certainly this could be done, but I was looking to
avoid the expense of multiple reflection-based checks.
 Do you think it would be better to store a Boolean so
that the call could still be made only once (triggered
by the null reference), but deferred until after
initialization?

-Matt

> --DD
> 
> On 7/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> wrote:
> > +private final boolean preserveBC =
> delegateIteratorToList();
> 
> > +/**
> > + * that implements list(); this
> can, of course, be avoided by overriding
> > + * this method to return false.
> It is not expected that the result of this
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 



   

Need a vacation? Get great deals
to amazing places on Yahoo! Travel.
http://travel.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: is broken with Jython in the recent trunk builds

[Matt Benson]

--- Steve Loughran <[EMAIL PROTECTED]> wrote:

> Alexey N. Solofnenko wrote:
> > Recent trunk ANT fails in my builds because
>  does 
> > something with the script that Jython cannot
> digest (new lines?).  
> >  with the same code works fine. This is a
> test script:
> > 
> > 
> >