DO NOT REPLY [Bug 22865] - Zip whenempty attribute is broken

[bugzilla]

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=22865

Zip whenempty attribute is broken





--- Additional Comments From [EMAIL PROTECTED]  2003-09-02 14:24 ---
There have been massive changes in the  task between 1.5.1 and 1.5.3.
With Ant 1.5.4 I get

BUILD FAILED
file:/tmp/foo.xml:4: Cannot create zip archive /tmp/foo.zip: no files were 
included.

Could you please try Ant 1.5.4 and see whether the bug still exists for you?
It works for me.

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

DO NOT REPLY [Bug 22901] - [Patch] -only option to execute target(s) without dependencies

[bugzilla]

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=22901

[Patch] -only option to execute target(s) without dependencies





--- Additional Comments From [EMAIL PROTECTED]  2003-09-02 22:26 ---
Created an attachment (id=8043)
patch file

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

DO NOT REPLY [Bug 22901] New: - [Patch] -only option to execute target(s) without dependencies

[bugzilla]

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=22901

[Patch] -only option to execute target(s) without dependencies

   Summary: [Patch] -only option to execute target(s) without
dependencies
   Product: Ant
   Version: 1.6Alpha (nightly)
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The patch adds '-only' option to be able to execute target(s) without their 
dependencies.

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

DO NOT REPLY [Bug 22877] - cvstagdiff support for cvs module aliases

[bugzilla]

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=22877

cvstagdiff support for cvs module aliases

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]
 AssignedTo|[EMAIL PROTECTED]  |[EMAIL PROTECTED]

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

DO NOT REPLY [Bug 22863] - Can't just rename a directory with the move task

[bugzilla]

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=22863

Can't just rename a directory with the move task





--- Additional Comments From [EMAIL PROTECTED]  2003-09-02 14:28 ---
Are there any files or directories left in the original location in the


  


case?  This should try to simply rename the directory if it actually moves
everything.  But then again, the long delay you see may be spent scanning
the directory tree just to see whether everything is included.

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

Re: Timestamp attribute processing

[Steve Loughran]

Ken Gentle wrote:
At 12:56 PM 9/2/2003, you wrote:
Steve Cohen wrote:
Hmm, that's weaker than I would have expected.  If I'd like something 
a little better, is your recommendation then to add to DateUtils?

I guess it is time for a date type. I imagine taking 
java.util.Calendar as a param would be a nice way to map it (or Date, 
though that one's lack of timezones is an eternal source of trouble in 
the SOAP world)

SOAP and everywhere an application may span timezones.

Anyway, I'd suggest be very cautious about introducing general date 
processing in ant that would allow arbitrary date formats, as opposed to 
one or two formats per locale, or a single ISO style format 
"-MM-ddTHH:mm:ss.SSS" (I think that one is legal, I don't have the 
spec in front of me).
I agree, with the caveat that the 'T' is so vague; there is nowhere in 
the ISO spec to say 'dont know the timezone', which is why I use time_t 
in GMT as the sole time specifier in my soap systems

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

DO NOT REPLY [Bug 22759] - antcall at top level causes infinite loop

[bugzilla]

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=22759

antcall at top level causes infinite loop

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]
 AssignedTo|[EMAIL PROTECTED]  |[EMAIL PROTECTED]
   Target Milestone|--- |1.6
Version|1.1 |1.6Alpha (nightly)



--- Additional Comments From [EMAIL PROTECTED]  2003-09-02 15:47 ---
It hasn't popped up for two reasons:

(1)  cannot live at the top level in any released version, so it hasn't
been used that way by too many people yet.

(2) it used to cause a build failure instead of an inifite loop for the first
few months it was allowed there.

The is code in Ant.java that tries to detect this, but since top-level tasks get
executed at parser time now (they didn't in the initial version that allowed
top-level tasks), the test kicks in too late.

This is not a unique issue of having antcall at the top level, of course.


  




will have the same problem - and we've decided to not fix it as doing so would
require too much logic that could be defeated by more complex builds anyway.

We can and should test wether  or  try to call the target they are
defined in.  And for tasks at the top level we must not allow calling the same
build file at all.

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

DO NOT REPLY [Bug 22896] New: - The webinc directive for the jspc task does not work

[bugzilla]

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=22896

The webinc directive for the jspc task does not work

   Summary: The webinc directive for the jspc task does not work
   Product: Ant
   Version: 1.5.4
  Platform: PC
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have a target defined to precompile my jsps using the built-in  task.  
When I specify a file name for the webinc task, it does not work.  I get an 
error message that says the file cannot be found.  If I create an empty file as 
a placeholder, I don't get the error message, but no data is written to it.  

Here is a snippet of my build.xml.




The jsps are compiled successfully but the web-xml-fragment.xml is not correct.

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

DO NOT REPLY [Bug 22834] - XSLT fails transforming file with doctype

[bugzilla]

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=22834

XSLT fails transforming file with doctype





--- Additional Comments From [EMAIL PROTECTED]  2003-09-02 17:04 ---
I don't have any proxy settings in my browser.

The ant get task:

http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd"; 
 dest="toto.dtd" verbose="true" usetimestamp="true"/>

functions perfectly what means that the file can be retrieved from my computer
using ant.

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

DO NOT REPLY [Bug 22889] New: - Add string formatting options to

[bugzilla]

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=22889

Add string formatting options to 

   Summary: Add string formatting options to 
   Product: Ant
   Version: 2.0 spec
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


It would be handy to have string formatting options similar to KornShell's
'typedef' command available for  values. I find it a common operation
in my build scripts to have the same value in different case. For example:

 
  
  
  

If string formatting options were available, here's a possible reimplementation:

 
  
  
  

which would approximate 'typedef -l' and 'typedef -u'. Justification and
string length truncation would allow for fixed width values, etc.

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

DO NOT REPLY [Bug 22877] - cvstagdiff support for cvs module aliases

[bugzilla]

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=22877

cvstagdiff support for cvs module aliases





--- Additional Comments From [EMAIL PROTECTED]  2003-09-02 15:09 ---
There most probably will be no more 1.5.x releases, so there is no point in
patching the branch.

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

RE: Timestamp attribute processing

[Ken Gentle]

At 02:52 PM 9/2/2003, you wrote:
I appreciate what you are saying.
What I did so far, and none of it has been submitted yet, was to code my
task to accept either of the ISO8601 formats in DateUtils
(-MM-ddThh:mm:ss or -MM-dd) if no format is specified by the
user, OR if the user specifies a time format in the parameters to the
 task, parse only against that single format (and not the
defaults).  While that may fit your definition of a slippery slope, I
really don't think so since the only defaults are standards and anything
non-standard must be specified by the user in the same task-invocation
as the data being passed to the task.
And the "nested exception handler from hell" is only two levels deep.
Sorry, I must not have been following this thread as well as I thought.
You're solution there is very similar to what I'd planned to do (but 
haven't gotten to) for the CvsChangeLog task.

Granted, the exception handler is only two levels deep, but it will take 
some discipline, education and monitoring to prevent later developers from 
just throwing their favorite format in the list.

I think we're in violent agreement... ;^)

-Original Message-
From: Ken Gentle [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 02, 2003 1:35 PM
To: Ant Developers List
Subject: Re: Timestamp attribute processing
At 12:56 PM 9/2/2003, you wrote:
>Steve Cohen wrote:
>>Hmm, that's weaker than I would have expected.  If I'd like something
>>a
>>little better, is your recommendation then to add to DateUtils?
>
>I guess it is time for a date type. I imagine taking java.util.Calendar
>as
>a param would be a nice way to map it (or Date, though that one's lack
of
>timezones is an eternal source of trouble in the SOAP world)
SOAP and everywhere an application may span timezones.
This sounds like the first step down a very slippery slope of processing
arbitrary date formats.  I don't believe that the date parsing is
consistent across ant tasks now, and tasks like CVSTAGDIFF don't parse
their date parameters at all, but pass them through to the underlying
app.
As date formats are different across locales, and date strings can be
very
ambiguous (MM-DD- vs DD-MM- for example will both "match" the
input
string '12-12-2000' and there is no way to "dis-ambiguate" them without
some other input.
This is a sore point with me because for the mess in the system I'm
working
with now -- there are a list of US specific formats that are each tried
against the input string until one matches.  This was originally coded
as
the nested exception handler from hell...
Anyway, I'd suggest be very cautious about introducing general date
processing in ant that would allow arbitrary date formats, as opposed to
one or two formats per locale, or a single ISO style format
"-MM-ddTHH:mm:ss.SSS" (I think that one is legal, I don't have the
spec
in front of me).
 Ken
-
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]

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

DO NOT REPLY [Bug 22883] New: - Enhancement to pvcs Operational Task

[bugzilla]

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=22883

Enhancement to pvcs Operational Task 

   Summary: Enhancement to pvcs Operational Task
   Product: Ant
   Version: 1.5.4
  Platform: All
OS/Version: Windows NT/2K
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Apache ANT 1.5.4 has within it a number of useful Operational Tasks. One of 
which is called pvcs it can be used to extract files from PVCS Version Manager 
(VM)basically by front ending the VM PCLI "GET" command.
The ANT pvcs Operational Task has a number of parameters which can be used with 
it. However it has no parameter to allow the extraction of files directly to a 
directory. You can only extract files to a VM Workspace. The VM Workspace must 
have been previously created in the VM GUI. What we and I guess most people 
would like to do have the option to extract files directly to given directory 
without having to remember to go into the VM GUI in advance and create the 
Workspace.

Please could this feature be incorporated into a future release of Ant.

Andrew.

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

DO NOT REPLY [Bug 22759] - antcall at top level causes infinite loop

[bugzilla]

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=22759

antcall at top level causes infinite loop





--- Additional Comments From [EMAIL PROTECTED]  2003-09-02 17:31 ---
That makes sense. However antcall needs to call the same file in all cases so it
sounds like you are banning antcall from the top level? Perhaps there is a way
to scan ahead for the target and grab it? A quick pass over the top level of the
build file to collect the targets first would give us a list of targets to
invoke rather than calling the whole file over (if it is not already done that 
way).

It should not be too supprising to the user if top level properties defined
after the antcall are not expanded when the target is invoked. (and similar
issues with other things that happen at the top level after the antcall).

What I can't seem to figure out myself is would such a strategy force us to
change the behavior of antcall in a non-backwards compatable manner.

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

DO NOT REPLY [Bug 22863] - Can't just rename a directory with the move task

[bugzilla]

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=22863

Can't just rename a directory with the move task





--- Additional Comments From [EMAIL PROTECTED]  2003-09-02 14:50 ---
With this:





I got this output:

 [move] Moving 1199 files to C:\cvs\DS-4\delivs\dist\targetdir
 [move] Moved 2 empty directories to C:\cvs\DS-4\delivs\dist\targetdir

and the original folder was gone, so yes, apparently everything was moved.
It still took quite a while, but I guess that was just a scan of the tree
to move, as you said. The point remains that I don't want that scan ...
what I want is simply to rename the root directory of the tree, with no
regard to its contents. That is exactly what  does for me -- my use
case is a renaming operation, not a moving operation -- and thus the 
task is an imperfect replacement in this use case. So maybe  should
not have been deprecated?

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

problem with subscribing to ant-user list

[James Carpenter]

For some reason I am having trouble subscribing to the ant-user mailing
list, although I was able to subscribe to this dev list without problems.  I
tried several times, both today and yesterday.

To subscribe to the user list I sent the usual empty email to
[EMAIL PROTECTED] but never received the confirmation message.

Can anyone help me?  Sorry to bother the dev list, but I don't know what
else to do.

On a related tangent, is NNTP access to the mailing list available?


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

DO NOT REPLY [Bug 15729] - StarTeam rootLocalFolder should be java.io.File

[bugzilla]

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=15729

StarTeam rootLocalFolder should be java.io.File





--- Additional Comments From [EMAIL PROTECTED]  2003-09-02 15:57 ---
Steve, I'll trust ypur judgement here.  If you say a relative path has never
made too much sense anyway (and there is no way to detect what the user wanted
at runtime), go ahead and change it.

Printing a warning is good.  We should also add a not to Ant's WHATSNEW file
in the "this can break your build" section.

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

DO NOT REPLY [Bug 22877] - cvstagdiff support for cvs module aliases

[bugzilla]

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=22877

cvstagdiff support for cvs module aliases





--- Additional Comments From [EMAIL PROTECTED]  2003-09-02 12:54 ---
Hi Patrick,

cvstagdiff has changed a bit in ant 1.6
Can you do one of the following :
1) see if you can redo your patch against 1.6
or
2) give me an example of public cvs repository which has theses aliases and
against which I can test

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

Re: Timestamp attribute processing

[Antoine Levy-Lambert]

Sounds good.

Cheers,

Antoine
- Original Message - 
From: "Steve Cohen" <[EMAIL PROTECTED]>
To: "Ant Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, September 02, 2003 8:52 PM
Subject: RE: Timestamp attribute processing


I appreciate what you are saying.  

What I did so far, and none of it has been submitted yet, was to code my
task to accept either of the ISO8601 formats in DateUtils
(-MM-ddThh:mm:ss or -MM-dd) if no format is specified by the
user, OR if the user specifies a time format in the parameters to the
 task, parse only against that single format (and not the
defaults).  While that may fit your definition of a slippery slope, I
really don't think so since the only defaults are standards and anything
non-standard must be specified by the user in the same task-invocation
as the data being passed to the task.
And the "nested exception handler from hell" is only two levels deep.




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

DO NOT REPLY [Bug 22859] - Cross buildfile dependency

[bugzilla]

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=22859

Cross buildfile dependency





--- Additional Comments From [EMAIL PROTECTED]  2003-09-02 19:48 ---
Thanks for your answer. I suspected that this enhancement would rock the 
foundation quite a bit. The syntax for the reference is the easy part.
I will that a look at  and se if it will do the work.

.mats

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

RE: Timestamp attribute processing

[Steve Cohen]

I appreciate what you are saying.  

What I did so far, and none of it has been submitted yet, was to code my
task to accept either of the ISO8601 formats in DateUtils
(-MM-ddThh:mm:ss or -MM-dd) if no format is specified by the
user, OR if the user specifies a time format in the parameters to the
 task, parse only against that single format (and not the
defaults).  While that may fit your definition of a slippery slope, I
really don't think so since the only defaults are standards and anything
non-standard must be specified by the user in the same task-invocation
as the data being passed to the task.
And the "nested exception handler from hell" is only two levels deep.

-Original Message-
From: Ken Gentle [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 02, 2003 1:35 PM
To: Ant Developers List
Subject: Re: Timestamp attribute processing


At 12:56 PM 9/2/2003, you wrote:
>Steve Cohen wrote:
>>Hmm, that's weaker than I would have expected.  If I'd like something 
>>a
>>little better, is your recommendation then to add to DateUtils?
>
>I guess it is time for a date type. I imagine taking java.util.Calendar

>as
>a param would be a nice way to map it (or Date, though that one's lack
of 
>timezones is an eternal source of trouble in the SOAP world)

SOAP and everywhere an application may span timezones.

This sounds like the first step down a very slippery slope of processing

arbitrary date formats.  I don't believe that the date parsing is 
consistent across ant tasks now, and tasks like CVSTAGDIFF don't parse 
their date parameters at all, but pass them through to the underlying
app.

As date formats are different across locales, and date strings can be
very 
ambiguous (MM-DD- vs DD-MM- for example will both "match" the
input 
string '12-12-2000' and there is no way to "dis-ambiguate" them without 
some other input.

This is a sore point with me because for the mess in the system I'm
working 
with now -- there are a list of US specific formats that are each tried 
against the input string until one matches.  This was originally coded
as 
the nested exception handler from hell...

Anyway, I'd suggest be very cautious about introducing general date 
processing in ant that would allow arbitrary date formats, as opposed to

one or two formats per locale, or a single ISO style format 
"-MM-ddTHH:mm:ss.SSS" (I think that one is legal, I don't have the
spec 
in front of me).

 Ken 


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


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

Re: [VOTE] Ant/Antcall Returning properties and references [WAS] Re: ant 1.5.4 : Import

[Dale Anson]

Dominique --
Dang, I didn't know there was a competition going on!
I wrote most of the Antelope tasks because I had a specific need. Feel 
free to grab what you want and put it in Ant-contrib. I like your 
"loophole" for your "antreturn" task, I didn't like the code reuse 
either, but the way the "ant" task was written didn't lend itself to 
extension, and I didn't see your loophole.

Really, the "call" task in Antelope does what many people seem to 
expect, and is a very minimal task with almost no overhead. Below is the 
complete source. Judging from the e-mail I get, most people are 
downloading the Antelope tasks for this "call" task, the 
"try/catch/finally" task, the "if/else" task, and the "post" task. 
Ant-contrib already has try/catch and if/else, but adding call and post 
(or equivalent) would be good.

Dale
Here's the "call" task source. It's very short, even with whitespace 
it's only 17 lines. "Call" is to replace "antcall", not "ant".

import org.apache.tools.ant.Task;
import org.apache.tools.ant.BuildException;
public class Call extends Task {
 
  private String target = null;
 
  public void setTarget(String target) {
 this.target = target; 
  }
 
  public void execute() {
 if (target == null)
throw new BuildException("target is required");
 getProject().executeTarget(target);
  }
}

Dominique Devienne wrote:
-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
I'd like to explore the needs that is driving this specific feature
request - and see whether there is a different way to meet it.
 or  will allow you to import a set of properties (or
property setting tasks) for example.
   

I probably would not have needed  if I had access to ...
I feel it's a little hackish too, even though it serves my purpose just
fine for now. The fact that ProjectComponent reference instances change
Project when returned could have negative side effects for example???
 

Three +1s are required for a code change, so, by the likes of it,
the vote will have a negative result.
 

No, just no positive result.
   

Sorry for dropping the ball on you ;-) I posted this code kinda showing off
I guess, during the  discussion if you recall, and also because it
might be useful to somebody else. I looked at the Antelope one, and really
didn't like the code duplication I saw there. So I hacked my own thanks to a
loop hope related to the Introspection rules of Ant to get a hold of the
nested private project... Would be cleaner in  proper, but still not
great.
 is the way to go forward I think. I'm just missing it with my 1.5.3
Ant used in production builds (augmented Ant, but not modified in any way).
Thanks for proposing my code though. Cheers, --DD
PS: Maybe Ant-Contrib would like to incorporate 
   to compete on features with Antelope??? ;-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
 


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

DO NOT REPLY [Bug 22834] - XSLT fails transforming file with doctype

[bugzilla]

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=22834

XSLT fails transforming file with doctype





--- Additional Comments From [EMAIL PROTECTED]  2003-09-02 16:55 ---
And what is the proxy setting on your browser?

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

DO NOT REPLY [Bug 22859] - Cross buildfile dependency

[bugzilla]

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=22859

Cross buildfile dependency





--- Additional Comments From [EMAIL PROTECTED]  2003-09-02 16:55 ---
If you download and build ant1.6 from CVS you will see that we improve
inter-file work with an  task. However, doing cross-buildfile
dependencies is not something we currently want to address as it introduces far
too many complexities, even if its declarative nature is appealing. Also,
because we have few reserved characters in target names, coming up with a syntax
that doesnt clash with existing tasks is difficult (i.e I could be using : in a
target today)

Please grab the latest ant and see if the approach we are taking can be adapted
to meet your needs, and if not, tell is where we can improve it.

thanks,

steve

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

DO NOT REPLY [Bug 22774] - [PATCH] Allow reallyquiet (-Q) to task.

[bugzilla]

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=22774

[PATCH] Allow reallyquiet (-Q) to  task.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |1.6
Version|unspecified |1.5.4



--- Additional Comments From [EMAIL PROTECTED]  2003-09-02 14:41 ---
will be in nightly build 2003-09-03, thanks.

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

Re: Timestamp attribute processing

[Ken Gentle]

At 12:56 PM 9/2/2003, you wrote:
Steve Cohen wrote:
Hmm, that's weaker than I would have expected.  If I'd like something a 
little better, is your recommendation then to add to DateUtils?
I guess it is time for a date type. I imagine taking java.util.Calendar as 
a param would be a nice way to map it (or Date, though that one's lack of 
timezones is an eternal source of trouble in the SOAP world)
SOAP and everywhere an application may span timezones.
This sounds like the first step down a very slippery slope of processing 
arbitrary date formats.  I don't believe that the date parsing is 
consistent across ant tasks now, and tasks like CVSTAGDIFF don't parse 
their date parameters at all, but pass them through to the underlying app.

As date formats are different across locales, and date strings can be very 
ambiguous (MM-DD- vs DD-MM- for example will both "match" the input 
string '12-12-2000' and there is no way to "dis-ambiguate" them without 
some other input.

This is a sore point with me because for the mess in the system I'm working 
with now -- there are a list of US specific formats that are each tried 
against the input string until one matches.  This was originally coded as 
the nested exception handler from hell...

Anyway, I'd suggest be very cautious about introducing general date 
processing in ant that would allow arbitrary date formats, as opposed to 
one or two formats per locale, or a single ISO style format 
"-MM-ddTHH:mm:ss.SSS" (I think that one is legal, I don't have the spec 
in front of me).

Ken 

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

RE: Timestamp attribute processing

[Steve Cohen]

This is why I don't want to use it.  The starTeam API has a method to
make an OLEDate (which it requires) out of a java.util.Date, and that's
all I need.  All I'm saying is that Ant should do the parsing in java,
and only convert the result to an OLEDate right before it passes it to
the Starteam API.

-Original Message-
From: Steve Loughran [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 02, 2003 11:56 AM
To: Ant Developers List
Subject: Re: Timestamp attribute processing


Steve Cohen wrote:
...

> The StarTeam API uses something they call an OLEDate, which I'm sure 
> has some sort of parse capability but if I rely on that then I run the

> risk of being out of synch with the rest of Ant.

That looks suspiciously like a COM or SQL server datatype.



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


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

Re: Timestamp attribute processing

[Steve Loughran]

Steve Cohen wrote:
Hmm, that's weaker than I would have expected.  If I'd like something a little better, is your recommendation then to add to DateUtils?
I guess it is time for a date type. I imagine taking java.util.Calendar 
as a param would be a nice way to map it (or Date, though that one's 
lack of timezones is an eternal source of trouble in the SOAP world)


The StarTeam API uses something they call an OLEDate, which I'm sure has some sort of parse capability but if I rely on that then I run the risk of being out of synch with the rest of Ant.
That looks suspiciously like a COM or SQL server datatype.

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

Re: Getting 1.6 out the door

[Nicola Ken Barozzi]

Gus Heck wrote, On 02/09/2003 17.26:
...
 From Nicola Ken Barozzi:
 >Imports should be reusable bits of builds. But instead they carry the 
baggage
 >of targets. With macrodef I can finally *create tasks using Ant*.

And so Ant becomes an xml based programming language? Writing tasks in 
java seems preferable to me. 
Ant is an "Ant" programming language. Writing "tasks" in Ant is much 
much simpler if they are an aggregation and specialization of existing 
Ant tasks, way simpler.

I am not opposed to macrodef, but I want 
clear syntax that doesn't make atributes look like properties, and if we 
do have macrotemplates (which I still have some reservations about) I 
think they should have a backwards compatable syntax that is also 
clearly different from both properties and atributes. A clear syntax is 
my biggest gripe here.
Any syntax is ok for me, I just tend to think that the proposed one is 
clear enough.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

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

Re: Getting 1.6 out the door

[peter reilly]

On Tuesday 02 September 2003 16:26, Gus Heck wrote:
> >>  follows (I think) the same rules of properties as
> >>  with
> >> inheritall=yes.
>
> Modeling after antcall...? I am wary of this as antcall is broken at the
> top level.
> http://issues.apache.org/bugzilla/show_bug.cgi?id=22759 I certainly
> havn't looked at macrodef closely enough to know if it will be subject
> to the same problem, but it makes me wonder. It might even be the case
> that antcall should be deprecated and replaced with macrodef if macrodef
> works at the top level and can truely duplicate antcall's functionality.

I meant that on reading DD's e-mail, I realized that the property
expansion was the same as for using antcall.

The  code is totally different to , and  is not
meant to duplicate antcall's functionality - except for the case where
antcall is used as a template. (My build files had a number of such
targets).

However  does allow recursive calling so doing:


  
  
  


will cause an stack overflow if called.

One can do:



  


  Testing [${t}]
  


  DONE!


  
  

  

  

  

  



Giving the result:
recursive:
 [echo] Testing [hello world]
 [echo] Testing [hello worl]
 [echo] Testing [hello wor]
 [echo] Testing [hello wo]
 [echo] Testing [hello w]
 [echo] Testing [hello ]
 [echo] Testing [hello]
 [echo] Testing [hell]
 [echo] Testing [hel]
 [echo] Testing [he]
 [echo] Testing [h]
 [echo] Testing []
 [echo] DONE!

Peter

Note: I am not saying that one should do the above.., it is just
  the first example that came into my head.



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

cvs commit: ant/docs/manual/CoreTasks exec.html

[jhm]

jhm 2003/09/02 09:24:02

  Modified:docs/manual/CoreTasks exec.html
  Log:
  spell check
  
  Revision  ChangesPath
  1.32  +1 -1  ant/docs/manual/CoreTasks/exec.html
  
  Index: exec.html
  ===
  RCS file: /home/cvs/ant/docs/manual/CoreTasks/exec.html,v
  retrieving revision 1.31
  retrieving revision 1.32
  diff -u -r1.31 -r1.32
  --- exec.html 1 Aug 2003 10:08:12 -   1.31
  +++ exec.html 2 Sep 2003 16:24:02 -   1.32
  @@ -178,7 +178,7 @@
   resolveExecutable
   When this attribute is true, the name of the executable
if resolved firstly against the project basedir and
  - if that doe snot exist, against the execution
  + if that does not exist, against the execution
directory if specified. On Unix systems, if you only 
want to allow execution of commands in the user's path, 
set this to false.
  
  
  

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

cvs commit: ant/xdocs contributors.xml

[jhm]

jhm 2003/09/02 09:17:40

  Modified:docs contributors.html
   xdocscontributors.xml
  Log:
  Add some infos about myself.
  
  Revision  ChangesPath
  1.29  +6 -1  ant/docs/contributors.html
  
  Index: contributors.html
  ===
  RCS file: /home/cvs/ant/docs/contributors.html,v
  retrieving revision 1.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- contributors.html 1 Sep 2003 21:07:14 -   1.28
  +++ contributors.html 2 Sep 2003 16:17:40 -   1.29
  @@ -331,8 +331,13 @@
   
   
   
  -Jan Matèrne
  +Jan Matèrne (jhm at apache.org)
   
  +Jan is consultant for OOA/D in the computer centre of the government
  +of Northrhine Westfalia / Germany. He is the co-author of
  +http://www.galileocomputing.de/katalog/buecher/titel/gp/titelID-341?";>
  +Rational Rose und UML im Praxiseinsatz the first German book about
  +that OOAD-tool.
   
   
   Adam Murdoch
  
  
  
  1.16  +6 -1  ant/xdocs/contributors.xml
  
  Index: contributors.xml
  ===
  RCS file: /home/cvs/ant/xdocs/contributors.xml,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- contributors.xml  1 Sep 2003 21:05:15 -   1.15
  +++ contributors.xml  2 Sep 2003 16:17:40 -   1.16
  @@ -189,8 +189,13 @@
   
   
   
  -Jan Matèrne
  +Jan Matèrne (jhm at apache.org)
   
  +Jan is consultant for OOA/D in the computer centre of the government
  +of Northrhine Westfalia / Germany. He is the co-author of
  +http://www.galileocomputing.de/katalog/buecher/titel/gp/titelID-341?";>
  +Rational Rose und UML im Praxiseinsatz the first German book about
  +that OOAD-tool.
   
   
   Adam Murdoch
  
  
  

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

RE: Getting 1.6 out the door

[Jose Alberto Fernandez]

> From: peter reilly [mailto:[EMAIL PROTECTED] 
> 
> 
> >
> > Property interceptors are not part of Ant, and might never 
> be for that 
> > matter. Using a notation that mimicks interceptors is 
> probably not a 
> > good idea either.
> >
> > As I've been saying all along, lets just introduce a new (unique) 
> > notion for attribute/variable expansion (at use time rather than 
> > definition time), which is something new in Ant anyhow. No 
> (or less?) 
> > backward compatibility issues, and makes it plain and 
> obvious what is 
> > what:
> >
> > ${name} it's a property!
> > (@name) it's an attribute/variable!!!
> 
> yes but (IMO) this is confusingly similar to XPath use of variables.
>   
> 
> 
> buffer="storedXml" />
>   
> 
>   
> 

This to me is the best argument for using ${...} as the only
syntax for variables. If not, people will not only need to
learn a new syntax but also we need to create a way to escape
the meaning of the syntax, as per the example above.

We have already gone through all the pain of devicing and recognizing
escape sequences for the syntax for properties, we do not need to
go through that again. Lets keep things simple for users.


Jose Alberto

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

Re: Getting 1.6 out the door

[Gus Heck]

Steve Loughran wrote:
Gus Heck wrote:

I don't think there's such a thing as experimental stuff. It's 
either in or
not, and once in, it must be backward compatible.

I'm sorry so few people chimed in on the subject of overloading the 
meaning
of ${name} in Ant. If this could be changed, then I'd have an 
enthusiastic
+1, but as it stands, I'm -1 or maybe -0.

--DD
 

I agree 100%.
I also would like some feedback on my target access modifier patch, 
if possble
(see http://issues.apache.org/bugzilla/show_bug.cgi?id=22020)

I have mentioned this to a couple of people, including the friend who 
introduced me to ant in the first place and all thought the idea was 
good. I would like it to get in 1.6 if possible.

I am worried about the interaction between public/private and the 
inclusion mechanism. Will people expect object style access modifiers 
to  work with inclusion, such that targets marked private can not be 
called by included content?

I am similarly concerned and so I would like it considered before back 
compatablity constrains us with import etc. Personally, the private 
public distinction I have made (as I have implemented it) could be 
called non-user and user as easily as it only effects the ability to 
access things from the command line. I tried to write it in a way that 
other access tags could be used, to create a broader continum, though I 
havn't gone so far to set it up to handle independant flags. (such that 
user/non-user could be independant from import/no-import)

My patch is just a suggestion, and I am looking for feedback on how it 
could be improved, or made to play nicely with things like import.

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

Re: Getting 1.6 out the door

[Gus Heck]

Nicola Ken Barozzi wrote:

peter reilly wrote, On 01/09/2003 20.10:
On Monday 01 September 2003 16:43, Dominique Devienne wrote:
...
It's not all about power, or one would use a real programming language
like Perl or Python. , although powerful, complexifies the 
rules
of Ant, namely the property expansion one, making it context dependent!

What she said :)
Never underestimate the power and simplicity of context/scope free 
rules.
Although Ant already has scopes with //, the 
property
expansion rules works the same everywhere, and I'd like this to stay 
the
same.

 follows (I think) the same rules of properties as 
 with
inheritall=yes.

+1
Modeling after antcall...? I am wary of this as antcall is broken at the 
top level.
http://issues.apache.org/bugzilla/show_bug.cgi?id=22759 I certainly 
havn't looked at macrodef closely enough to know if it will be subject 
to the same problem, but it makes me wonder. It might even be the case 
that antcall should be deprecated and replaced with macrodef if macrodef 
works at the top level and can truely duplicate antcall's functionality.

From Nicola Ken Barozzi:
>Imports should be reusable bits of builds. But instead they carry the 
baggage
>of targets. With macrodef I can finally *create tasks using Ant*.

And so Ant becomes an xml based programming language? Writing tasks in 
java seems preferable to me. I am not opposed to macrodef, but I want 
clear syntax that doesn't make atributes look like properties, and if we 
do have macrotemplates (which I still have some reservations about) I 
think they should have a backwards compatable syntax that is also 
clearly different from both properties and atributes. A clear syntax is 
my biggest gripe here.

-Gus

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

DO NOT REPLY [Bug 22877] - cvstagdiff support for cvs module aliases

[bugzilla]

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=22877

cvstagdiff support for cvs module aliases





--- Additional Comments From [EMAIL PROTECTED]  2003-09-02 14:02 ---
Is there any chance this patch can make it to the ANT_15_BRANCH?

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

DO NOT REPLY [Bug 22888] New: - using regex package when optional.jar is not on classpath

[bugzilla]

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=22888

using regex package when optional.jar is not on classpath

   Summary: using regex package when optional.jar is not on
classpath
   Product: Ant
   Version: 1.5.4
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I think I have found a packaging problem with optional.jar

Since I have removed optional.jar from the system classpath, everything works OK
except for replaceregexp; I am always getting 'No supported regular expression
matcher found' even tought I am using Java 1.4.

Looking into the code, I have found that RegexpMatcherFactory is in ant.jar but
the different implementations are in optional.jar. How the factory can
instianciate a class in optional.jar if it is in a different classloader ? is
this a packaging bug ? why not put the complete package
org.apache.tools.ant.util.regexp/** into optional.jar ?

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

DO NOT REPLY [Bug 22877] - cvstagdiff support for cvs module aliases

[bugzilla]

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=22877

cvstagdiff support for cvs module aliases





--- Additional Comments From [EMAIL PROTECTED]  2003-09-02 14:00 ---
Created an attachment (id=8034)
unified diff against 1.16

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

Re: patch.xml and .cvsignore

[Stefan Bodewig]

On Wed, 27 Aug 2003, Larry Shatzer <[EMAIL PROTECTED]> wrote:

> If we add patch.txt and patch.tar.gz to the .cvsignore in the root
> directory, this solves this problem.

Yep, thanks.

Stefan

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

cvs commit: ant patch.xml

[bodewig]

bodewig 2003/09/02 07:54:14

  Modified:.patch.xml
  Log:
  fix inconsistent handling of cvs.found - fail if we cannot use CVS
  
  Revision  ChangesPath
  1.6   +3 -1  ant/patch.xml
  
  Index: patch.xml
  ===
  RCS file: /home/cvs/ant/patch.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- patch.xml 23 Jun 2003 11:54:14 -  1.5
  +++ patch.xml 2 Sep 2003 14:54:14 -   1.6
  @@ -22,7 +22,9 @@
   
   
   
  -
  +
  +
   
   
   
  
  
  

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

cvs commit: ant .cvsignore

[bodewig]

bodewig 2003/09/02 07:49:38

  Modified:..cvsignore
  Log:
  exclude patch.txt and patch.tar.gz to make patch.xml more useful
  
  Revision  ChangesPath
  1.10  +2 -1  ant/.cvsignore
  
  Index: .cvsignore
  ===
  RCS file: /home/cvs/ant/.cvsignore,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- .cvsignore26 Nov 2002 07:43:11 -  1.9
  +++ .cvsignore2 Sep 2003 14:49:38 -   1.10
  @@ -8,4 +8,5 @@
   *.iws
   *.pif
   velocity.log*
  -
  +patch.txt
  +patch.tar.gz
  
  
  

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

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs AbstractCvsTask.java

[bodewig]

bodewig 2003/09/02 07:38:19

  Modified:docs/manual/CoreTasks cvs.html
   src/main/org/apache/tools/ant/taskdefs AbstractCvsTask.java
  Log:
  Add a reallyquiet attribute to .
  
  PR: 22774
  Submitted by: Larry Shatzer 
  
  Revision  ChangesPath
  1.18  +29 -23ant/docs/manual/CoreTasks/cvs.html
  
  Index: cvs.html
  ===
  RCS file: /home/cvs/ant/docs/manual/CoreTasks/cvs.html,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- cvs.html  22 Apr 2003 15:31:03 -  1.17
  +++ cvs.html  2 Sep 2003 14:38:19 -   1.18
  @@ -13,8 +13,8 @@
   http://www.cvshome.org/"; target="_top">CVS repository.
   When doing automated builds, the get task should be
   preferred over the checkout command, because of speed.
  -Important: This task needs "cvs" on the path. If it isn't, you 
will get
  -an error (such as error 2 on windows). If  doesn't work, try to 
execute cvs.exe
  +Important: This task needs "cvs" on the 
path. If it isn't, you will get
  +an error (such as error 2 on windows). If 
 doesn't work, try to execute cvs.exe
   from the command line in the target directory in which you are working.
   Parameters
   
  @@ -31,25 +31,25 @@
 
   compression
   true or false - if set
  -to true, this is the same as compressionlevel="3"
  +to true, this is the same as 
compressionlevel="3"
   No. Defaults to false.
 
 
   compressionlevel
   A number between 1 and 9 (corresponding to
  -possible values for CVS' -z# argument). Any
  -other value is treated as compression="false"
  +possible values for CVS' -z# argument). Any
  +other value is treated as compression="false"
   No. Defaults to no compression.
 
   
 
   cvsRoot
  -the CVSROOT variable.
  +the CVSROOT variable.
   No
 
 
   cvsRsh
  -the CVS_RSH variable.
  +the CVS_RSH variable.
   No
 
 
  @@ -74,7 +74,13 @@
 
 
   quiet
  -suppress informational messages.
  +suppress informational messages. This is the same as 
-q on the command line.
  +No, default "false"
  +  
  +  
  +reallyquiet
  +suppress all messages. This is the same as
  +  -Q on the command line.  since Ant 1.6.
   No, default "false"
 
 
  @@ -110,7 +116,7 @@
 
   failonerror
   Stop the build process if the command exits with a
  -  return code other than 0. Defaults to false
  +  return code other than 0. Defaults to false
   No
 
   
  @@ -120,31 +126,31 @@
  dest="${ws.dir}"
 />
   checks out the package/module "ant" from the CVS
  -repository pointed to by the cvsRoot attribute, and stores the files in 
"${ws.dir}".
  +repository pointed to by the cvsRoot attribute, and stores the 
files in "${ws.dir}".
 
   updates the package/module that has previously been checked out into
  -"${ws.dir}".
  +"${ws.dir}".
   
 
   
  -silently (-q) creates a file called patch.txt which contains a unified 
(-u) diff which includes new files added via "cvs add" (-N) and can 
be used as input to patch.
  -The equivalent, using   elements, is:
  +silently (-q) creates a file called patch.txt 
which contains a unified (-u) diff which includes new files added 
via "cvs add" (-N) and can be used as input to patch.
  +The equivalent, using   elements, is:
   
   
  -
  +
   
  -
  -
  -
  -
  +
  +
  +
  +
   
   
   
   or:
   
  -
  +
   
  -
  +
   
   
   
  @@ -156,11 +162,11 @@
   
   
 
  -Updates from the head of repository ignoring sticky bits (-A) and 
creating any new directories as necessary (-d).
  +Updates from the head of repository ignoring sticky bits 
(-A) and creating any new directories as necessary 
(-d).
   Note: the text of the command is passed to cvs "as-is" so any 
cvs options should appear
   before the command, and any command options should appear after the command 
as in the diff example
  -above. See http://www.cvshome.org/docs/manual/index.html"; 
target="_top">the cvs manual for details,
  -specifically the http://www.cvshome.org/docs/manual/cvs_16.html"; 
target="_top">Guide to CVS commands
  +above. See http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs.html"; 
target="_top">the cvs manual for

cvs commit: ant/src/etc/checkstyle checkstyle-frames.xsl

[jhm]

jhm 2003/09/02 04:36:03

  Modified:src/etc/checkstyle checkstyle-frames.xsl
  Log:
  Display number of the column where the "error" occured (if present).
  
  Revision  ChangesPath
  1.4   +3 -4  ant/src/etc/checkstyle/checkstyle-frames.xsl
  
  Index: checkstyle-frames.xsl
  ===
  RCS file: /home/cvs/ant/src/etc/checkstyle/checkstyle-frames.xsl,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- checkstyle-frames.xsl 20 Jul 2003 10:18:29 -  1.3
  +++ checkstyle-frames.xsl 2 Sep 2003 11:36:02 -   1.4
  @@ -286,13 +286,13 @@
   
   
   Error Description
  -Line
  +Line:Column
   
   
   
   
   
  -
  +:
   
   
   
  @@ -327,5 +327,4 @@
   evenrow
   
   
  -
  -
  +
  \ No newline at end of file
  
  
  

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

RE: can't build ant 1.6

[Steve Cohen]

1.3

-Original Message-
From: Steve Loughran [mailto:[EMAIL PROTECTED] 
Sent: Monday, September 01, 2003 11:04 PM
To: Ant Developers List
Subject: Re: can't build ant 1.6


Steve Cohen wrote:

> I've received no replies to this, so let me try again with a little 
> more information.  Previous versions of build.sh (or build.bat)  
> contained this sequence:
> 
> LOCALCLASSPATH=lib/xercesImpl.jar:lib/xml-apis.jar:bootstrap/lib/ant.j
> ar
> # add in the dependency .jar files
> DIRLIBS=lib/optional/*.jar
> for i in ${DIRLIBS}
> do
> if [ "$i" != "${DIRLIBS}" ] ; then
> LOCALCLASSPATH=$LOCALCLASSPATH:"$i"
> fi
> done
> 
> In the current version, it is like this:
> 
> LOCALCLASSPATH=
> # add in the dependency .jar files
> DIRLIBS=lib/optional/*.jar
> for i in ${DIRLIBS}
> do
> if [ "$i" != "${DIRLIBS}" ] ; then
> LOCALCLASSPATH=$LOCALCLASSPATH:"$i"
> fi
> done
> 
> The difference is that LOCALCLASSPATH is no longer being preset with 
> xercesImpl.jar and xml-apis.jar before the optional directory is
scanned. The absence of these jars from the classpath was what led to
the failures below.  Getting them onto the classpath solved the problem.
> 
> But is this a bug?  Or is it an undocumented requirement that ant be 
> built in an environment that has these or other such jars on the 
> classpath?  Or is it a documented requirement and I've just been 
> unable to find the documentation?

I have seen something like this running build.sh on unix; it may be an 
effect of how we have recently changed the bootloader.

What java version are you running?


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


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

RE: Timestamp attribute processing

[Steve Cohen]

Actually, what about the TSTAMP formats?  These are probably the most common in 
Ant.  I think what I will do is accept either "MMdd hhmm" or "MMdd"
unless user specifies something else.  It's not much harder to do this than to 
enforce one person's idea of the "right way".


-Original Message-
From:   Stefan Bodewig [mailto:[EMAIL PROTECTED]
Sent:   Tue 9/2/2003 2:11 AM
To: [EMAIL PROTECTED]
Cc: 
Subject:Re: Timestamp attribute processing
there also is a datetime attribute in .  Would be nice to unify
them - at least Java code wise.

On Mon, 1 Sep 2003, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:

> (with a hardcoded US locale, looks like the europeans (continentals)
> are not allowed to enter DD-MM- dates, MM-DD- is preferred.

The reason is that you don't have to care about the user's locale
(user being the one who runs the build script).  For a reason unknown
to me, cron on RedHat 7.3 doesn't use the default locale of the
installed OS for example.

I could easily patch its environment but I've come to like the
fact that my code gets compiled and run on a different locale than my
default locale in nightly builds.  This has caught some locale
dependencies in my code in the past..

Stefan

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

DO NOT REPLY [Bug 22877] - cvstagdiff support for cvs module aliases

[bugzilla]

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=22877

cvstagdiff support for cvs module aliases





--- Additional Comments From [EMAIL PROTECTED]  2003-09-02 12:13 ---
The patch above should correct this issue.

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

DO NOT REPLY [Bug 22877] - cvstagdiff support for cvs module aliases

[bugzilla]

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=22877

cvstagdiff support for cvs module aliases





--- Additional Comments From [EMAIL PROTECTED]  2003-09-02 12:11 ---
Created an attachment (id=8032)
CvsTagDiff.java (revision 1.6.2.5) unified diff

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

DO NOT REPLY [Bug 22877] New: - cvstagdiff support for cvs module aliases

[bugzilla]

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=22877

cvstagdiff support for cvs module aliases

   Summary: cvstagdiff support for cvs module aliases
   Product: Ant
   Version: 1.5.3
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


cvstagdiff does not seem to work with cvs module aliases in ant 1.5.3.

If an alias is defined as "mod123 -a mod1 mod2 mod3" in CVSROOT/modules, the 
output of cvstagdiff will truncate the 6 first characters of each file name 
(length of mod123).

For example, if "mod1/file1.txt" should be reported, it will become "ile1.txt".

It seems the problem comes from line 271 of revision 1.6.2.5 of CvsTagDiff.java:
int headerLength = 5 + m_package.length() + 1;

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

Re: Timestamp attribute processing

[Stefan Bodewig]

On Mon, 1 Sep 2003, Steve Cohen <[EMAIL PROTECTED]> wrote:

> I've put this logic into StarTeamCheckout,

I'd say put it into DateUtils.

> because DateUtils seems to have a somewhat different purpose (like
> getPhaseOfMoon()??? :-) )

That's been fun to code.  If you want to know why I've written it, see


Stefan

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

Re: Getting 1.6 out the door

[Knut Wannheden]

> > > 3.  and 
> > >
> >   a) resolution of properties
> >  The issue here is that properties get resolved when the
> >  macro is used and not when the macro is defined.
> >  I think that it would be difficult to resolve the
> >  properties correctly when the macro is defined.
> >
> >  I think that the current implementation and behaviour is
> >  preferable.
>
> I think it's sad that you reflect on this from the implementation
> perspective rather than the user's one... One of the major 'feature'
> of Ant is that it is very explicit and relatively simple.
>
> It's not all about power, or one would use a real programming language
> like Perl or Python. , although powerful, complexifies the rules
> of Ant, namely the property expansion one, making it context dependent!
>
> Never underestimate the power and simplicity of context/scope free rules.
> Although Ant already has scopes with //, the
property
> expansion rules works the same everywhere, and I'd like this to stay the
> same.
>

Of course you always have to remember that this property expansion doesn't
work the same for targets.  Inside a target the properties aren't expanded
until the target is called.  This may seem obvious, but now that any task
can be at the top-level, a target doesn't feel that different from a task.
It's a task container and in a way not that different from .

Just my $0.02.

--
knut




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

Re: Timestamp attribute processing

[Stefan Bodewig]

there also is a datetime attribute in .  Would be nice to unify
them - at least Java code wise.

On Mon, 1 Sep 2003, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:

> (with a hardcoded US locale, looks like the europeans (continentals)
> are not allowed to enter DD-MM- dates, MM-DD- is preferred.

The reason is that you don't have to care about the user's locale
(user being the one who runs the build script).  For a reason unknown
to me, cron on RedHat 7.3 doesn't use the default locale of the
installed OS for example.

I could easily patch its environment but I've come to like the
fact that my code gets compiled and run on a different locale than my
default locale in nightly builds.  This has caught some locale
dependencies in my code in the past..

Stefan

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

Re: can't build ant 1.6

[Conor MacNeill]

On Tue, 2 Sep 2003 03:14 am, Steve Cohen wrote:
> I've received no replies to this, so let me try again with a little more
> information.  Previous versions of build.sh (or build.bat)  contained this
> sequence:
>

I assume you have the latest from CVS - nothing sticky?

>
> The difference is that LOCALCLASSPATH is no longer being preset with
> xercesImpl.jar and xml-apis.jar before the optional directory is scanned.
> The absence of these jars from the classpath was what led to the failures
> below.  Getting them onto the classpath solved the problem.

They are not required in the LOCALCLASSPATH as they are now copied into the 
bootstrap directory and added by the loader.

It works for me.

Can you check that the xerces jars are in the bootstrap/lib directory?

Conor


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

RE: Timestamp attribute processing

[Jan . Materne]

BTW, your first post was to the old adress "[EMAIL PROTECTED]".
Maybe your adress book isn´t uptodate :-)


Jan


> -Original Message-
> From: Steve Cohen [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 02, 2003 4:37 AM
> To: Ant Developers List
> Subject: RE: Timestamp attribute processing
> 
> 
> I've decided to do the following:
> I allow user to optionally specify a SimpleDateFormat String. 
>  If they don't do that, my routine will try by default 
> DateUtils.ISO8601_DATETIME_PATTERN and if that fails, then 
> DateUtils.ISO8601_DATE_PATTERN.  If a format is supplied and 
> fails or if one isn't supplied and neither of the defaults 
> work, I throw an exception.  I've put this logic into 
> StarTeamCheckout, because DateUtils seems to have a somewhat 
> different purpose (like getPhaseOfMoon()??? :-) ) and I'm not 
> sure my logic is generically applicable.  So I am using 
> DateUtils but not modifying it.  I could put 
> SimpleDateFormat.parse() inside a wrapper, but that seems pointless.
> 
> 
> -Original Message-
> From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED]
> Sent: Mon 9/1/2003 6:12 PM
> To:   Ant Developers List
> Cc:   
> Subject:  Re: Timestamp attribute processing
> Yes, if you think of a good generic routine to parse strings 
> into dates,
> then DateUtils should be the place for it.
> 
> Antoine
> - Original Message -
> From: "Steve Cohen" <[EMAIL PROTECTED]>
> To: "Ant Developers List" <[EMAIL PROTECTED]>
> Sent: Monday, September 01, 2003 10:27 PM
> Subject: RE: Timestamp attribute processing
> 
> 
> 
> Hmm, that's weaker than I would have expected.  If I'd like 
> something a
> little better, is your recommendation then to add to DateUtils?
> 
> The StarTeam API uses something they call an OLEDate, which 
> I'm sure has
> some sort of parse capability but if I rely on that then I 
> run the risk of
> being out of synch with the rest of Ant.
> 
> -Original Message-
> From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED]
> Sent: Mon 9/1/2003 3:15 PM
> To: Ant Developers List
> Cc:
> Subject: Re: Timestamp attribute processing
> - there is a date selector with a method 
> DateSelector#setDateTime which
> contains parsing code (with a hardcoded US locale, looks like 
> the europeans
> (continentals) are not allowed to enter DD-MM- dates, 
> MM-DD- is
> preferred.
> 
> - there is a DateUtils class in ant  It has methods to format 
> dates, but not
> to parse them. Parsing methods should be added there.
> 
> - the cvstagdiff task has attributes which are 
> date/timestamps, but the task
> does not parse these attributes itself, rather they are copied without
> parsing as command line arguments for the cvs executable.
> 
> - the tstamp task can create strings (properties) 
> representing dates, but
> does not have to parse the strings back
> 
> Cheers,
> 
> Antoine
> - Original Message -
> From: "Steve Cohen" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, September 01, 2003 9:58 PM
> Subject: Timestamp attribute processing
> 
> 
> There have been some requests to add functionality to the 
> stcheckout task
> (for StarTeam) to enable checkout by a timestamp.  It will 
> not be hard to do
> this, as the scenario is well-supported in the StarTeam API.
> 
> However, what about the Ant API?  Is there a standard way (and
> reusable/accessible code) for passing in timestamps as 
> attributes to a task?
> It seems like a bad idea for every task to roll its own date-parse
> processing.  Can someone point me at a better way to 
> implement it in ant?
> Ideally this would support at least -MM-dd, -MM-dd 
> hh:mm without
> making the user supply a date-format string.
> 
> 
> 
> -
> 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]
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> 
> 
> 

Re: can't build ant 1.6

[Steve Loughran]

Steve Cohen wrote:
I've received no replies to this, so let me try again with a little more 
information.  Previous versions of build.sh (or build.bat)  contained this 
sequence:
LOCALCLASSPATH=lib/xercesImpl.jar:lib/xml-apis.jar:bootstrap/lib/ant.jar
# add in the dependency .jar files
DIRLIBS=lib/optional/*.jar
for i in ${DIRLIBS}
do
if [ "$i" != "${DIRLIBS}" ] ; then
LOCALCLASSPATH=$LOCALCLASSPATH:"$i"
fi
done
In the current version, it is like this:
LOCALCLASSPATH=
# add in the dependency .jar files
DIRLIBS=lib/optional/*.jar
for i in ${DIRLIBS}
do
if [ "$i" != "${DIRLIBS}" ] ; then
LOCALCLASSPATH=$LOCALCLASSPATH:"$i"
fi
done
The difference is that LOCALCLASSPATH is no longer being preset with xercesImpl.jar and xml-apis.jar before the optional directory is scanned.
The absence of these jars from the classpath was what led to the failures below.  Getting them onto the classpath solved the problem.  

But is this a bug?  Or is it an undocumented requirement that ant be built in an environment that has these or other such jars on the classpath?  Or is it a documented requirement and I've just been unable to find the documentation?
I have seen something like this running build.sh on unix; it may be an 
effect of how we have recently changed the bootloader.

What java version are you running?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Timestamp attribute processing

[Steve Cohen]

I've decided to do the following:
I allow user to optionally specify a SimpleDateFormat String.  If they don't do 
that, my routine will try by default DateUtils.ISO8601_DATETIME_PATTERN and if 
that fails, then DateUtils.ISO8601_DATE_PATTERN.  If a format is supplied and 
fails or if one isn't supplied and neither of the defaults work, I throw an 
exception.  I've put this logic into StarTeamCheckout, because DateUtils seems 
to have a somewhat different purpose (like getPhaseOfMoon()??? :-) ) and I'm 
not sure my logic is generically applicable.  So I am using DateUtils but not 
modifying it.  I could put SimpleDateFormat.parse() inside a wrapper, but that 
seems pointless.


-Original Message-
From:   Antoine Levy-Lambert [mailto:[EMAIL PROTECTED]
Sent:   Mon 9/1/2003 6:12 PM
To: Ant Developers List
Cc: 
Subject:Re: Timestamp attribute processing
Yes, if you think of a good generic routine to parse strings into dates,
then DateUtils should be the place for it.

Antoine
- Original Message -
From: "Steve Cohen" <[EMAIL PROTECTED]>
To: "Ant Developers List" <[EMAIL PROTECTED]>
Sent: Monday, September 01, 2003 10:27 PM
Subject: RE: Timestamp attribute processing



Hmm, that's weaker than I would have expected.  If I'd like something a
little better, is your recommendation then to add to DateUtils?

The StarTeam API uses something they call an OLEDate, which I'm sure has
some sort of parse capability but if I rely on that then I run the risk of
being out of synch with the rest of Ant.

-Original Message-
From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED]
Sent: Mon 9/1/2003 3:15 PM
To: Ant Developers List
Cc:
Subject: Re: Timestamp attribute processing
- there is a date selector with a method DateSelector#setDateTime which
contains parsing code (with a hardcoded US locale, looks like the europeans
(continentals) are not allowed to enter DD-MM- dates, MM-DD- is
preferred.

- there is a DateUtils class in ant  It has methods to format dates, but not
to parse them. Parsing methods should be added there.

- the cvstagdiff task has attributes which are date/timestamps, but the task
does not parse these attributes itself, rather they are copied without
parsing as command line arguments for the cvs executable.

- the tstamp task can create strings (properties) representing dates, but
does not have to parse the strings back

Cheers,

Antoine
- Original Message -
From: "Steve Cohen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 01, 2003 9:58 PM
Subject: Timestamp attribute processing


There have been some requests to add functionality to the stcheckout task
(for StarTeam) to enable checkout by a timestamp.  It will not be hard to do
this, as the scenario is well-supported in the StarTeam API.

However, what about the Ant API?  Is there a standard way (and
reusable/accessible code) for passing in timestamps as attributes to a task?
It seems like a bad idea for every task to roll its own date-parse
processing.  Can someone point me at a better way to implement it in ant?
Ideally this would support at least -MM-dd, -MM-dd hh:mm without
making the user supply a date-format string.



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



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