DO NOT REPLY [Bug 15730] - StarTeam performance enhancement
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=15730. 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=15730 StarTeam performance enhancement [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-04-22 02:03 --- Ok, I've now built from the CVS repository (since the nightly build doesn't contain its code and I can verify that it works) so I am marking this one fixed.
DO NOT REPLY [Bug 18884] - stcheckout should handle a convertCRLF flag
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=18884. 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=18884 stcheckout should handle a convertCRLF flag [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|--- |1.6 --- Additional Comments From [EMAIL PROTECTED] 2003-04-22 02:22 --- Submitted patch implements Mr. DeForest's request. One difference - I call the option convertEOL instead of convertCRLF since it works in either direction and is more generic that way. Mr. DeForest - this will not reach the official distribution until 1.6 but it sounds like you have taken care of it on your own in the meantime.
RE: antlib
Happy to help out if I can, and Erik's right, I haven't been monitoring the dev list lately. :-) Stu 4) A framework for managing classloaders where you can specify which classloader to use when loading an antlib. We ought to get Stuart Halloway involved in this effort. He's got a lot of experience and expertise with classloaders and has some specific thoughts on what we can do with Ant to get some more classloader sanity, I think. I'm CC'ing him on this mail in case he's not monitoring the dev list. Erik
Re: antlib
Antoine Levy-Lambert wrote, On 21/04/2003 23.23: ... I would like, based on this email, to read what you find OK and what should be changed in the antlib proposal. Once I have the comments from everybody on the list, we might put them together in a document - including conflicting views if any - and vote. Cool. What I would like to see in antlibs, and that can be quite easily done IMHO, is to make it possible to add an 'autodownload' attribute that can get them from a repository, using Ruper, and versioning. Example: antlib name=ant-contrib version=1.2+ autodownload=true/ This would use the ruper task to get the antlib and load it. It would just need to have the Ruper task in Ant core. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: antlib
- Original Message - From: Erik Hatcher [EMAIL PROTECTED] Also keep in mind that we can use XDoclet to generate these descriptors, if that seems like the right thing to do. I'd be happy to help out with that generation. OK - feel free to add a target in the proposals build.xml to generate the two descriptors which exist already, then the descriptors themselves could be removed from CVS. We ought to get Stuart Halloway involved in this effort. He's got a lot of experience and expertise with classloaders and has some specific thoughts on what we can do with Ant to get some more classloader sanity, I think. I'm CC'ing him on this mail in case he's not monitoring the dev list. I will be glad to have as many experienced people involved in this effort as possible. Antoine
Re: antlib
- Original Message - From: Stu Halloway (DevelopMentor) [EMAIL PROTECTED] Sent: Tuesday, April 22, 2003 5:08 AM Subject: RE: antlib Happy to help out if I can, and Erik's right, I haven't been monitoring the dev list lately. :-) Stu I will be happy too if you review the code of the proposal and suggest improvements. Antoine
cvs commit: ant/xdocs external.xml
bodewig 2003/04/22 00:38:02 Modified:docs external.html xdocsexternal.xml Log: Update Antenna's description. Submitted by: Joerg Pleumann joerg at pleumann dot de Revision ChangesPath 1.112 +11 -6 ant/docs/external.html Index: external.html === RCS file: /home/cvs/ant/docs/external.html,v retrieving revision 1.111 retrieving revision 1.112 diff -u -r1.111 -r1.112 --- external.html 9 Apr 2003 01:44:48 - 1.111 +++ external.html 22 Apr 2003 07:38:01 - 1.112 @@ -1070,12 +1070,17 @@ /td /tr /table -pWith Antenna, you can compile, preverify, package, and -obfuscate your MIDP applications, as well as convert them to -PRC files designed to run on MIDP for PalmOS. The tasks are -mostly built around the Wireless Toolkit and the free -RetroGuard obfuscator, with some additional gimmicks like -automatic version numbering./p +pAntenna provides a set of Ant tasks suitable for developing +wireless Java applications targeted at the Mobile Information +Device Profile (MIDP). With Antenna, you can compile, +preverify, package, obfuscate, and run your MIDP applications +(aka MIDlets), manipulate Java Application Descriptor (JAD) +files, as well as convert JAR files to PRC files designed to +run on MIDP for Palm OS. Deployment is supported via a +deployment task and a corresponding HTTP servlet for +Over-the-Air (OTA) provisioning. A small preprocessor allows +to generate different variants of a MIDlet from a single +source./p table class=ForrestTable cellspacing=1 cellpadding=4 tr th colspan=1 rowspan=1 1.81 +11 -6 ant/xdocs/external.xml Index: external.xml === RCS file: /home/cvs/ant/xdocs/external.xml,v retrieving revision 1.80 retrieving revision 1.81 diff -u -r1.80 -r1.81 --- external.xml 8 Apr 2003 12:42:53 - 1.80 +++ external.xml 22 Apr 2003 07:38:02 - 1.81 @@ -502,12 +502,17 @@ /tr /table -pWith Antenna, you can compile, preverify, package, and -obfuscate your MIDP applications, as well as convert them to -PRC files designed to run on MIDP for PalmOS. The tasks are -mostly built around the Wireless Toolkit and the free -RetroGuard obfuscator, with some additional gimmicks like -automatic version numbering./p +pAntenna provides a set of Ant tasks suitable for developing +wireless Java applications targeted at the Mobile Information +Device Profile (MIDP). With Antenna, you can compile, +preverify, package, obfuscate, and run your MIDP applications +(aka MIDlets), manipulate Java Application Descriptor (JAD) +files, as well as convert JAR files to PRC files designed to +run on MIDP for Palm OS. Deployment is supported via a +deployment task and a corresponding HTTP servlet for +Over-the-Air (OTA) provisioning. A small preprocessor allows +to generate different variants of a MIDlet from a single +source./p table tr
Re: antlib / ruper task
Antoine Levy-Lambert wrote, On 22/04/2003 9.50: ... I am searching for documentation about ruper. I found this http://krysalis.org/cgi-bin/krywiki.pl?Ruper I see that the ruper task depends on common-vfs. If we use Ruper for antlib, which can be very good, then we are making ant core dependent upon common-vfs. Stefan Bodewig wrote : http://marc.theaimsgroup.com/?l=ant-devm=104333061332642w=2 Hmmm, you are right. Ant must be able to bootstrap itself without any additional libraries (apart from an XML parser) is a long-standing requirement for Ant. As using jar is part of the bootstrap process and jar requires the zip classes, we have a problem here, that may be solvable by some CVS tricks. I have not studied what is there in common-vfs, nor what are the dependencies of common-vfs itself. If common-vfs can help us solve more elegantly all the problems we have (such as the old bug 10755, and now some open issues with ftp) accessing resources, and can help ant manipulate with more ease resources (VCS repository entries, FTP or HTTP urls, file system files, zip entries, ...), it might be a good idea. This [ adding new dependencies other than the XML parser ] to ant would require a specific vote outside of or parallel to the antlib discussion. Yes. I guess that for antlib anyone would say ok to it, but it's more about a question of putting Ruper in Ant, and alongside, also commons-vfs. Here is the build sequence that is needed for ruper, taken from the latest Gump descriptors. It's very bad WRT the above points :-/ NOTE TO KRYSALIS DEVS I guess we'll have to make ruper depend *optionally* on commons-vfs, and failback to simple http get if that is not present. So Ant would depend on ruper-light, that is wothout the commons-vfs stuff. Good catch. - Build sequence for krysalis-ruper - bootstrap-ant xml-crimson xjavac xml-xerces xml-apis ant jakarta-log4j junit avalon-logkit commons-logging commons-httpclient jakarta-oro commons-net dist-ant java_cup jlex jakarta-regexp jakarta-bcel xml-xalan2 jaf javamail jmx jsse jakarta-tomcat-util jakarta-servletapi-4 commons-collections commons-beanutils jakarta-servletapi commons-fileupload tomcat-catalina jakarta-tomcat-util-coyote_10 xmlunit saxon javacc jrefactory xjavadoc jrefactory-pretty xdoclet-compile-core xdoclet-xdoclet-module-prepare ejb xdoclet-ejb-module-prepare xdoclet-apache-module-prepare xdoclet-hibernate-module-prepare xdoclet-web-module-prepare jms jdom werken.xpath jakarta-velocity jakarta-site2 mockobjects xdoclet commons-discovery jtidy nekohtml httpunit xml-axis mx4j jakarta-tomcat jakarta-tomcat-coyote jakarta-tomcat-4.0 jakarta-struts jakarta-slide jcifs jsch commons-vfs commons-lang commons-cli krysalis-ruper -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
DO NOT REPLY [Bug 19213] New: - Further Cleanup of the ClasspathUtils.
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=19213. 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=19213 Further Cleanup of the ClasspathUtils. Summary: Further Cleanup of the ClasspathUtils. Product: Ant Version: 1.6Alpha (nightly) Platform: Other OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Introduction of the o.a.t.a.util.ClasspathUtils opened the opportunity for some more refactoring and enhancements. (see bug 18906 see http://marc.theaimsgroup.com/?l=ant-devm=105066678101704w=2) Will add a patch for ClasspathUtils and Definer... -marc=
AW: [VOTE] propertycopy
I took a look at cvs log
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ant-contrib/ant-contrib/src/n
et/sf/antcontrib/property/PropertyCopy.java
The initial version was introduced by SF-user carnold (Curt Arnold) later
modifications
by SF-user bodewig (Stefan Bodewig).
Maybe we can ask them directly?
Jan Matèrne
-Ursprüngliche Nachricht-
Von: Bruce Atherton [mailto:[EMAIL PROTECTED]
Gesendet am: Montag, 21. April 2003 21:22
An: Ant Developers List
Betreff: Re: [VOTE] propertycopy
At 02:19 AM 4/21/2003, you wrote:
I use propertycopy from ant-contrib a lot. I propose that it be
migrated to Ant's HEAD. Objections?
A big +1 from me assuming copyright assignment can be
resolved. We should
also probably add a FAQ entry on how to do multiple levels of
dereferencing
of a property once this is adopted, since that comes up so
frequently with
people trying ${${propname}}.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: [VOTE] propertycopy
And the original author was Matthew Inger.
Peter
On Tuesday 22 April 2003 10:43, [EMAIL PROTECTED] wrote:
I took a look at cvs log
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ant-contrib/ant-contrib/src/
n et/sf/antcontrib/property/PropertyCopy.java
The initial version was introduced by SF-user carnold (Curt Arnold) later
modifications
by SF-user bodewig (Stefan Bodewig).
Maybe we can ask them directly?
Jan Matèrne
-Ursprüngliche Nachricht-
Von: Bruce Atherton [mailto:[EMAIL PROTECTED]
Gesendet am: Montag, 21. April 2003 21:22
An: Ant Developers List
Betreff: Re: [VOTE] propertycopy
At 02:19 AM 4/21/2003, you wrote:
I use propertycopy from ant-contrib a lot. I propose that it be
migrated to Ant's HEAD. Objections?
A big +1 from me assuming copyright assignment can be
resolved. We should
also probably add a FAQ entry on how to do multiple levels of
dereferencing
of a property once this is adopted, since that comes up so
frequently with
people trying ${${propname}}.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test failures (Gump is coming to tell us anyway ...)
Hi, Your guess is nearly right, I originally used beanshell, after modifying it to use apache BSF. When submitting I modified the tests to use javascript, but missed the test to check if script is available. Cheers, Peter On Tuesday 15 April 2003 07:39, Stefan Bodewig wrote: In addition, testScriptFilter fails. It seems as if the new filter was using the old IBM BSF package names, while the rest of Ant has switched to Apache BSF. The later is on my CLASSPATH, so bsf.present gets set and the test is run, but fails due to a java.lang.NoClassDefFoundError: com/ibm/bsf/util/BSFEngineImpl. I'll try to look into them later today but wouldn't mind if anybody else was faster 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/src/main/org/apache/tools/ant/types/selectors ExtendSelector.java
On Tuesday 15 April 2003 01:05, Conor MacNeill wrote: I have some questions about this patch On Tue, 15 Apr 2003 03:21 am, [EMAIL PROTECTED] wrote: +Project.setProjectOnObject(project, o); Why is this a static method rather than a plain method like this: project.setProjectOnObject(o); To save typing if (project != null) Why don't we define an interface for all things that can have a Project instance (Projectable :-)) rather than using reflection? It could be applied to ProjectComponent. Yes, but TaskAdaptor uses reflection to check if the adapted class contains the setProject method. This patch was meant to maintain this behaviour. Peter
RE: antlib
I agree with Stefan. I much prefer to have AntLib *specified*, as in a specification of the contract an AntLib must fullfil to be usable but Ant, than working on the tools themselves to package an AntLib (XDoclet or whatever else), or even an auto-download feature (I've looked at Ruper, and I'm not fond of this implementation, although the principle at play is useful, as demonstrated by Maven). The tools would fall down quite easily once we agree on what's necessary. Regarding AntLib itself, XML descriptor or not, I'm more interested in being able to partition the namespace used by Ant to perform the name to class mapping currently restricted to tasks/types. Maybe something along the lines of Digester, where you can specify a simplified XPath to indicate when a mapping should occur (current mappings are all implicit /**/name or //name to be more XPath compliant), or some role as discussed recently. IMO, if an AntLib doesn't allow specifying a custom Selector, or a custom implementation of a custom interface (by a custom task), both of which configurable using the regular attributes/elements Ant rules, then it's a failure. Peter's proposal, and to a lesser extend mine, both allow to do that, by polluting the types namespace though, and by requiring changes to Tasks/Types to accept custom extensions/beans. In summary, AntLib would finally make Ant pluggable, without requiring to modify its source code every time something needs to be added, just to add a addXXX, or createXXX method, for both built-in tasks, and custom tasks. I don't care much if it uses properties files or XML descriptors for the purpose. --DD
Re: cvs commit: ant/src/main/org/apache/tools/ant/types ZipFileSet.java defaults.properties
On Sat, 19 Apr 2003, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: I have coded the calls to the getters of ZipFileSet similarly to the getters of FileSet or AbstractFileSet in Zip.java. They are the way they look right now because FileSet is much older than ProjectComponent and thus didn't have project instance (same for Path, BTW). Can we safely to change all the getters of AbstractFileSet As long as you keep the old method signatures (of released code, that is) for backwards compatibility, probably yes, but ... From: Conor MacNeill [EMAIL PROTECTED] Hmmm, it may even be a different project instance. is something to consider. I don't think we are testing a scenario where a fileset gets inherited by a subbuild thoroughly, if at all - still we may get away with the help of clone() that is performed in Ant.java. Stefan
Re: antlib
On Tue, 22 Apr 2003, Dominique Devienne [EMAIL PROTECTED] wrote: I agree with Stefan. Cool. Now if only I could find time to respond to Antoine's original mail. 8-) Will try very hard tomorrow. Regarding AntLib itself, XML descriptor or not, I'm more interested in being able to partition the namespace used by Ant to perform the name to class mapping currently restricted to tasks/types. Let's start with tasks and types and see if/how that flies. If we want to extend the plugability to mappers or selectors or whatever (I do), the solution in the end may be a flat namespace (everything is a type) as Costin seems to hint at when he wants to drop the difference between task and type. Stefan
Re: [GUMP] Test Failure - Ant
- Original Message - From: Stefan Bodewig [EMAIL PROTECTED] Sent: Tuesday, April 22, 2003 5:50 PM * In the code of the War.java task, the lib attribute is defined as a ZipFileSet. In the documentation, the same lib attribute is defined as a FileSet. Should we fix the code or the documentation of the War task ? Which documentation? I meant the ant manual page under docs/manual/CoreTasks/war.html Nested elements lib The nested lib element specifies a FileSet. All files included in this fileset will end up in the WEB-INF/lib directory of the war file. -- We don't tell people that lib is a zipfileset because they may get confused when they try to use the prefix attribute then. It must be a zipfileset, so that it can get mapped to prefix=/WEB-INF/lib. What about changing the method signature of War#addLib from addLib(ZipFileSet fs) to addLib(FileSet fs) ? This would also require changing the access of ZipFileSet#ZipFileSet(FileSet fs) from protected to public too. c) or write in WHATSNEW something like : - only references to zipfileset(s) are accepted by tasks using zipfileset(s) as attributes or nested elements. Is this really new? Yes this is new, it was possible to do fileset ... id=xyz/ war lib refid=xyz/ /war before I did my changes. Cheers Antoine
Re: antlib
A flat namespace is a bit problematic :- for example: is containsregexp a filter, condition or a selector The antlib proposal does provide associating the same name to different classes using roles. If a flat namespace is used, there is not much point in proceeding with the xml based descriptors. A patch in bugzilla report 17844 provides a simple alternative (it is however missing needed tasks like antlib and antjar). Peter. On Tuesday 22 April 2003 17:13, Stefan Bodewig wrote: On Tue, 22 Apr 2003, Dominique Devienne [EMAIL PROTECTED] wrote: I agree with Stefan. Cool. Now if only I could find time to respond to Antoine's original mail. 8-) Will try very hard tomorrow. Regarding AntLib itself, XML descriptor or not, I'm more interested in being able to partition the namespace used by Ant to perform the name to class mapping currently restricted to tasks/types. Let's start with tasks and types and see if/how that flies. If we want to extend the plugability to mappers or selectors or whatever (I do), the solution in the end may be a flat namespace (everything is a type) as Costin seems to hint at when he wants to drop the difference between task and type. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: antlib / ruper task
Works just fine for the purpose of doing gets... We don't require anything fancy here. Getting files thru HTTP with timestamp works for me, and has been for a while. I've even done simple stuff like extracting properties from the HTTP header at the same time I'm getting a file (properties added by a custom Jetty-based HTTP server serving meta-data about the file downloaded). I'm not saying it doesn't indeed suck, just that I've never run into the 'suck' part for my simple purposes (using JDK 1.4+). --DD -Original Message- From: Steve Loughran [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 22, 2003 11:20 AM To: Ant Developers List Subject: Re: antlib / ruper task of course, the http stack built in to java sucks, so we need to serve stuff in the subset of valid http that it supports.
RE: antlib
From: Dominique Devienne [mailto:[EMAIL PROTECTED] I agree with Stefan. I much prefer to have AntLib *specified*, as in a specification of the contract an AntLib must fullfil to be usable but Ant, than working on the tools themselves to package an AntLib (XDoclet or whatever else), or even an auto-download feature (I've looked at Ruper, and I'm not fond of this implementation, although the principle at play is useful, as demonstrated by Maven). The tools would fall down quite easily once we agree on what's necessary. I agree with you in principle, but it is more than just a contract that we need to agree, there is also all the issues with respect to execution in the presence of antlibs (should they be inherited in ant calls? How redefinitions are treated? all this in the context of things like the import task and such). Regarding AntLib itself, XML descriptor or not, I'm more interested in being able to partition the namespace used by Ant to perform the name to class mapping currently restricted to tasks/types. Maybe something along the lines of Digester, where you can specify a simplified XPath to indicate when a mapping should occur (current mappings are all implicit /**/name or //name to be more XPath compliant), or some role as discussed recently. The current proposal uses the Role approach. You can define Roles, you can say that a class belongs to a Role and there where changes (not sure how finalized) to the introspectors to connect the two in an element definintion. I wanted to be able to rename imported tasks in case of collision with others comming from different antlibs. I am not sure how XPath could be use to specify roles with that in mind. IMO, if an AntLib doesn't allow specifying a custom Selector, or a custom implementation of a custom interface (by a custom task), both of which configurable using the regular attributes/elements Ant rules, then it's a failure. Peter's proposal, and to a lesser extend mine, both allow to do that, by polluting the types namespace though, and by requiring changes to Tasks/Types to accept custom extensions/beans. We will always would have to change something :-) And you will always will need collaboration from the tasks that accepr a particular Role. What concerns me is that over time every feature of ANT has define its own separate and divergent mechanist for adding new implementations. On of the objectives of ANTLIB woulb be to settle on on mechanism ( modulo backward compatibility) that all existend and future tasks must support and hence obtain more simetry. In summary, AntLib would finally make Ant pluggable, without requiring to modify its source code every time something needs to be added, just to add a addXXX, or createXXX method, for both built-in tasks, and custom tasks. I don't care much if it uses properties files or XML descriptors for the purpose. --DD This has been my dream, since day one of ANTLIB. Now lets take a look at the proposal and let us know what you guys think of it. Jose Alberto
Re: antlib / ruper task
Dominique Devienne wrote: Works just fine for the purpose of doing gets... We don't require anything fancy here. Getting files thru HTTP with timestamp works for me, and has been for a while. I've even done simple stuff like extracting properties from the HTTP header at the same time I'm getting a file (properties added by a custom Jetty-based HTTP server serving meta-data about the file downloaded). I'm not saying it doesn't indeed suck, just that I've never run into the 'suck' part for my simple purposes (using JDK 1.4+). --DD -doesnt let you set 1 cookie -doesnt let you at the text of an error response in some java versions -if you get a response shorter than the content-length header, sometimes it rounds down the result of getContentLength() instead of flagging an error If/when the http tasks in the sandbox make it into ant as an ant-httptasks package, they'll use httpclient for this reason ...etc.
Re: antlib
Jose Alberto Fernandez wrote: Hi guys, I would propose to that instead of antlib calling ruper, the rupper people can provide a ruperautoload task (or whatever other name you want) that will do all the finding and downloading and then will invoque antlib. If we do this, then we can concentrate here on the local antlib while someone else can take care of the external work. Jose Alberto Maybe you can register one or more handlers for missing/out-of-date libraries and people can choose their downloader appropriately. so the gumploader would download and build your dependencies, ruper just pull them from wherever.
cvs commit: ant/src/testcases/org/apache/tools/ant/filters NoNewLineTest.java HeadTailTest.java
umagesh 2003/04/22 11:23:55
Modified:.WHATSNEW build.xml
docs/manual/CoreTypes filterchain.html
src/etc/testcases/filters build.xml
src/etc/testcases/filters/expected head-tail.headtail.test
src/etc/testcases/filters/input head-tail.test
stripjavacomments.test
src/etc/testcases/taskdefs copy.filterset
src/main/org/apache/tools/ant/filters HeadFilter.java
StripJavaComments.java TailFilter.java
TokenFilter.java
src/main/org/apache/tools/ant/util FileUtils.java
src/testcases/org/apache/tools/ant/filters HeadTailTest.java
Added: src/testcases/org/apache/tools/ant/filters
NoNewLineTest.java
Log:
filter readers modify lineendings.
PR: 18476
Submitted by: [EMAIL PROTECTED] (peter reilly)
Revision ChangesPath
1.402 +3 -0 ant/WHATSNEW
Index: WHATSNEW
===
RCS file: /home/cvs/ant/WHATSNEW,v
retrieving revision 1.401
retrieving revision 1.402
diff -u -r1.401 -r1.402
--- WHATSNEW 18 Apr 2003 22:36:18 - 1.401
+++ WHATSNEW 22 Apr 2003 18:23:52 - 1.402
@@ -32,6 +32,9 @@
Fixed bugs:
---
+* Filter readers were not handling line endings properly. Bugzilla
+ Report 18476.
+
* Expand tasks did not behave as expected with PatternSets.
* property environment=... / now works on OS/400.
1.367 +1 -1 ant/build.xml
Index: build.xml
===
RCS file: /home/cvs/ant/build.xml,v
retrieving revision 1.366
retrieving revision 1.367
diff -u -r1.366 -r1.367
--- build.xml 17 Apr 2003 13:09:17 - 1.366
+++ build.xml 22 Apr 2003 18:23:53 - 1.367
@@ -277,7 +277,7 @@
patternset id=teststhatfail
exclude name=${optional.package}/BeanShellScriptTest.java/
exclude name=${ant.package}/taskdefs/ImportTest.java/
-exclude name=${ant.package}/filters/HeadTailTest.java/
+!--exclude name=${ant.package}/filters/HeadTailTest.java/ --
/patternset
!--
1.9 +30 -3 ant/docs/manual/CoreTypes/filterchain.html
Index: filterchain.html
===
RCS file: /home/cvs/ant/docs/manual/CoreTypes/filterchain.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- filterchain.html 14 Apr 2003 18:07:31 - 1.8
+++ filterchain.html 22 Apr 2003 18:23:54 - 1.9
@@ -898,10 +898,24 @@
The tokenizer delimits lines
by \r, \n or \r\n.
This is the default tokenizer.
+TABLE cellSpacing=0 cellPadding=2 border=1
+ TR
+TD vAlign=topBAttribute/B/TD
+TD vAlign=topBDescription/B/TD
+TD vAlign=top align=centerBRequired/B/TD
+ /TR
+ TR
+TD vAlign=topincludeDelims/TD
+TD vAlign=top
+ Include the line endings in the token.
+ Default is false.
+/TD
+TD vAlign=top align=centerNo/TD
+ /TR
+/TABLE
H4Examples:/H4
Convert input current line endings to unix style line endings.
-emThis currently has no effect when used in the copy task./em
BLOCKQUOTEPRE
lt;tokenfilter delimoutput=quot;\nquot;/gt;
/PRE/BLOCKQUOTE
@@ -955,13 +969,26 @@
tr
td valign=topdelimsaretokens/td
td valign=topIf this is true,
- each delimiter character is returned as a token/td
+ each delimiter character is returned as a token.
+ Default is false.
+/td
td valign=top align=centerNo/td
/tr
tr
td valign=topsuppressdelims/td
-td valign=topIf this is true, delimiters are not returned. /td
+td valign=top
+ If this is true, delimiters are not returned.
+ Default is false.
+/td
td valign=top align=centerNo/td
+ /tr
+ tr
+td vAlign=topincludeDelims/td
+td vAlign=top
+ Include the delimiters in the token.
+ Default is false.
+/td
+td vAlign=top align=centerNo/td
/tr
/TABLE
1.5 +14 -3 ant/src/etc/testcases/filters/build.xml
Index: build.xml
===
RCS file: /home/cvs/ant/src/etc/testcases/filters/build.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- build.xml 9 Apr 2003 15:28:51 - 1.4
+++ build.xml 22 Apr 2003 18:23:54 - 1.5
@@ -20,11 +20,11 @@
/filterreader
/filterchain
/copy
-!--fixcrlf srcdir=result eol=lf
+!--fixcrlf srcdir=result eol=lf
include name=linecontains.test/
-/fixcrlf--
+/fixcrlf--
/target
-
+
target name=testEscapeUnicode
ERROR: unknown key letter (cm1)
Hello, Anyone has solution/cause for following error. Thanks Nafis [pvcs] Getting files [pvcs] Executing get -N @/tmp_mnt/home/auto/ch1npat1/pvcs_ant_5070228153567178712.log Execute:Java13CommandLauncher: Executing 'get' with arguments: '-N' '@/tmp_mnt/home/auto/ch1npat1/pvcs_ant_5070228153567178712.log' The ' characters around the executable and arguments are not part of the command. [pvcs] ERROR: unknown key letter (cm1) BUILD FAILED file:/tmp_mnt/home/auto/ch1npat1/build.xml:14: Failed executing: get -N @/tmp_mnt/home/auto/ch1npat1/pvcs_ant_5070228153567178712.log. Return code was 1 at org.apache.tools.ant.taskdefs.optional.pvcs.Pvcs.execute(Pvcs.java:280) at org.apache.tools.ant.Task.perform(Task.java:341) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:336) at org.apache.tools.ant.Project.executeTarget(Project.java:1339) at org.apache.tools.ant.Project.executeTargets(Project.java:1255) at org.apache.tools.ant.Main.runBuild(Main.java:609) at org.apache.tools.ant.Main.start(Main.java:196) at org.apache.tools.ant.Main.main(Main.java:235) _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
Backward incompatible change in war task?
Hi there,
probably some of you are already aware of this problem since I posted
about it on the Gump ML. I've never been a power ant user, and I never
participated in the ant development process so please forgive me if this
discussion has been already done in the past (apart from
http://marc.theaimsgroup.com/?l=ant-devm=105077339807455w=2 I was
unable to find a particular reference to that).
In short, our beloved friend Gump found while building Xindice what I'd
label as a backward incompatible change in the war task. In
Xindice-land we are using the war task together with a lib subtask
that points (refid) to a fileset:
war
destfile=${dist.dir}/${project.filename}-${project.version}.war
update=false
webxml=config/web.xml
classes dir=${src.build.dir}/
webinf dir=config
include name=system.xml/
/webinf
lib refid=core.jars /
where core.jars is defined as a plain fileset in the project section.
Needless to say, this label is used elsewhere in the file so having it
as a refid makes it more mantainable for us: I don't consider a real
option to expand it inside the war target.
Unfortunately the Ant CVS version seems to accept only zipfilesets as
the argument to the lib element:
/home/rubys/jakarta/xml-xindice/build.xml:336: core.jars doesn't denote
a zipfileset
This is not easy to fix, since in turn the stable (released) version of
Ant (up to 1.5.3) doesn't allow for zipfileset in the project section.
So we're bitten by a chicken and egg problem, since we should either
ship the CVS version of Ant or just forget about it and let our Gump
builds fail. I don't like either option, so I'm wondering if there is a
solution I'm missing (again, I'm not an Ant guru at all), a reason for
this particular backward incompatible change, or a chance to see it
corrected in Ant CVS: my take is that not only Xindice will be bitten by
this.
TIA,
--
Gianugo Rabellino
Pro-netics s.r.l.
http://www.pro-netics.com
cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs JavaTest.java
antoine 2003/04/22 15:12:53
Modified:src/main/org/apache/tools/ant/taskdefs Java.java
docs/manual/CoreTasks java.html
src/etc/testcases/taskdefs java.xml
src/testcases/org/apache/tools/ant/taskdefs JavaTest.java
Log:
allow to set a property with the exit code of java bugrep 19099 submitted by
Donal Quinlan (donal at savvion dot com)
Revision ChangesPath
1.58 +24 -0 ant/src/main/org/apache/tools/ant/taskdefs/Java.java
Index: Java.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Java.java,v
retrieving revision 1.57
retrieving revision 1.58
diff -u -r1.57 -r1.58
--- Java.java 7 Mar 2003 11:23:01 - 1.57
+++ Java.java 22 Apr 2003 22:12:53 - 1.58
@@ -75,6 +75,7 @@
* @author Stefano Mazzocchi
* a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/a
* @author Stefan Bodewig
+ * @author a href=mailto:[EMAIL PROTECTED]Donal Quinlan/a
*
* @since Ant 1.1
*
@@ -91,6 +92,7 @@
private boolean append = false;
private Long timeout = null;
private Redirector redirector = new Redirector(this);
+private String resultProperty;
/**
* Do the execution.
*/
@@ -106,6 +108,7 @@
log(Java Result: + err, Project.MSG_ERR);
}
}
+maybeSetResultPropertyValue(err);
} finally {
dir = savedDir;
}
@@ -241,6 +244,27 @@
return cmdl.createArgument();
}
+/**
+ * The name of a property in which the return code of the
+ * command should be stored. Only of interest if failonerror=false.
+ *
+ * @since Ant 1.6
+ */
+public void setResultProperty(String resultProperty) {
+this.resultProperty = resultProperty;
+}
+
+/**
+ * helper method to set result property to the
+ * passed in value if appropriate
+ */
+protected void maybeSetResultPropertyValue(int result) {
+String res = Integer.toString(result);
+if (resultProperty != null) {
+project.setNewProperty(resultProperty, res);
+}
+}
+
/**
* If true, execute in a new VM.
*/
1.17 +18 -1 ant/docs/manual/CoreTasks/java.html
Index: java.html
===
RCS file: /home/cvs/ant/docs/manual/CoreTasks/java.html,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- java.html 9 Feb 2003 22:10:57 - 1.16
+++ java.html 22 Apr 2003 22:12:53 - 1.17
@@ -84,6 +84,13 @@
td align=center valign=topNo/td
/tr
tr
+td valign=topresultproperty/td
+td valign=topThe name of a property in which the return code of the
+ command should be stored. Only of interest if failonerror=false
+ and if fork=true./td
+td align=center valign=topNo/td
+ /tr
+ tr
td valign=topdir/td
td valign=topThe directory to invoke the VM in. (ignored if
fork is disabled)/td
@@ -179,6 +186,16 @@
forked VM via nested ienv/i elements. See the description in the
section about a href=exec.html#envexec/a/p
pSettings will be ignored if fork is disabled./p
+
+h3Errors and return codes/h3
+By default the return code of a lt;javagt; is ignored. Alternatively, you
can set coderesultproperty/code to the name
+of a property and have it assigned to the result code (barring immutability,
+of course).
+When you set codefailonerror=true/code, the only possible value for
coderesultproperty/code is 0. Any non zero response is treated as an
+error and would mean the build exits.
+p Similarly, if codefailonerror=false/code and
codefork=false/code
+, then codelt;javagt;/code bmust/b return 0 otherwise the build
will exit, as the class was run by the build jvm./p
+
h3Examples/h3
pre
lt;java classname=quot;test.Mainquot;gt;
@@ -218,7 +235,7 @@
JVM, as it takes different parameters for other JVMs,
That JVM can be started from lt;execgt; if required.
hr
-p align=centerCopyright copy; 2000-2002 Apache Software Foundation. All
rights
+p align=centerCopyright copy; 2000-2003 Apache Software Foundation. All
rights
Reserved./p
/body
1.5 +21 -0 ant/src/etc/testcases/taskdefs/java.xml
Index: java.xml
===
RCS file: /home/cvs/ant/src/etc/testcases/taskdefs/java.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- java.xml 24 Jul 2002 15:43:28 - 1.4
+++ java.xml 22 Apr 2003 22:12:53 - 1.5
@@ -89,5 +89,26 @@
/java
/target
+ target
DO NOT REPLY [Bug 19237] New: - SSHExec task should fail if remote command fails
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=19237. 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=19237 SSHExec task should fail if remote command fails Summary: SSHExec task should fail if remote command fails Product: Ant Version: 1.6Alpha (nightly) Platform: All OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Optional Tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The success/failure of the sshexec task is only dependant on whether or not you can connect to the remote host. The task should evaluate the exit status of the remote command to determine the success or failure of the task.
Fwd: Xindice: a final suggestion
FYI. Begin forwarded message: From: Gianugo Rabellino [EMAIL PROTECTED] Date: Tue Apr 22, 2003 1:35:06 PM US/Eastern To: Gump code and data gump@jakarta.apache.org Subject: Xindice: a final suggestion Reply-To: Gump code and data gump@jakarta.apache.org As some of you might have noticed, Xindice is failing again, this time on a wicked part: in order to keep the build clean, a fileset of jars is specified at a project level and reused further on during the build: classpaths are set using this fileset and the fileset itself is used to configure the lib dir on the war task. Now, Gump build is just fine, but packaging fails because the latest Ant *from CVS* expects a zipfileset as the parameter of the war/lib element, while we just have a fileset. Even more: the *current* (stable) release of Ant supports only filesetat a project level, not zipfileset, so I cannot change the build file to accomodate the new ANT expected settings. Now, this is exactly the problem that Gump is supposed to anticipate, but what would be the best solution? 1. tell Gump not to build the war (ugly workaround from a Gump POV); 2. upgrade our Ant version to the CVS one (somehow scary); 3. have a less maintainable build file removing the fileset and duplicating the list (ugly workaround from an Xindice POV); 4. don't use the war task altogether and roll back to the jar one (don't like it); 5. Bug the Ant developers so that they rollback the change to the War task, accepting also plain filesets as it was in the past: this sounds like the best solution to me since it was them to introduce a backward incompatible change (but I'm sure it was for a reason). I'm kinda stuck. Suggestions? TIA, -- Gianugo Rabellino Pro-netics s.r.l. http://www.pro-netics.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
