DO NOT REPLY [Bug 11459] - If not grant perm to "ant.jar", throws Sec. Excep., If do grant perm to "ant.jar", but not to my Java app classes, will run without sec. excep. - this is wrong

[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=11459

If not grant perm to "ant.jar", throws Sec. Excep., If do grant perm to 
"ant.jar", but not to my Java app classes, will run without sec. excep. - this 
is wrong

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-11-26 21:50 ---
please see also bug 22533. This report has been one of my reasons writing the
permissions. By adding / revoking permissions your application should be
testable with a set of permission independent of the permissions ant needs.
(Marking as fixed)

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

Re: Invicta - a new open-source build management tool & framework

[Nadav Soferman]

RE: Invicta - a new open-source build management tool & frameworkHi,
Thanks for your comments (and compliments).
Here are answers to some questions that were raised (sorry for the delay):

- License:
- The license is currently LGPL. It was GPL (it wasn't a
hallucination...) and was changed according to your suggestion. I understand
that GPL is problematic and LGPL is better, but I don't have enough
knowledge in the various open-source licenses. Invicta should be used freely
by anyone (similar to ANT) and an appropriate license should be used (any
suggestions?).


- Maven:

- Scope: The scope of Maven is different from the scope of Invicta and
is much larger (Maven's). As stated on Maven's homepage, it is 'a project
management and project comprehension tool'. It manages various aspects of
project's (mainly Internet open-source projects) development, support, web
site and others. Among these aspects, there is the build management aspect.
Invicta concentrates on build management only (as ANT concentrates on the
actual build script) for any projects or software companies that need an
easy to maintain and customizable powerful build scripts for their
developers. As far as I can see it, conceptually Invicta may act in the
future as the build management module of projects that are based on Maven
and as a stand-alone module for other projects.

- J2EE: As far as I understand the current version of Maven (and I don't
pretend to be an expert of this cool product), it is not targeted for J2EE
projects. The following is an example of a scenario for which I believe
Invicta can be useful:
- A group of people or a software company develops one or more J2EE
projects.
- The projects are built of multiple components with internal
dependencies. They might also depend on external projects or packages. There
are many components that share the same 'build profile'. Multiple developers
are working on the projects. They might not be build 'experts'. The build
manager definitely doesn't want to duplicate a lot of ANT code and maintain
it.
- The build manager wants to write once (or none at all) powerful
build scripts that automatically perform actions such as:
- Automatic creation of EJB descriptors and interfaces.
- Pre-compilation of JSP files and automatic generation of
descriptor files.
- Compilation of sources and packing in JAR files.
- EJB compilation.
- Various packing and distribution methods (WAR, EAR, ZIP).
- Various deployment actions (for example: deploying an EJB
on a remote BEA WebLogic server).
- Various other build-related tasks.
- Any specific tasks of that software company or group of
people.
- The build manager wants the developers (and also himself) to
easily define and maintain by themselves the components of the projects,
their types and their relations and to automatically get powerful build
scripts that can do all the build & deployment actions in a standard and a
convenient way.
- These type definition files of the project acts as an integral
part of the project and can be used by the build manager (using Invicta) for
creating any required output according to their content.
- Invicta should contain powerful component built-in types such as
JAR, WAR, Pre-compile-WAR, EAR, EJB, etc. It also allows build managers or
developers to create their own 'types' that can be shared by multiple
components, projects or groups/companies.


We'll update Invicta's site with some more general information about 'what
it is good for', including a detailed comparison with Maven.

I'm sorry for writing such a long mail...  If you want more information and
you don't want it to be on this mailing list, contact me directly (or read
more at http://invicta.sf.net).

Thanks again for your interest and comments. We'll be happy to receive any
comments you have (both the good and the bad ones :)
Nadav

- Original Message -
From: Stirling, Scott
To: Ant Users List
Sent: Monday, November 24, 2003 3:54 PM
Subject: RE: Invicta - a new open-source build management tool & framework


> From: Nadav Soferman [mailto:[EMAIL PROTECTED]
>
> Hi,
> Invicta is a new open-source tool and framework for
> managing a build environment. It is based on ANT.
> Take a look at:
>   http://invicta.sf.net
Hi,
It's similar to Maven, but without the Jelly scripting and with a better
project object model.
The license is GPL.  Why not LGPL or BSD-style?
The extent of documentation and diagrams for this tool is amazing for a
first announcement.  I'm curious how this project came about.  The content
on the site looks great.
Scott Stirling
Workscape, Inc.
***
This message is intended only for the use of the intended recipient and
may contain information that is PRIVILEGED and/or CONFIDENTIAL.  If you
are

DO NOT REPLY [Bug 25032] New: - Unable to FTP to a Windows server

[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=25032

Unable to FTP to a Windows server

   Summary: Unable to FTP to a Windows server
   Product: Ant
   Version: 1.6Beta
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The commons-net task fails when FTPing to a windows server.
ANT 1.5.4 handles this without any problems (NetComponents.jar)

ftp> ls -l
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
09-18-02  02:05PM  204 BatchLanyon
11-13-03  11:04AM CD
09-18-02  02:05PM  773 copyLanyonFiles.sh
04-17-03  08:28AM1 final.txt
11-13-03  11:04AM FS
09-18-02  02:05PM  201 ftpLanyonZip.sh
11-20-03  10:37AM kevin
04-17-03  08:28AM   109147 LN01012.xml
04-17-03  08:27AM   154901 LN1.xml
04-17-03  08:26AM   112576 LN103.xml
04-17-03  08:26AM   141605 LN777.xml
04-17-03  08:27AM31487 LNBOAZ.xml
11-26-03  01:18PM LQ
11-13-03  11:02AM MnC
11-24-03  04:10PM 28405802 Single_20031121085641.zip
11-13-03  11:02AM SM
226 Transfer complete.
remote: -l
796 bytes received in 0.0072 seconds (108.39 Kbytes/s)
ftp>

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

DO NOT REPLY [Bug 23913] - Style task does not use XMLCatalog as required

[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=23913

Style task does not use XMLCatalog as required





--- Additional Comments From [EMAIL PROTECTED]  2003-11-26 17:40 ---
I have created an attachement with sample for this bug.
I was getting different errors depending if I ran my large build
or the small one. So you should treat this as an initial point.

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

DO NOT REPLY [Bug 23913] - Style task does not use XMLCatalog as required

[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=23913

Style task does not use XMLCatalog as required





--- Additional Comments From [EMAIL PROTECTED]  2003-11-26 17:38 ---
Created an attachment (id=9306)
Jar containing sample buildfile and support files for bug

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

DO NOT REPLY [Bug 24928] - Multithreaded JUnit test cases with Log4J and ANT

[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=24928

Multithreaded JUnit test cases with Log4J and ANT

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-11-26 14:14 ---
I tried forking the JUnit task as you suggested and I ended up getting the 
desired behavior I'm looking for.  Thank you for explaining how logging in ANT 
works.  Although the second solution sounds intriguing, (w.r.t. the time that I 
have available) I think I'll stick with the former solution.

Cheers!

-- Ross

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

RE: Ant 1.6 local and macrodef attributes

[Steve Cohen]

Not a committer but my votes on Jose's ballots:

1) Vote on @{x} as the syntax for textual substitutions
of attributes in .
+1

2) Vote on , must include decision on syntax,
scope (i.e., passing things on  & co., etc.)
I do not think all these have been settle.
0

-Original Message-
From:   Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
Sent:   Wed 11/26/2003 6:15 AM
To: Ant Developers List
Cc: 
Subject:RE: Ant 1.6 local and macrodef attributes
Here is my proposal for you guys to vote on.
Two completely separate votes:

1) Vote on @{x} as the syntax for textual substitutions
of attributes in .

Once this is settle, we can move on releasing 
in B3 with its fixed syntax. 

2) Vote on , must include decision on syntax,
scope (i.e., passing things on  & co., etc.)
I do not think all these have been settle.

If (2) is resolved and acepted on 1.6, then Peter
gets most of what he wants, if not, then at least
we can release move on on the rest of ANT.

Jose Alberto

> From: peter reilly [mailto:[EMAIL PROTECTED] 
> 
> 
> On Wednesday 26 November 2003 11:09, Stefan Bodewig wrote:
> > On Wed, 26 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > > a)
> > > I sent a vote last week on local properties
> > > and the result was:
> > >committers  others (+ votes in 
> bugzilla)
> > >have local in ant 1.6   2   1 + 6
> > >not 0   0
> > >+0  1   0
> > >
> > > Based on this and other feedback I think that local does 
> belong in 
> > > ant 1.6.
> >
> > I agree with your opinion (that locals should be there, 
> after all I'm 
> > one of the two +1s), but disagree with the conclusion that this is 
> > going to happen.  2 +1s is simply not enough to make a vote pass.
> >
> > I'm not trying to argue from a procedural standpoint but 
> merely from 
> > the fact that a change like this needs community support - and it 
> > doesn't seem to have it.
> 
> Well as least not Yet..
> >
> > > b)
> > > I send an vote the week before about local properties being
> >
> > s/local properties/macrodef attributes/
> 
> Opps..
> 
> >
> > > implemented by textual replacement or by using local 
> properties. The 
> > > result was:
> > >
> > >committers  others
> > >local properties2   1
> > >textual replacement 1   4
> > >+0  1   0
> > >
> > > I would like to implement attributes using local properties,
> >
> > -0.8
> 
> Ok, The reason (as I said before) I do not like textual subs 
> is the use of a different notation.., but I can live with it 
> if other people think it is a good thing,
> 
> >
> > most if not all things that could be done when we implement the 
> > attributes as local properties are possible with textual expansion. 
> > Textual expansion enables things that local properties don't.
> 
> This is true.
> 
> >
> > > I propose to commit local properties and implement 
> attributes using 
> > > local properties for the ant 1.6 beta3 release.
> >
> > -1 on both.  Both parts lack committer support.  We could try to 
> > revote or something.
> 
> Indeed.
> 
> Peter
> 
> 
> -
> 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 24928] - Multithreaded JUnit test cases with Log4J and ANT

[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=24928

Multithreaded JUnit test cases with Log4J and ANT





--- Additional Comments From [EMAIL PROTECTED]  2003-11-26 12:59 ---
Ant attaches threads and their outputs to tasks to enable tasks running in
 to log without interfering with each other.

If you spawn a new thread, Ant won't know which task it belongs to and only
capture the output of the main thread for  - and thus only this output
is going to end up in the output sent to the formatters.

If you fork , the task will only see one output (the output of the 
spawned)
VM and it will ge captured.  The alternative would be to explicitly register 
your
created threads with Ant's logging system which will be very hard if not 
impossible
to do (you'd need access to Project#registerThreadTask).

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

DO NOT REPLY [Bug 24802] - The style task and nested 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=24802

The style task and nested classpath

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement

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

DO NOT REPLY [Bug 19301] - junitreport fails for long string literals

[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=19301

junitreport fails for long string literals

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]
   ||.net



--- Additional Comments From [EMAIL PROTECTED]  2003-11-26 12:50 ---
*** Bug 24799 has been marked as a duplicate of this bug. ***

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

DO NOT REPLY [Bug 24799] - junitreport stylesheet causes StackOverflow with big replacements

[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=24799

junitreport stylesheet causes StackOverflow with big replacements

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-11-26 12:50 ---


*** This bug has been marked as a duplicate of 19301 ***

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

DO NOT REPLY [Bug 24799] - junitreport stylesheet causes StackOverflow with big replacements

[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=24799

junitreport stylesheet causes StackOverflow with big replacements

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |



--- Additional Comments From [EMAIL PROTECTED]  2003-11-26 12:50 ---
sorry, wrong number

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

DO NOT REPLY [Bug 24799] - junitreport stylesheet causes StackOverflow with big replacements

[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=24799

junitreport stylesheet causes StackOverflow with big replacements

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-11-26 12:49 ---


*** This bug has been marked as a duplicate of 19391 ***

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

DO NOT REPLY [Bug 24713] - Arbitrary header support for Mail 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=24713

Arbitrary header support for Mail task

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement

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

DO NOT REPLY [Bug 24697] - The JUnit plugin forks once for each test suite

[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=24697

The JUnit plugin forks once for each test suite

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]
 AssignedTo|[EMAIL PROTECTED]  |[EMAIL PROTECTED]
   Severity|Normal  |Enhancement
   Target Milestone|--- |1.7

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

DO NOT REPLY [Bug 24668] - SQL task's onError='stop' behaviour doesn't match docs

[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=24668

SQL task's onError='stop' behaviour doesn't match docs





--- Additional Comments From [EMAIL PROTECTED]  2003-11-26 12:39 ---
implementation and documentation are quite ambiguos to me.

abort -> explicit rollback + fail
continue -> only log exception, commit what we have at end of transaction, no 
fail

stop docs are not clear at all

stop implementation -> exactly identical to abort just that the rollback doesn't
   happen explicitly.  But the transaction won't be 
committed
   either.

My interpreation of the docs (and what probably is desired behavior) would be to
rollback the transaction, don't run consecutive transactions but don't make
the task fail.  This seems to be the same as your interpretation.

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

DO NOT REPLY [Bug 24646] - using format="xml" in gives NoClassDefFoundError

[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=24646

using format="xml" in  gives NoClassDefFoundError

[EMAIL PROTECTED] changed:

   What|Removed |Added

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



--- Additional Comments From [EMAIL PROTECTED]  2003-11-26 12:27 ---
No, it doesn't use java.class.path, that property gets modified by Ant after
starting Ant and doesn't reflect your system classpath.

I'll take a closer look.

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

DO NOT REPLY [Bug 24646] - using format="xml" in gives NoClassDefFoundError

[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=24646

using format="xml" in  gives NoClassDefFoundError





--- Additional Comments From [EMAIL PROTECTED]  2003-11-26 12:25 ---
I've tried to run the same target with both 1.5.2. and 1.6beta2 - and only 1.6 
failed...

It sounds odd to me as the java.class.path property looks fine i.e. all the 
jars from the lib directory are included. And I guess that forked of VMs use 
this property

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

RE: Ant 1.6 local and macrodef attributes

[Jose Alberto Fernandez]

Here is my proposal for you guys to vote on.
Two completely separate votes:

1) Vote on @{x} as the syntax for textual substitutions
of attributes in .

Once this is settle, we can move on releasing 
in B3 with its fixed syntax. 

2) Vote on , must include decision on syntax,
scope (i.e., passing things on  & co., etc.)
I do not think all these have been settle.

If (2) is resolved and acepted on 1.6, then Peter
gets most of what he wants, if not, then at least
we can release move on on the rest of ANT.

Jose Alberto

> From: peter reilly [mailto:[EMAIL PROTECTED] 
> 
> 
> On Wednesday 26 November 2003 11:09, Stefan Bodewig wrote:
> > On Wed, 26 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > > a)
> > > I sent a vote last week on local properties
> > > and the result was:
> > >committers  others (+ votes in 
> bugzilla)
> > >have local in ant 1.6   2   1 + 6
> > >not 0   0
> > >+0  1   0
> > >
> > > Based on this and other feedback I think that local does 
> belong in 
> > > ant 1.6.
> >
> > I agree with your opinion (that locals should be there, 
> after all I'm 
> > one of the two +1s), but disagree with the conclusion that this is 
> > going to happen.  2 +1s is simply not enough to make a vote pass.
> >
> > I'm not trying to argue from a procedural standpoint but 
> merely from 
> > the fact that a change like this needs community support - and it 
> > doesn't seem to have it.
> 
> Well as least not Yet..
> >
> > > b)
> > > I send an vote the week before about local properties being
> >
> > s/local properties/macrodef attributes/
> 
> Opps..
> 
> >
> > > implemented by textual replacement or by using local 
> properties. The 
> > > result was:
> > >
> > >committers  others
> > >local properties2   1
> > >textual replacement 1   4
> > >+0  1   0
> > >
> > > I would like to implement attributes using local properties,
> >
> > -0.8
> 
> Ok, The reason (as I said before) I do not like textual subs 
> is the use of a different notation.., but I can live with it 
> if other people think it is a good thing,
> 
> >
> > most if not all things that could be done when we implement the 
> > attributes as local properties are possible with textual expansion. 
> > Textual expansion enables things that local properties don't.
> 
> This is true.
> 
> >
> > > I propose to commit local properties and implement 
> attributes using 
> > > local properties for the ant 1.6 beta3 release.
> >
> > -1 on both.  Both parts lack committer support.  We could try to 
> > revote or something.
> 
> Indeed.
> 
> Peter
> 
> 
> -
> 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 24364] - Javadoc task link attribute should be relative to basedir

[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=24364

Javadoc task link attribute should be relative to basedir

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Major   |Enhancement

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

DO NOT REPLY [Bug 24354] - tar task does not include empty dirs

[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=24354

tar task does not include empty dirs

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Major   |Enhancement

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

DO NOT REPLY [Bug 23602] - Zip task STILL creates zip files incompatible with Winzip

[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=23602

Zip task STILL creates zip files incompatible with Winzip





--- Additional Comments From [EMAIL PROTECTED]  2003-11-26 12:06 ---
Any success with disabling the JIT or switching to a different VM?

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

DO NOT REPLY [Bug 24646] - using format="xml" in gives NoClassDefFoundError

[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=24646

using format="xml" in  gives NoClassDefFoundError





--- Additional Comments From [EMAIL PROTECTED]  2003-11-26 12:03 ---
includeantruntime only includes the parts of Ant's runtime that are necessary
to run the testrunner, not the classes to use the formatters.

So if you fork, you have to ensure there is a DOM library in your classpath (I
don't think the XML formatter needs anything besides DOM).

Has this been different in 1.5.x?

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

Re: Ant 1.6 local and macrodef attributes

[peter reilly]

On Wednesday 26 November 2003 11:09, Stefan Bodewig wrote:
> On Wed, 26 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > a)
> > I sent a vote last week on local properties
> > and the result was:
> >committers  others (+ votes in bugzilla)
> >have local in ant 1.6   2   1 + 6
> >not 0   0
> >+0  1   0
> >
> > Based on this and other feedback I think that local does
> > belong in ant 1.6.
>
> I agree with your opinion (that locals should be there, after all I'm
> one of the two +1s), but disagree with the conclusion that this is
> going to happen.  2 +1s is simply not enough to make a vote pass.
>
> I'm not trying to argue from a procedural standpoint but merely from
> the fact that a change like this needs community support - and it
> doesn't seem to have it.

Well as least not Yet..
>
> > b)
> > I send an vote the week before about local properties being
>
> s/local properties/macrodef attributes/

Opps..

>
> > implemented by textual replacement or by using local properties.
> > The result was:
> >
> >committers  others
> >local properties2   1
> >textual replacement 1   4
> >+0  1   0
> >
> > I would like to implement attributes using local properties,
>
> -0.8

Ok, The reason (as I said before) I do not like textual subs is
the use of a different notation.., but I can live with it
if other people think it is a good thing,

>
> most if not all things that could be done when we implement the
> attributes as local properties are possible with textual expansion.
> Textual expansion enables things that local properties don't.

This is true.

>
> > I propose to commit local properties and implement attributes using
> > local properties for the ant 1.6 beta3 release.
>
> -1 on both.  Both parts lack committer support.  We could try to
> revote or something.

Indeed.

Peter


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

Re: Ant 1.6 local and macrodef attributes

[peter reilly]

On Wednesday 26 November 2003 10:31, Jose Alberto Fernandez wrote:
> > From: peter reilly [mailto:[EMAIL PROTECTED]
> >
> > b)
> > I send an vote the week before about local properties being
> > implemented by textual replacement or by using local
> > properties. The result was:
>
> The vote was about macrodef expanding attributes as local properties.

Opps

> Just to make things clear.
>
> >committers  others
> >local properties2   1
> >textual replacement 1   4
> >+0  1   0
> >
> >
> > I would like to implement attributes using local properties,
> > with a possible option to allow the script writer to specify
> > textual replacement.
>
> You are the committers and you do whatever you want, but I think this
> is the biggest mistake that you can make to ANT (using locals).

Point taken..

> Providing both, sounds even more confusing. It means you get the
> bad side effects no matter what. (Or will I be able to say "DO NOT USE
> LOCALS AT ALL"?)
> If that is the case, then at least make it the default.
>
> > c)
> > I sent a vote on the syntax to use for texual replacement.
> > There was a varied response. A number of people liked the
> > notation @{x}.
>
> That looks fine to me.
>
> >  -
> >
> > I propose to commit local properties and implement attributes
> > using local properties for the ant 1.6 beta3 release.
> >
> > If there are problems with use of local properties as
> > attributes, this should be discovered very quickly.
>
> I thought we discover them already.
>
> Jose Alberto
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


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

Re: Ant 1.6 local and macrodef attributes

[Stefan Bodewig]

On Wed, 26 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> a)
> I sent a vote last week on local properties
> and the result was:
>committers  others (+ votes in bugzilla)
>have local in ant 1.6   2   1 + 6
>not 0   0
>+0  1   0
> 
> Based on this and other feedback I think that local does
> belong in ant 1.6.

I agree with your opinion (that locals should be there, after all I'm
one of the two +1s), but disagree with the conclusion that this is
going to happen.  2 +1s is simply not enough to make a vote pass.

I'm not trying to argue from a procedural standpoint but merely from
the fact that a change like this needs community support - and it
doesn't seem to have it.

> b)
> I send an vote the week before about local properties being

s/local properties/macrodef attributes/

> implemented by textual replacement or by using local properties.
> The result was:
> 
>committers  others
>local properties2   1
>textual replacement 1   4
>+0  1   0
> 
> I would like to implement attributes using local properties,

-0.8

most if not all things that could be done when we implement the
attributes as local properties are possible with textual expansion.
Textual expansion enables things that local properties don't.

> I propose to commit local properties and implement attributes using
> local properties for the ant 1.6 beta3 release.

-1 on both.  Both parts lack committer support.  We could try to
revote or something.

Stefan

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

RE: Ant 1.6 local and macrodef attributes

[Jose Alberto Fernandez]

> From: peter reilly [mailto:[EMAIL PROTECTED] 
> 
> b)
> I send an vote the week before about local properties being 
> implemented by textual replacement or by using local 
> properties. The result was:
> 

The vote was about macrodef expanding attributes as local properties.
Just to make things clear.

>committers  others
>local properties2   1
>textual replacement 1   4
>+0  1   0
> 
> 
> I would like to implement attributes using local properties, 
> with a possible option to allow the script writer to specify 
> textual replacement.
> 

You are the committers and you do whatever you want, but I think this
is the biggest mistake that you can make to ANT (using locals).
Providing both, sounds even more confusing. It means you get the 
bad side effects no matter what. (Or will I be able to say "DO NOT USE
LOCALS AT ALL"?)
If that is the case, then at least make it the default.

> 
> c)
> I sent a vote on the syntax to use for texual replacement. 
> There was a varied response. A number of people liked the 
> notation @{x}.
> 

That looks fine to me.

>  -
> 
> I propose to commit local properties and implement attributes 
> using local properties for the ant 1.6 beta3 release.
> 
> If there are problems with use of local properties as 
> attributes, this should be discovered very quickly.
> 

I thought we discover them already.

Jose Alberto

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

DO NOT REPLY [Bug 25003] New: - ejbjar documentation not complete

[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=25003

ejbjar documentation not complete

   Summary: ejbjar documentation not complete
   Product: Ant
   Version: 1.5.4
  Platform: All
   URL: http://ant.apache.org/manual/
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


ejbjar task allows a property manifest, defining the location of a custom
manifest to be included in the ejb jar file produced. 
This works in exactly the same manner as the jar task - however the 
documentation does not reflect this.
I suggest that the relevent line from the jar documentation is copied into the
ejbjar documentation.

i.e.
manifest | the manifest file to use. This can be either the location of a
manifest, or the name of a jar added through a fileset. If its the name of an
added jar, the task expects the manifest to be in the jar at
META-INF/MANIFEST.MF |  No

and maybe an example, for instance:



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

DO NOT REPLY [Bug 24756] - support property values containing refs to undefined properties

[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=24756

support property values containing refs to undefined properties

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2003-11-26 09:51 ---
I am marking this as WONTFIX.
The behaviour asked for is a bit confusing and would
if implemented not be backward compatible.

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

DO NOT REPLY [Bug 24646] - using format="xml" in gives NoClassDefFoundError

[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=24646

using format="xml" in  gives NoClassDefFoundError





--- Additional Comments From [EMAIL PROTECTED]  2003-11-26 09:42 ---
Hmm, it seems that when using fork="yes" I have to provide a classpath - even 
if includeantruntime is true (it should be by default according to junit task 
documentation). When fork is off things work well

I don't know if this is intended - so I'll just leave the bug in the NEW 
status. If this is intended the bug can be closed for my part. 

Is there anybody out there at all? ;o)

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

DO NOT REPLY [Bug 24945] - jar update fails with "Unable to rename old file to temporary 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=24945

jar update fails with "Unable to rename old file to temporary file"

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-11-26 09:33 ---
Ok added the name of the file to the error message
Thanks.

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

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

[peterreilly]

peterreilly2003/11/26 01:32:45

  Modified:src/main/org/apache/tools/ant/taskdefs Tag: ANT_16_BRANCH
Zip.java
  Log:
  sync with HEAD
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.116.2.2 +8 -4  ant/src/main/org/apache/tools/ant/taskdefs/Zip.java
  
  Index: Zip.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Zip.java,v
  retrieving revision 1.116.2.1
  retrieving revision 1.116.2.2
  diff -u -r1.116.2.1 -r1.116.2.2
  --- Zip.java  14 Oct 2003 13:20:11 -  1.116.2.1
  +++ Zip.java  26 Nov 2003 09:32:44 -  1.116.2.2
  @@ -421,11 +421,15 @@
   try {
   fileUtils.rename(zipFile, renamedFile);
   } catch (SecurityException e) {
  -throw new BuildException("Not allowed to rename old file 
"
  - + "to temporary file");
  +throw new BuildException(
  +"Not allowed to rename old file ("
  ++ zipFile.getAbsolutePath()
  ++ ") to temporary file");
   } catch (IOException e) {
  -throw new BuildException("Unable to rename old file "
  - + "to temporary file");
  +throw new BuildException(
  +"Unable to rename old file ("
  ++ zipFile.getAbsolutePath()
  ++ ") to temporary file");
   }
   }
   
  
  
  

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

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

[peterreilly]

peterreilly2003/11/26 01:31:45

  Modified:src/main/org/apache/tools/ant/taskdefs Zip.java
  Log:
  add filename to errormessage if unable to rename file in zip task
  PR: 24945
  Obtained from: Bart Vanhaute
  
  Revision  ChangesPath
  1.118 +8 -4  ant/src/main/org/apache/tools/ant/taskdefs/Zip.java
  
  Index: Zip.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Zip.java,v
  retrieving revision 1.117
  retrieving revision 1.118
  diff -u -r1.117 -r1.118
  --- Zip.java  14 Oct 2003 13:19:52 -  1.117
  +++ Zip.java  26 Nov 2003 09:31:45 -  1.118
  @@ -421,11 +421,15 @@
   try {
   fileUtils.rename(zipFile, renamedFile);
   } catch (SecurityException e) {
  -throw new BuildException("Not allowed to rename old file 
"
  - + "to temporary file");
  +throw new BuildException(
  +"Not allowed to rename old file ("
  ++ zipFile.getAbsolutePath()
  ++ ") to temporary file");
   } catch (IOException e) {
  -throw new BuildException("Unable to rename old file "
  - + "to temporary file");
  +throw new BuildException(
  +"Unable to rename old file ("
  ++ zipFile.getAbsolutePath()
  ++ ") to temporary file");
   }
   }
   
  
  
  

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

AW: cvs commit: ant/lib README xercesImpl.jar

[Antoine Lévy-Lambert]

I did not read properly the CVS commit emails. I need to clean my glasses.

Cheers,

Antoine

-Ursprüngliche Nachricht-
Von: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 26. November 2003 09:58
An: [EMAIL PROTECTED]
Betreff: Re: cvs commit: ant/lib README xercesImpl.jar


On Tue, 25 Nov 2003, Antoine Lévy-Lambert <[EMAIL PROTECTED]>
wrote:

> any reason why you did not update xml-apis.jar in the ANT_16_BRANCH,
> but only in CVS HEAD ?

I thought I did exactly the opposite of that.  I've only updated the
1.6 branch but not HEAD.  HEAD can wait for an official xml-commons
release IMHO.

Stefan



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

Ant 1.6 local and macrodef attributes

[peter reilly]

a)
I sent a vote last week on local properties
and the result was:
   committers  others (+ votes in bugzilla)
   have local in ant 1.6   2   1 + 6
   not 0   0
   +0  1   0

Based on this and other feedback I think that local does
belong in ant 1.6.

There was some concern about the syntax of declaring local
as a standalone task as against having a localproperty container.
I do not share the concern.

b)
I send an vote the week before about local properties being
implemented by textual replacement or by using local properties.
The result was:

   committers  others
   local properties2   1
   textual replacement 1   4
   +0  1   0


I would like to implement attributes using local properties, with
a possible option to allow the script writer to specify textual replacement.


c)
I sent a vote on the syntax to use for texual replacement. There was a varied
response. A number of people liked the notation @{x}.

 -

I propose to commit local properties and implement attributes using local
properties for the ant 1.6 beta3 release.

If there are problems with use of local properties as attributes, this should
be discovered very quickly.

Peter

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

Re: cvs commit: ant/lib README xercesImpl.jar

[Stefan Bodewig]

On Tue, 25 Nov 2003, Antoine Lévy-Lambert <[EMAIL PROTECTED]>
wrote:

> any reason why you did not update xml-apis.jar in the ANT_16_BRANCH,
> but only in CVS HEAD ?

I thought I did exactly the opposite of that.  I've only updated the
1.6 branch but not HEAD.  HEAD can wait for an official xml-commons
release IMHO.

Stefan

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

DO NOT REPLY [Bug 24993] - TStamp task documentation has HREF to invalid Sun URL

[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=24993

TStamp task documentation has HREF to invalid Sun URL

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-11-26 08:17 ---
Done in HEAD and ANT_16_BRANCH.

Thanks

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

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

[jhm]

jhm 2003/11/26 00:16:13

  Modified:docs/manual/CoreTasks Tag: ANT_16_BRANCH tstamp.html
  Log:
  Sync with HEAD
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.15.2.2  +1 -2  ant/docs/manual/CoreTasks/tstamp.html
  
  Index: tstamp.html
  ===
  RCS file: /home/cvs/ant/docs/manual/CoreTasks/tstamp.html,v
  retrieving revision 1.15.2.1
  retrieving revision 1.15.2.2
  diff -u -r1.15.2.1 -r1.15.2.2
  --- tstamp.html   9 Oct 2003 21:01:07 -   1.15.2.1
  +++ tstamp.html   26 Nov 2003 08:16:12 -  1.15.2.2
  @@ -42,7 +42,7 @@
   The Tstamp task supports a  nested element that
   allows a property to be set to the current date and time in a given format.
   The date/time patterns are as defined in the Java
  -http://java.sun.com/products/jdk/1.2/docs/api/java/text/SimpleDateFormat.html";>SimpleDateFormat
 class.
  +http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html";>SimpleDateFormat
 class.
   The format element also allows offsets to be applied to the time to generate 
different time values.
   
   
  @@ -144,4 +144,3 @@
   
   
   
  -
  
  
  

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

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

[jhm]

jhm 2003/11/26 00:14:23

  Modified:docs/manual/CoreTasks tstamp.html
  Log:
  Update SimpleDateFormat URL. BugID 24993 by Jason
  
  Revision  ChangesPath
  1.16  +1 -2  ant/docs/manual/CoreTasks/tstamp.html
  
  Index: tstamp.html
  ===
  RCS file: /home/cvs/ant/docs/manual/CoreTasks/tstamp.html,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- tstamp.html   22 Jun 2002 23:38:27 -  1.15
  +++ tstamp.html   26 Nov 2003 08:14:23 -  1.16
  @@ -41,7 +41,7 @@
   The Tstamp task supports a  nested element that
   allows a property to be set to the current date and time in a given format.
   The date/time patterns are as defined in the Java
  -http://java.sun.com/products/jdk/1.2/docs/api/java/text/SimpleDateFormat.html";>SimpleDateFormat
 class.
  +http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html";>SimpleDateFormat
 class.
   The format element also allows offsets to be applied to the time to generate 
different time values.
   
   
  @@ -143,4 +143,3 @@
   
   
   
  -
  
  
  

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