DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15031.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10413.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10413.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10413.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi,
I am concerned about the Perforce bugs, about which a lot of people have
complained.
There would be a way to fix the Perforce bug in the 1.5.4 branch, which would
be to bring back P4HandlerAdapter.java to the status of revision 1.7 (before I
submitted an unhappy change).
Can you also
I have a patch I have been testing for some time, I can submit it to fix the
threading issues.
-Original Message-
From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 23, 2003 6:04 PM
To: Ant Developers List
Subject: ant 1.5.4
Hi,
I am concerned about the
On Thu, 24 Jul 2003 11:03 am, Antoine Levy-Lambert wrote:
Hi,
I am concerned about the Perforce bugs, about which a lot of people have
complained.
The problem is that there are lots of bug fixes to Ant in HEAD that can be
back ported to 1.5. These are useful for many people. The more that
On Wed, 23 Jul 2003, Morten Mortensen
[EMAIL PROTECTED] wrote:
It basically repeats
org.apache.tools.ant.Project.replaceProperties() until nothing new
happens.
Without looking at the code, be careful with circular property
definitions then 8-)
property name=a value=${b}/
property name=b
On 24 Jul 2003, Stefan Bodewig [EMAIL PROTECTED] wrote:
who fixed a similar bug in property file=.../ yesterday.
Well, tried to fix and introduced a new bug, oops.
The next Gump build will see a lot of failures for taglibs because of
this.
Stefan
bodewig 2003/07/24 00:07:06
Modified:src/etc/testcases/taskdefs property.xml
src/testcases/org/apache/tools/ant/taskdefs
PropertyTest.java
Added: src/etc/testcases/taskdefs property5.properties
Log:
Show bug I've introduced yesterday
bodewig 2003/07/24 00:13:28
Modified:src/etc/testcases/taskdefs property.xml
Log:
Oops
Revision ChangesPath
1.9 +1 -1 ant/src/etc/testcases/taskdefs/property.xml
Index: property.xml
===
bodewig 2003/07/24 00:16:35
Modified:src/etc/testcases/taskdefs property5.properties
src/testcases/org/apache/tools/ant/taskdefs
PropertyTest.java
Log:
Things are even more complicated
Revision ChangesPath
1.2 +2 -1
bodewig 2003/07/24 01:09:34
Modified:src/main/org/apache/tools/ant/taskdefs Property.java
Log:
Resolve properties recursively to get a more robust handle on circular
definitions
Revision ChangesPath
1.66 +47 -37
On 23 Jul 2003, peter reilly [EMAIL PROTECTED] wrote:
Does anybody have a problem with this feature?
No.
... and you would have been told if I had after your commit anyway 8-)
Stefan
-
To unsubscribe, e-mail: [EMAIL
On Thu, 2003-07-24 at 03:59, Conor MacNeill wrote:
At the moment I have issues with import. The importing within imports is
not
right, at the moment, I think. Also I think we need to give antlib a bit of
a stretch :-) I'd like to see that happen first. For me a first 1.6 beta is
still
- Original Message -
From: Matt Bishop [EMAIL PROTECTED]
Sent: Thursday, July 24, 2003 3:14 AM
I have a patch I have been testing for some time, I can submit it to fix
the threading issues.
Matt, the Perforce problem (with p4change, p4label) is fixed in ant CVS
HEAD.
Would you be so
On Thu, 24 Jul 2003 07:19 pm, peter reilly wrote:
What are the issues with import.
I think we should write them down and deal with
them - it cannot be that difficult..
The difficult ones (manipulation of basebir etc)
we should explicitly defer to ant 1.6.
Not difficult but the issues are
conor 2003/07/24 05:02:51
Modified:src/main/org/apache/tools/ant/util LoaderUtils.java
Log:
Remove reflection which is no longer required
Revision ChangesPath
1.11 +14 -59ant/src/main/org/apache/tools/ant/util/LoaderUtils.java
Index: LoaderUtils.java
Conor MacNeill wrote, On 24/07/2003 13.36:
On Thu, 24 Jul 2003 07:19 pm, peter reilly wrote:
What are the issues with import.
I think we should write them down and deal with
them - it cannot be that difficult..
The difficult ones (manipulation of basebir etc)
we should explicitly defer to ant
Hi,
I just stumbled over findbugs[1] (via Cafe au lait) and ran it over
Ant's sources.
Some of the reported problems are non-issues, but it also detected
some things that checkstyle doesn't[2]. Some examples:
* BaseFilterReader line 88 should use instead of new String().
* bufferPos in
On Thu, 24 Jul 2003 10:26 pm, Nicola Ken Barozzi wrote:
What about:
import file=blah.xml name=blah/
Sure - pretty much what I thought, maybe a more descriptive attribute name
(overrideprefix). It would default to the imported project name.
So IIUC it's really only about making the
bodewig 2003/07/24 05:53:35
Modified:src/main/org/apache/tools/ant/taskdefs KeySubst.java
src/main/org/apache/tools/ant/types/selectors
ContainsRegexpSelector.java ContainsSelector.java
Log:
Fix potential NPEs
Revision ChangesPath
bodewig 2003/07/24 05:59:19
Modified:src/main/org/apache/tools/ant/taskdefs/optional/jlink
jlink.java
Log:
Fix potential stream leak
Revision ChangesPath
1.11 +11 -4
ant/src/main/org/apache/tools/ant/taskdefs/optional/jlink/jlink.java
Stefan Bodewig wrote:
Hi,
I just stumbled over findbugs[1] (via Cafe au lait) and ran it over
Ant's sources.
Some of the reported problems are non-issues, but it also detected
some things that checkstyle doesn't[2]. Some examples:
* BaseFilterReader line 88 should use instead of new String().
*
bodewig 2003/07/24 06:08:20
Modified:src/main/org/apache/tools/ant/taskdefs/optional/vss
MSVSSLABEL.java
Log:
Replace == with equals()
Revision ChangesPath
1.20 +1 -1
On Thu, 24 Jul 2003, Christopher Lenz [EMAIL PROTECTED] wrote:
You can check for 1/ and 2/ with Checkstyle, too:
I expected that to be the case, yes. My last commits (fixing of
potential NPEs, resource leaks) are less likely to be detected,
though.
Stefan
peterreilly2003/07/24 06:14:21
Modified:docs/manual/CoreTasks copy.html move.html
src/main/org/apache/tools/ant/taskdefs Copy.java Move.java
Added: src/etc/testcases/taskdefs multimap.xml
src/testcases/org/apache/tools/ant/taskdefs
bodewig 2003/07/24 06:14:31
Modified:src/main/org/apache/tools/tar TarEntry.java
Log:
Fix incorrect equals() override
Revision ChangesPath
1.17 +14 -0 ant/src/main/org/apache/tools/tar/TarEntry.java
Index: TarEntry.java
bodewig 2003/07/24 06:17:04
Modified:src/main/org/apache/tools/bzip2 CBZip2OutputStream.java
Log:
Fix incorrect finalize override
Revision ChangesPath
1.15 +2 -1
ant/src/main/org/apache/tools/bzip2/CBZip2OutputStream.java
Index: CBZip2OutputStream.java
peterreilly2003/07/24 06:19:27
Modified:.WHATSNEW
Log:
multiple mappings for copy and move
Revision ChangesPath
1.466 +4 -0 ant/WHATSNEW
Index: WHATSNEW
===
RCS file:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21320.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
bodewig 2003/07/24 06:24:35
Modified:src/main/org/apache/tools/ant AntClassLoader.java
src/main/org/apache/tools/ant/taskdefs ExecuteJava.java
Log:
Fix inconsistent synchronization
Revision ChangesPath
1.73 +1 -1
bodewig 2003/07/24 06:29:38
Modified:src/main/org/apache/tools/ant/taskdefs ProcessDestroyer.java
StreamPumper.java
Log:
notifyAll instead of notify
Revision ChangesPath
1.11 +1 -1
bodewig 2003/07/24 06:48:16
Modified:src/main/org/apache/tools/ant/taskdefs AntStructure.java
Get.java
src/main/org/apache/tools/ant/taskdefs/optional/ejb
IPlanetEjbc.java
src/main/org/apache/tools/bzip2
peterreilly2003/07/24 06:48:46
Modified:docs/manual/CoreTasks typedef.html
src/main/org/apache/tools/ant/helper ProjectHelper2.java
src/main/org/apache/tools/ant/taskdefs Definer.java
Added: src/etc/testcases/taskdefs antlib.xml test.antlib.xml
peterreilly2003/07/24 06:54:05
Modified:src/main/org/apache/tools/ant IntrospectionHelper.java
Log:
use valueof instead of new Boolean
Revision ChangesPath
1.63 +2 -1
ant/src/main/org/apache/tools/ant/IntrospectionHelper.java
Index:
bodewig 2003/07/24 07:05:55
Modified:src/main/org/apache/tools/ant Project.java
PropertyHelper.java
Log:
Fix inconsistent synchronization
Revision ChangesPath
1.149 +5 -5 ant/src/main/org/apache/tools/ant/Project.java
Index:
antoine 2003/07/24 07:07:51
Modified:src/main/org/apache/tools/ant/taskdefs Basename.java
BuildNumber.java Available.java Ant.java
AbstractCvsTask.java AntStructure.java
Log:
style
Revision ChangesPath
1.10 +11 -5
On 24 Jul 2003, [EMAIL PROTECTED] wrote:
Boolean.valueOf(Project.toBoolean(value))
won't compile with JDK 1.3- as only the valueOf(String) method
exists. I'll roll that back.
Stefan
-
To unsubscribe, e-mail: [EMAIL
bodewig 2003/07/24 07:20:32
Modified:src/main/org/apache/tools/ant IntrospectionHelper.java
Log:
JDK 1.2 compatibility
Revision ChangesPath
1.64 +1 -1
ant/src/main/org/apache/tools/ant/IntrospectionHelper.java
Index: IntrospectionHelper.java
bodewig 2003/07/24 07:20:56
Modified:src/main/org/apache/tools/ant Target.java
src/main/org/apache/tools/ant/filters TailFilter.java
src/main/org/apache/tools/ant/taskdefs/email EmailTask.java
src/main/org/apache/tools/bzip2
Yikes!
Peter
On Thu, 2003-07-24 at 15:19, Stefan Bodewig wrote:
On 24 Jul 2003, [EMAIL PROTECTED] wrote:
Boolean.valueOf(Project.toBoolean(value))
won't compile with JDK 1.3- as only the valueOf(String) method
exists. I'll roll that back.
Stefan
conor 2003/07/24 07:24:07
Modified:src/main/org/apache/tools/ant/taskdefs Parallel.java
docs/manual/CoreTasks parallel.html
Log:
Rework parallel
Remove need for poll interval (only covered race condition between isAlive
and notifyAll calls
Add timeout
Conor MacNeill wrote, On 24/07/2003 14.49:
On Thu, 24 Jul 2003 10:26 pm, Nicola Ken Barozzi wrote:
What about:
import file=blah.xml name=blah/
Sure - pretty much what I thought, maybe a more descriptive attribute name
(overrideprefix). It would default to the imported project name.
A bit long...
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16906.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19485.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18754.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Thu, 2003-07-24 at 13:49, Conor MacNeill wrote:
On Thu, 24 Jul 2003 10:26 pm, Nicola Ken Barozzi wrote:
What about:
import file=blah.xml name=blah/
Sure - pretty much what I thought, maybe a more descriptive attribute name
(overrideprefix). It would default to the imported
On Fri, 25 Jul 2003 12:49 am, peter reilly wrote:
So the question is what should B's import be relative to:
1) A.xml's basedir
2) B.xml
3) B.xml's currently ignored basedir attribute.
I think that the consensus is 3).
+1
Conor
a) I personally think that (2) is the least surprising answer,
and furthermore that
b) the effective basedir for the task to operate inside any
imported file should always be the outermost one.
Also,
c) Imported projects which have an explicit basedir specified
should result in a warning
On 24 Jul 2003, peter reilly [EMAIL PROTECTED] wrote:
So the question is what should B's import be relative to:
1) A.xml's basedir
2) B.xml
3) B.xml's currently ignored basedir attribute.
I think that the consensus is 3).
I'm not sure, I'm more along the lines of (3) if B has a
Dominique Devienne wrote, On 24/07/2003 16.55:
...
In other words, the context of execution of any imported file should be the
top level build file. I foresee no end in the confusion that would result
otherwise.
Some might argue that an imported file should be able to know where if was
imported
I'm interested to hear about use bases that would refute my argument on the
other hand, to see what I missed. Thanks, --DD
Say I have build B importing C and I'm using B quite happily.
Then one day, I create A to import B and the import in B of C no longer works
because B had a basedir
This is indeed a valid use of knowledge of where an imported file was
imported from.
I still think (strongly) that the basedir of any imported file should be
ignored (with a warning if it's something else than ., the default), and
always use the one of the top-level build.
To allow the use-case
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21856.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I don't disagree with your scenario in the sense that it would break, but I
disagree that it's either a good usage of import or desirable.
I (strongly again ;) believe that imported build files should be designed to
be imported, and never used without being imported. I would even be
favorable
Did my other messages answer your questions??? --DD
-Original Message-
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 24, 2003 10:09 AM
To: [EMAIL PROTECTED]
Subject: Re: ant 1.5.4 : Import
Dominique Devienne wrote, On 24/07/2003 16.55:
...
In other
Dominique Devienne wrote, On 24/07/2003 17.23:
Did my other messages answer your questions??? --DD
IIUC we agree.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
On Fri, 25 Jul 2003 01:23 am, Dominique Devienne wrote:
I (strongly again ;) believe that imported build files should be designed
to be imported, and never used without being imported.
I disagree (strongly :-). I think augmenting/overriding an existing build file
is a valid use for import. I
Dominique Devienne wrote, On 24/07/2003 17.18:
This is indeed a valid use of knowledge of where an imported file was
imported from.
I still think (strongly) that the basedir of any imported file should be
ignored (with a warning if it's something else than ., the default), and
always use the one
Then have a look at what I did in the past two days to do something similar
;-) I created an antreturn task that piggybacks on ant, and allows
returning properties and/or references from the called build file back into
the caller's context (Project).
That would take care of that use case ;-) --DD
On Fri, 25 Jul 2003 01:36 am, Dominique Devienne wrote:
Then have a look at what I did in the past two days to do something similar
;-) I created an antreturn task that piggybacks on ant, and allows
returning properties and/or references from the called build file back into
the caller's
-Original Message-
From: Conor MacNeill [ mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
Sent: Thursday, July 24, 2003 10:39 AM
To: Ant Developers List
Subject: Re: ant 1.5.4 : Import
On Fri, 25 Jul 2003 01:23 am, Dominique Devienne wrote:
I (strongly again ;) believe that imported
I know ;-) To come back on track, I would still like to be able to set this
attribute if I chose to (getting the behavior I described), while you could
leave it off, and have your cake too.
As a build writer, I want to be able to protect myself from improper (IMO)
use of my build files, which
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21856.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21858.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
If I'm not mistaken then a DCL script can only process a maximum of
8 arguments and the call to a DCL script from Java, including the
script filename and its arguments, can at the most be 256 characters
long.
I'm out of OpenVMs business for too long, to know whether you are
correct.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21860.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21860.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21861.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
antoine 2003/07/24 13:29:10
Modified:src/java/org/apache/tools/ant/gui/xml NamedDOMNodeMap.java
Log:
PR: 21861
this fixes the bug, but I am not sure that my change is done at the best
place.
Revision ChangesPath
1.3 +2 -2
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21861.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21865.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21865.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Wannheden, Knut wrote:
If I'm not mistaken then a DCL script can only process a maximum of
8 arguments and the call to a DCL script from Java, including the
script filename and its arguments, can at the most be 256 characters
long.
I'm out of OpenVMs business for too long, to know whether you are
antoine 2003/07/24 14:32:14
Modified:src/java/org/apache/tools/ant/gui/xml NamedDOMNodeMap.java
Log:
copyright date
Revision ChangesPath
1.4 +12 -12
ant-antidote/src/java/org/apache/tools/ant/gui/xml/NamedDOMNodeMap.java
Index: NamedDOMNodeMap.java
It would be nice if the cvs tasks were rewritten to use a java cvs
implementation rather than the native cvs binary for the os. Is there a java
cvs implementation that is prefered? Thoughts?
-Rob Anderson
-Original Message-
From: Matt [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 24,
77 matches
Mail list logo
