Re: [ANN] Ant 1.5.2 Released!
Congratulations everyone! I've updated the Jakarta site (listed Ant under elsewhere ;-), freshmeat and sent an announcement to Usenet. I'm back from my flu (this is what your kids are taking home from the kindergarten 8-) and readily packed with anti-histamin to resist the now blossoming birch trees (I hope), so I should be back in the game. Cheers Stefan
Re: How do you communicate with an administrator of bugzilla?
On Tue, 4 Mar 2003, Steve Cohen [EMAIL PROTECTED] wrote: I want to change the email address by which I am known to Bugzilla. This requires some extra bugzilla karma (more than I have). [EMAIL PROTECTED] is supposed to be the role-account for people with sufficient administrative privileges IIRC. Stefan
Re: [SUBMIT] scp
On Thu, 6 Mar 2003, Joe Consumer [EMAIL PROTECTED] wrote: but I read on the jcraft site, that jsch requires 1.4 so I didn't bother. Two weeks ago or so I posted to the jsch list that I have successfully used jsch with JDK 1.2 (and 1.3) and bouncycastle's JCE implementation http://www.bouncycastle.org/. They say JDK 1.4 as jsch uses JCE and this is part of 1.4 - but JCE is available from Sun for JDK 1.2.2+ and bouncycastle's version works better than Sun's in my experience. Does it work on 1.2? Yes. Stefan
Re: tests failing
On Sun, 9 Mar 2003, Steve Loughran [EMAIL PROTECTED] wrote: i have been lax on running tests for a while; now I am seeing (on winXP, single CPU) Is this from CVS HEAD? Looks like the bug Nico's patch was supposed to fix (i.e. http://cvs.apache.org/viewcvs/ant/src/main/org/apache/tools/ant/taskdefs/Zip.java.diff?r1=1.97r2=1.98). But then again Nico reported he still had problems with the test and he's using Windows AFAIK. Needless to say it passes on my machines (Linux, MacOS X and Solaris) and seems to pass in Gump (running on Linux and Solaris) as well. Stefan
Re: cvs commit: ant/src/etc/testcases/taskdefs/optional/dotnet HelloWorld.wsdl example.cs example.il example2.il
On 10 Mar 2003, [EMAIL PROTECTED] wrote: ant/src/etc/testcases/taskdefs/optional/dotnet/example2.il // Copyright (C) Microsoft Corporation 1998-2001. All rights reserved. I realize that this file may be a generated file, but I think this copyright notice is, uhm, problematic. Stefan
Re: ssh exec task...
Hi Robert, as you may have seen, our mailing list software strips all HTML parts from mails. I'm sure there has been some message in addition to the tarball 8-) I've committed modified versions of your code - in particular I've made the password part of user:[EMAIL PROTECTED]:/path optional to really enable key based authentication for scp and made your SSHExec task use SSHBase (more than it did before, at least 8-). The main thing missing now is documentation for sshexec. Stefan
Re: [GUMP] Test Failure - Ant
On Tue, 11 Mar 2003, Steve Loughran [EMAIL PROTECTED] wrote: OK, this is me, I need to set up the build to exclude DotnetTest I've already taken care of it. Stefan
Re: ssh exec task...
On Tue, 11 Mar 2003, Rob H. Anderson [EMAIL PROTECTED] wrote: There is one problem with the sshexec task that someone should look into: I was not able to get the output from the remote command to show up in the log. It works if my machine (the one running Ant) is under heavy load, but doesn't otherwise. 8-( The problem seems to be (from some cursory code review on jsch) that jsch spawns a thread to execute the command - and the task may very well be finished (and Ant exited) before the thread gets run. I will work on some documentation to go with it. Great. Stefan
Re: 1.6 milestones ?
On Wed, 12 Mar 2003, Costin Manolache [EMAIL PROTECTED] wrote: It'll have documentation after it is reviewed by more people and we know it's going to be stable. I don't like this approach at all. How are you expecting user feedback on an undocumented feature? Stefan
Re: 1.6 milestones ?
On Wed, 12 Mar 2003, Costin Manolache [EMAIL PROTECTED] wrote: Do we have any plan or idea on when we'll start distributing 1.6 milestone builds ? Ant has never released any milestone builds so far, so no, there is no plan yet AFAIK. If there was, you'd know it for sure 8-) Before we release a milestone we should make sure that whatever we release at least passes our tests (including the currently disabled ImportTest) and doesn't have any known regressions (see my mail of yesterday). And then I'd really love to have a rundown of the new features (I was swamped when you committed the parts coming from the embed proposal and lost track of it, a simple short list would suffice for starters) and look at them one by one to get consensus on whether we want them - if we can't agree on a given feature, it shouldn't be included in a milestone at all IMHO. Stefan
Re: JDK 1.1 support
On Fri, 14 Mar 2003, Conor MacNeill [EMAIL PROTECTED] wrote: 1. Make Ant 1.6.x the last JDK 1.1 release. This would be clearly documented Fine with me. I'd like to keep 1.6 compatible to JDK 1.1, though. When we make 1.2 a requirement, we'd better start using collections and URLClassloader consistently - and doing this for 1.6 would push 1.6 even further down the timeline. 2. Make the subsequent release require JDK 1.2+ (what about leap frogging to later versions?) 1.2 OS/2 and the BSDs (not FreeBSD, but the rest of the pack) are the only OSes I'm aware of that don't have a decent 1.2+ VM yet, but there are quite a few without a stable 1.4 VM (and I don't think 1.3 would give us too much, proxies, but what else?). 3. Name this subsequent release Ant 2.0 (due to its change in system requirements) +0 4. Drop all the Ant2 cruft from the website. OK. Just as a data point, CVS HEAD (Ant 1.6) has not compiled against JDK 1.1 for a while now (due to diagnostics changes). But I've nagged Steve about it and promise to fix it during the next few weeks. 8-) Stefan
Re: New External Task
I've changed the page in CVS, the site should be updated sometime during the next few hours via cron. Stefan
Re: cvs commit: ant/src/testcases/org/apache/tools/ant/filters EscapeUnicodeTest.java
On 14 Mar 2003, [EMAIL PROTECTED] wrote: New filter escapeunicode that translates non-ASCII characters to \u1234 escapes. Maybe we want to rename that to native2ascii? IIUC correctly it does the same thing as the task or Sun's tool of that name (only that the filter will also recode the latin-1 part (i.e. the eight but not seven bit characters). + target name=testEscapeUnicode depends=init snip +fixcrlf srcdir=result eol=crlf + include name=escapeunicode.test/ +/fixcrlf /target Became necessary as filtering copy converts the line ends to the platform's version (and the original files from Antoine have DOS line ends and contain binary characters so I had to commit them with -kb). I'm not really sure whether this is expected behavior or a bug in copy. Stefan
Re: New related project
On Mon, 17 Mar 2003, Jan Materne [EMAIL PROTECTED] wrote: I see a new project with it´s Ant tasks: www.AndroMDA.org . we usually don't go and search for projects to add, but wait for them to ask us 8-) Anyway, thanks for the pointer, I've added it - will appear on the site when cron kicks in. Stefan
Re: New J2ME Ant task
On Mon, 17 Mar 2003, Steve Neal [EMAIL PROTECTED] wrote: I've implemented this task recently to help with J2ME development Just out of curiosity, what has been wrong with one of the three existing sets of tasks? I've added the pointer, it should appear on the site within the next few hours. Stefan
CLAs for all committers
Dear co-committers, as you probably (hopefully) know, all of us need to sign the Contributor License Agreement that can be found here http://www.apache.org/foundation/ASF_Contributor_License_1_form.pdf. Now there is a very simple and quick check to see whether you have done so (or just think you have): visit this page http://www.apache.org/~jim/committers.html. If your name is in italics, the secretary of the ASF has received the CLA. If it isn't, well, there is something waiting for you to get printed out and sent (by snail-mail to keep Jim's FAX from exploding 8-) to the address given in the CLA. Please do so Stefan
Re: [VOTE] JDK 1.1 support
On Thu, 20 Mar 2003, Conor MacNeill [EMAIL PROTECTED] wrote: On Wed, 19 Mar 2003 06:13 pm, Stefan Bodewig wrote: -0 and +1 on doing it after 1.6. I think this is a majority vote, isn't it? Your -0 isn't a veto, in any case. I know, and I wouldn't want it to be one. Do you have some reservations? Is it just a timing issue? Mainly a timing issue, yes. I realize that the split-up optional.jar thing is almost crying for help from URLClassLoader, so I almost buy that a switch now is necessary. It just feels (to me) better to do such a move completely than doing it in an incosistent manner. Stefan
Re: ssh exec task...
On Wed, 19 Mar 2003, Dale Anson [EMAIL PROTECTED] wrote: I've asked Atsuhiko (the jsch author) to make a minor change, he says it will be included in the next release, scheduled for tomorrow. Cool. I'll modify the task to capture the output correctly and make the maxwait attribute actually work. Can you rename it to timeout (to mirror exec) at the same time? I didn't see the jsch.jar file in Ant cvs, And it will never go there. how are optional libraries like this generally handled? We expect developers to install them themselves. Stefan
Re: Perforce patch for 1.5.3
On Wed, 19 Mar 2003, Matt Bishop [EMAIL PROTECTED] wrote: I'd like someone to look at this patch for 1.5.3; Have you seen Antoine's comment on the bugrep that says your patch didn't change anything for him? To be honest, I don't see how it would help either as the exception is going to be thrown in a different thread than the task is running in, no? Stefan
Re: java 1.1 on linux
On Tue, 18 Mar 2003, peter reilly [EMAIL PROTECTED] wrote: 1.5.1 and 1.5: java.lang.ClassFormatError: Bad major version number I do not get this on an admittedly simple build file using Blackdown's 1.1.8. I.e. Ant 1.5.1 from the binary tar.gz version seems to work with JDK 1.1 for me. This may be fixed by recompiling ant or it may be due to the fact that ant-contrib uses 1.2 isms. Does that mean I should use one of the ant-contrib tasks to reproduce the problem? Maybe the ant-contrib stuff has been compiled with JDK 1.4. Where have you obtained it (self-compiled?)? Stefan
Re: ssh exec task...
On Thu, 20 Mar 2003, Dale Anson [EMAIL PROTECTED] wrote: One more question -- how is documentation handled? The same way as code, you send patches (diff -u). Docs are a bit more difficult if you want to send in complete new files as our mailing list configuration will not accept any HTML part in mails - you'd have to zip them or something. The documentation currently consists of static HTML pages, the docs for sshexec are in docs/manual/OptionalTasks/sshexec.html in Ant's CVS module. We may or may not switch to generated docs (generated from comments in the sources), but we are not there yet. Stefan
Re: Dynamic Configurator
On Thu, 20 Mar 2003, Brett Wooldridge [EMAIL PROTECTED] wrote: When I run ant, I see that createDynamicElement() gets called twice for the junit element, and further that setDynamicAttribute() gets called twice for someattr. This certainly sounds like a bug. We don't call the attribute setters or nested creators/storers twice for normal elements either. I put a Thread.dumpStack() inside of my implementations of those methods, and can provide the stacks for the two calls (they ARE different) if that would help. I think it would, yes. Stefan
AntClassLoader in 1.6
Hi, if we are going to go the 1.2+ route for Ant 1.6, can we change AntClassLoader in a way that Grant is going to work again (I vaguely recall something about a no-arg constructor being added or removed or something 8-). This would make the jelly-tags-html Gump build failure either go away or change to something easier to solve. Stefan
Re: JBuilder Gel IDE Integration
On Tue, 25 Mar 2003, Paul King [EMAIL PROTECTED] wrote: I didn't submit a bug on this 'cause I wasn't sure if this should normally come from the vendor themselves. Well, let's say we are not searching for the information, but add them when they get sent to us. Some vendors actually seem to care for this list (the NetBeans folks regularly send updates) while most don't. But here are the details if anyone wants to make the update. I'll look into it. Stefan
Re: JBuilder Gel IDE Integration
On Tue, 25 Mar 2003, Paul King [EMAIL PROTECTED] wrote: GEL IDE for Windows License: Freeware Isn't very specific and the site doesn't seem to give more details. I've downloaded the latest RC to see whether there are more license details but the setup.exe doesn't do any good on my Linux box 8-) Could you please take a look and pull out the exact words of the license? Freeware is applied to software licensed under GPL as well as stuff that is in the public domain. Stefan
Cygwin tester needed
Hi, please take a look at http://issues.apache.org/bugzilla/show_bug.cgi?id=17721. I can reprodice this bug, but I'm afraid that the proposed patch will break Cygwin - as I have no idea how it handles absolute paths. The change would be in line 54 of the ant wrapper script (CVS HEAD), instead of if expr $link : '.*/.*' /dev/null; then we'd use if expr $link : '^/.*' /dev/null; then Oh, to run into this code, you must not set ANT_HOME and the script you invoke must be a symlink (is this possible on Cygwin?) to the real script. Stefan
Re: ssh exec task...
On Tue, 25 Mar 2003, Dale Anson [EMAIL PROTECTED] wrote: Attached are updates for the SSHExec task and documentation as diffs. The updates fix the problem with output not always showing on the screen (or log). Thanks. I'll commit them after the release of jsch 0.1.3 final. While I was at it, I fixed the timeout attribute so it actually does something, 8-) plus I added some attributes from the exec task that seemed appropriate: output write the output to a file append append to or overwrite the output file outputproperty store the output in a property input and inputstring are additional candidates IMHO. Thanks! Stefan
Re: Request for downloadable Ant Manual in pdf Thank you
On Tue, 25 Mar 2003, Steve Loughran [EMAIL PROTECTED] wrote: I am sure we could probably do a PDF build from the xdocs stuff now, I'm sure, too. if we somehow create docbook content via XSLT, velocity, whatever. Why docbook? You could create the XSL:FO directly, no? Please note that this is not the official documentation. When in doubt, please consult the online manual. then the source :) 8-) I completely realize that Erik and you have helped to improve the manual a lot (and not just the manual) while writing the book, because you've used the source. It's just that 1.5.3 is a bit different from 1.5 in some places. Stefan
Re: Cygwin tester needed
On Tue, 25 Mar 2003, Stefan Moebius [EMAIL PROTECTED] wrote: warning: unportable BRE: `^/.*': using `^' as the first character of the basic regular expression is not portable; That's funny. The GNU man pages of expr(1) are a bit vague here (they talk about anchored expressions in context of the : operator) - at least the man pages installed on my RedHat 7.3 box. The FreeBSD and Mac OS X pages state that a leading ^ would be added implicitly and it seems to work on Solaris as well. So I think we'll go without the leading ^. This seems to be POSIX.2 conformant as well. So basically, the modification works as expected. Great, thanks. Stefan
Re: [patch] [bugfix] IntrospectionHelper.java
On Wed, 26 Mar 2003, Neeme Praks [EMAIL PROTECTED] wrote: Stefan Bodewig :: On Sat, 01 Mar 2003, Neeme Praks [EMAIL PROTECTED] wrote: storeElement() method silently returns, if the tag does not support the specified element. This is because storeElement can never be called without calling createElement before that from within Ant. It may be different from within Jelly, I don't know. So, could we fix this? Sure. You mean you want to fix Jelly? 8-) If you don't invoke createElement before you call storeElement, you are probable in trouble anyway. I'm going to throw in the extra check in CVS HEAD later today/tomorrow. Stefan
Re: Artima SuiteRunner Task
On Wed, 26 Mar 2003, Adam Duffy [EMAIL PROTECTED] wrote: Myself and Leigh Ishikawa (Adding 'setName' support to the xmljunitresultformatter.java) have not received any response to our contributions. Can someone please advise? First advice would be to be more patient, four hours isn't that much 8-) Looking into contributions is something that takes time and all of us here are volunteers. It is not unusual to get no response for days, and I'll admit that occasionally there will be no response at all. In your case, I have no idea what Artima SuiteRunner is, so a contribution that focusses on it will not catch my attention. It will go into a queue of mails and I'll hope that another committer - somebody who knows what you are talking about ;-) - will get to it first. Dominique's comments suggest that it is some kind of testing tool, nice. So now the more general response: For quite some time we've become very reluctant to add new tasks. Especially tasks that are tied to third party products - we generally prefer to see them outside of Ant and with this product. The reason is that Ant already contains far too many tasks that no committer can really test and support - this leaves us in a position where we are not doing any good to our users, nor to ourselves. Tasks have to be supported. If no committer is able to support it directly, we have to rely on people less tightly connected to Ant. In many cases the original authors of a task have disappeared and when we receive patches for their tasks, reviewing those patches becomes painful. Cheers Stefan
Re: Artima SuiteRunner Task
On Wed, 26 Mar 2003, Dominique Devienne [EMAIL PROTECTED] wrote: That said (one more ;-), if Ant ever comes up with an easier way to integrate third party tasks Easier than taskdef resource=...classpath ...//taskdef? Almost impossible. Stefan
Re: Artima SuiteRunner Task
On Wed, 26 Mar 2003, Dominique Devienne [EMAIL PROTECTED] wrote: Hu, not totally. Did I forget to put that smiley in? Since you now use twice the classpath, if needs to be outside and refid'd. No, you'll need to use the loaderref attribute. And what about the junit task? Easy in Ant 1.6, it comes in a jar of its own. Ant's default install will most probably need to keep it on the system classpath. This backwards compatibility thing, you know. I believe it can and should be easier and more flexible. Agreed. Stefan
Re: Artima SuiteRunner Task
On Wed, 26 Mar 2003, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: Do we have a real-world candidate for antlib resource=.. classpathref=.. / ant-contrib's cpptasks, this includes custom tasks and types. Stefan
Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/starteam TreeBasedTask.java
On 27 Mar 2003, [EMAIL PROTECTED] wrote:
log(checking label + stLabel.getName(), Project.MSG_DEBUG);
- if (stLabel.getName().equals(this.label)) {
+ if (stLabel != null !stLabel.isDeleted()
stLabel.getName().equals(this.label)) {
given that the log line will have thrown a NPE if the first test in
the if statement fails, it looks a bit redundant 8-)
I've kept it in anyway.
Stefan
Merging fixes for 17646 and 17721 into 1.5.3?
The starteam patch looks innocent and the wrapper script change has been tested on Cygwin, Linux, MacOS X and Solaris and is know to work (and the corresponding bug report has been verified). But then again we've just released beta1 and I'm becoming more and more reluctant to changes post beta (they've caused some trouble in 1.5 IIRC - and it has probably been my fault). In this case, I'd favor to merge them in. Stefan
Re: JBuilder Gel IDE Integration
On Wed, 26 Mar 2003, Paul King [EMAIL PROTECTED] wrote: P.S. Another suggestion: the external.html page has no internal navigation to get to the three sections: Tasks, Compiler Implementations and IDE and Editor Integration fixed in CVS - and soon at the site, thanks. (Sorry, I know I should be looking at doing diff's but I haven't looked into how the doco is generated these days). http://ant.apache.org/faq.html#creating-faq applies here as well. Stefan
Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs Copy.java
On 28 Mar 2003, [EMAIL PROTECTED] wrote:
- public void setFailOnError(boolean failonerror) {
- this.failonerror = failonerror;
- }
+public void setFailOnError(boolean failonerror) {
+this.failonerror = failonerror;
+}
I have no idea what's happened here, especially since I've made the
last commit to that file yesterday and can't remember running a code
formatter over it after that (or something similar).
Stefan
junit, fork and CLASSPATH
Hi, I'm currently looking into Bug 14971. This bug points out an inconsistency in junit that has been there for ages and I'm a bit unsure on how to fix it. junit fork=true includeantruntime=yes will run the forked tests with a classpath containing ant.jar, optional.jar and junit.jar, nothing else. junit fork=true includeantruntime=no will run the forked tests with whatever is in the CLASSPATH env variable as it doesn't pass an explicit -classpath argument at all. If the junit task has a nested classpath, things are different, your CLASSPATH will never be used as there will always be a -classpath argument. I'm not sure, how this should be resolved. Even if we add a new attribute, I don't see a default setting that would preserve the old behavior. Well, maybe I do. Something like addsystemclasspath with a default of false that would query the native environment for CLASSPATH. Maybe we don't have a bug at all and we can say that you get exactly the classpath you are asking for? This doesn't hold as you don't get an empty CLASSPATH when you specify nothing. Ideas? Stefan
Re: [GUMP] Test Failure - Ant
This is bug 17807, I knew it would happen, I'll take care of it http://issues.apache.org/bugzilla/show_bug.cgi?id=17807 Stefan
Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional ANTLRTest.java
Note that test8 is now going to fail. test8 expects a BuildException to be thrown because the supergrammar file didn't exist. The real reason for the exception that has been thrown so far was that the outputdirectory didn't exist, I've fixed that. Now antlr will pront a warning error: file non-existant-file.g not found but return with an exit code of 0 so the task doesn't see an error. We will have to parse the output, I'm afraid. I wonder whether the now modified test would have passed with ANTLR 2.7.1 or whether it has been broken since its creation. Stefan
Re: [Patch] for antlib proposal (sorry attachment was incomplete in previous email)
On Tue, 1 Apr 2003, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: Please submit quickly if you can to allow work on this proposal to resume. Quick enough? Stefan
Re: ssh exec task...
On 01 Apr 2003, Stefan Bodewig [EMAIL PROTECTED] wrote: The main difference (apart from formatting changes) are that timeout uses milliseconds as its value and defaults to 0 (like exec) Stefan
Re: ssh exec task...
On Tue, 01 Apr 2003, Dale Anson [EMAIL PROTECTED] wrote: I take it you saw that jsch 0.1.3 was released this morning? Yep. Would you mind making one other minor change to the docs, it references jsch 0.1.2 as a requirement, but 0.1.3 is the minimum. Already changed in CVS. 8-) Stefan
Re: Patch JavaCC - KEEP_LINE_COLUMN, JJTree - OUTPUT_FILE and new tas kdef JJDoc
On Wed, 2 Apr 2003, Jene Jasper [EMAIL PROTECTED] wrote: As mentioned yesterday, I have made some changes to the JavaCC and JJTree taskdefs and added a new taskdef for JJDoc. I have included the patch.txt for the changes. But what is the best way to deliver the new files JJDoc.java and jjdoc.html ? Create an enhancement request in Bugzilla, attach this patch and the two new files. Does your patch include the JavaCC 3.0/2.1 changes? I'd like to tackle that separately if possible. Stefan
Re: Patch JavaCC - KEEP_LINE_COLUMN, JJTree - OUTPUT_FILE and new tas kdef JJDoc
On Wed, 2 Apr 2003, Jene Jasper [EMAIL PROTECTED] wrote: Thus I will try to check in a patch for JavaCC 2.1/3.0 changes against the latest snapshot around Monday. CVS HEAD hasn't changed for quite some time, shouldn't be a problem. Stefan
Re: Using files in classpath in task file=
On Wed, 02 Apr 2003, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: The problem is that AFAIK the xslt task needs a file, not an URL, and hence not a jar resource. Errm, where does it need the file? All tasks that resolve files IIUC call public File resolveFile(File file, String filename) in FileUtils.java [1] Most of them implicitly by defining setXYZ(File) setters, yes. Again IIUC and AFAIK it could be quite easy to extend this method to use a url to get the File. Return an URL? Receive an URL? I don't understand what you want. Stefan
Re: Using files in classpath in task file=
On Wed, 02 Apr 2003, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: If I had it in jars I could ship it automatically with the jar that has the task that generated index.xml, so I can easily do something like: xslt in=index.xml out=index.html style=resource:/a/style.xsl/ I see. What I don't see is how we could use an URI here without breaking backwards compatibility. In XSLTProcess we get the style parameter via setStyle(File), this obviously cannot be called with anything else but a file object. If we wanted general URIs, we'd have to change the signature and break custom tasks that inherit from or delegate to instances of XSLTProcess. No way. I'd rather propose to add an alternative attribute styleURI or something to XSLTProcess. Be able to specify a URL for every task that needs a file, and that thus uses the above fileutils method. Again, not without changing the tasks to use something else, not File, in their setter method and thus severely breaking backwards compatibility. Or maybe KISS and just add a getStyleResource(String styleResource). It solves the immediate issue and doesn't open other potential problems. Seems the better way to me - at least until we are prepared to break API compatibility on almost all tasks at once 8-) Stefan
Need JProbe testers
Hi, I've modified the JProbe tasks in a way that they now should autodetect and even work with JProbe 4.x. As I don't run any version of JProbe, I'd like to have people who currently run the JProbe tasks successfully (with older version of JProbe) to either bootstrap the CVS HEAD version of Ant or try the nightly build 2003-04-04 (not the not yet published -04-03, my commit won't be in there) to confirm that I haven't broken any existing functionality. Many thanks Stefan
defaultexcludes in MatchingTask
Can anybody imagine/remember why MatchingTask#setDefaultExcludes does not set the corresponding value on the implicit fileset but defers that to getDirectoryScanner()? Stefan
Re: jdepend error
On Fri, 4 Apr 2003, Conor MacNeill [EMAIL PROTECTED] wrote: The version of jdepend I have hanging around for building Ant is not compatible with the recent changes Any chance to find out which version that is? I'll throw in a little reflection around this (the manual still claims support for JDepend = 1.2 and we don't need to break it if a workaround is possible). Thanks Stefan
Re: jdepend error
On Fri, 4 Apr 2003, Conor MacNeill [EMAIL PROTECTED] wrote: On Fri, 4 Apr 2003 12:38 am, Stefan Bodewig wrote: On Fri, 4 Apr 2003, Conor MacNeill [EMAIL PROTECTED] wrote: The version of jdepend I have hanging around for building Ant is not compatible with the recent changes Any chance to find out which version that is? Not really - just jdepend.jar. OK. JDepend's release history says, setFilter has been introduced in 2.5 - I've updated the manual to that effect. Could you please compile the task and run some simple metrics? Maybe you could also use the nested exclude element and see whether it works as intended (i.e. print a warning and go on creating the report). Thanks Stefan
Re: cvs commit: ant/xdocs/stylesheets templates.vm
On 4 Apr 2003, [EMAIL PROTECTED] wrote: More CSS - less tables No question, it looks - umh - ugly on Netscape 4, don't know how much of a concern that has to be for us, though[1]. It works (the menu comes at the top, the content below) for links and lynx (text-only browsers that are used by tools that read webpage to blind users) which is important IMHO. Stefan Footnotes: [1] http://www.apache.org/~vgritsenko/stats/daily.html#User+Agents+Stats
Re: Fwd: [Xdoclet-user] multiple jsptaglib nested tag in webdoclet
On Thu, 3 Apr 2003, Erik Hatcher [EMAIL PROTECTED] wrote: Any ideas on the differences between using taskdef under project or under a target? Several, and they vary with the Ant version in use. With Ant 1.5.x, the main difference is that taskdefs defined at the project level will get evaluated immediately, so Ant creates the real task objects and real nested elements at parser time. If you put the taskdef into a target, things go the UnknownElement route first. This causes several differences. With CVS HEAD, things have become different, and taskdef is supposed to work consistently now (unchecked 8-) - as all tasks will be UnknowElement until used now. With Ant 1.4, nested child elements didn't work properly in one of the two cases, can't exactly remember which. Stefan
Re: updated sql documentation....
On Thu, 3 Apr 2003, Rob H. Anderson [EMAIL PROTECTED] wrote: Attached is the updated sql documentation that I promised. Didn't make it to the list, sorry. Stefan
Where are we WRT the JDK decision?
When I fixed the JDepend task, I made it depend on JDK 1.2 - which is fine as JDepend has the same dependency. I'll shortly commit the JUnit Report patches and those contain workarounds for the famous StringBuffer#toString memory leak[1] in JDK 1.4.1. Unfortunately the workaround is to use StringBuffer#substring which is not part of JDK 1.1. IIUC we don't have a 1.1 compatibility requirement for CVS HEAD any longer, so that is fine. I'll grep through the sources to see whether I find more cases of StringBuffer#toString used on shared StringBuffers (its my understanding that it doesn't do too much harm if the StringBuffer gets recycled at some point) and will apply the same workaround there. We won't be able to fix the problem in the 1.5 branch, though. Stefan Footnotes: [1] http://developer.java.sun.com/developer/bugParade/bugs/4724129.html
Re: updated sql documentation....
On Fri, 4 Apr 2003, Rob H. Anderson [EMAIL PROTECTED] wrote: How about now? Got it. Stefan
Re: sql triggers, stored procedures, packages, format preserved
On Thu, 3 Apr 2003, Rob H. Anderson [EMAIL PROTECTED] wrote: one line, pretty self explanatory self explaining? Yes. I'm just not sure whether we want to do that unconditionally. Stefan
Re: Patch JavaCC - KEEP_LINE_COLUMN, JJTree - OUTPUT_FILE and new tas kdef JJDoc
On Fri, 4 Apr 2003, Jene Jasper [EMAIL PROTECTED] wrote: Would it be useful if I add an updated patch.txt to bug 18602 for JavaCC.java and JJTree.java after the changes are available in a nightly build ?? Maybe, but I don't think that merging them will be a big deal anyway. Stefan
Re: cvs commit: ant/xdocs/stylesheets templates.vm
BTW, it looks nice in Safari as well, which probably makes up a considerable part of the Unknowns in http://www.apache.org/~vgritsenko/stats/daily.html#User+Agents+Stats Stefan
Re: [RESULT] Ant 1.6 will require JDK 1.2
On Sat, 5 Apr 2003, Conor MacNeill [EMAIL PROTECTED] wrote: It's funny that Stefan, who only voted +0, is the first to make a change that requires JDK 1.2 :-) I couldn't find a workaround, that's all (yes, I've seen that smiley). Having said that, I could have left all toStrings as they were after making sure that the StringBuffers didn't get reused. The real bad things happen in StringBuffer#setLength and only if the StringBuffer is shared, which happens after calling toString. Not calling toString avoids the sharing part, not reusing StringBuffers avoids both, sharing and the calls to setLength. This means that we've now traded a certain amount of memory that cannot get reclaimed by the GC in 1.4.1 for more objects that can get garbage collected. I.e. we could see some negative performance impact. The JDepend change would have required yet another (i.e. a third) layer of indirection via reflection. Let's say I'm lazy. ;-) Have nice weekend Stefan
Re: Using files in classpath in task file=
On Fri, 04 Apr 2003, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: What I mean is not to change the passing of a File object. I mean that we can *wrap* an URL in a File. So we pass a File, and use an URL, getting a Virtual File System. How so - put the URI into the name and abuse File as a String? I'd really like to understand that. We are talking about java.io.File here 8-) Stefan
Re: Using files in classpath in task file=
On Fri, 04 Apr 2003, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: Sure. Look at the JDK 1.4 version, Ahh, far to modern for Ant. Because a URI can be navigated, and it's possible to make a File from a URI. Not always. org.apache.tools.vfs.File extends java.io.File But this version cannot be the argument for the (existing) setters. For this to work, IntrospectionHelper will need to take special care (i.e. if setXYZ(java.io.File) is found, actually pass it an instance of org.apache.tools.vfs.File). This is possible, but ... * Is this generally desirable? mkdir dir=http://www.apache.org// delete fileset dir=jar:http://my.server.com/applets/loader.jar; include name=**/*.gif/ /fileset /delete means what? If I sound harsh, please forgive me. I'm trying to show that in some situations it may be better to stick with files and we need a way to distinguish them. * is not as transparent as you say. Tasks could only use the URI if they first check that the object is is our version of File and cast to it. I.e. the change in IntrospectionHelper will only work for tasks that can handle it. Both points mean that it becomes hard to explain when URIs can get used and when not. Just as people have by now become so used to the relazive path resolution magic that happens inside Ant that they now report it as a bug if a ceratin attribute is not resolved relative to basedir, we will get bug reports that certain tasks do not deal with URLs of protocol foo properly. I find it hard to imagine that we'll be able to convert all tasks that could reasonably be expected to deal with URIs in one go. if I gave you just an url in the constructor, you could write almost, if not all, those methods. That really depends on the protocol you use. delete() for resources loaded from a jar located on a remote server, loaded via some P2P protocol? I may be making up things, I know. Am I really missing the obvious? Could as well be. Same here. Stefan
Re: Using files in classpath in task file=
On Fri, 4 Apr 2003, Jose Alberto Fernandez [EMAIL PROTECTED]
wrote:
I would like for ANT to do this for me, transparently.
property name=fileurl locationURL=${myfile}/
or somethig like that.
Sure, should be trivial using FileUtils#toURI together with
setLocationURL(File), I'm just not sure about the attribute name.
locationURL would imply that its value was an URL and not a location
that gets turned into an URI - at least to me.
Hmm, uriOfLocation=${myfile}? uriForLocation?
Attributes are case-insensitive in Ant.
Stefan
Re: [Patch] trying solve w2k command line length limitations
On Mon, 7 Apr 2003, Ignacio J. Ortega [EMAIL PROTECTED] wrote: Stefan Bodewig [EMAIL PROTECTED] escribió en el mensaje Class.forName will use the system classloader and not the nice little IMHO This contradicts my experience of CLs, i think some places inside tomcat used Class.forName also, and never seen what you say.. Class.forName loads in the current loader Now, where did I get this misconception? Sorry I have disappointed you, DD ;-) I think what you say is true for Java 1.2+, but not for Java 1.1. The API docs of Java 1.1 are not clear about this, but a lot of classloader stuff has changed between 1.1 and 1.2. I'm one of those poor guys who still have to maintain 1.1 compatibility. So for Ant 1.6, this is no issue as long as no core Ant classes calling Class.forName can also be loaded via the parent. Stefan
Re: New external resource found
committed, thanks Stefan
Re: [PMC VOTE] ANt 1.5.3 Release
On Tue, 8 Apr 2003, Conor MacNeill [EMAIL PROTECTED] wrote: I am about to build Ant 1.5.3. Yes, yes, yes. Sigh with relief. 8-) +1 Stefan
Re: Making URIs from locations
On Tue, 8 Apr 2003, Dominique Devienne [EMAIL PROTECTED] wrote: Note the change to resource (from resources) to be consistent with taskdef / available. resources has been a typo, thanks. I assume the url attribute's signature would be setUrl(URL url). Yes. Stefan
Re: 1.5.3 Release
On Wed, 9 Apr 2003, Conor MacNeill [EMAIL PROTECTED] wrote: The 1.5.3 release is up on the site. I haven't had time to send the announcements out yet. Which may be good so that the mirrors have time to catch up. Freshmeat announcement is pending approval, next I'll do will be Usenet and the Jakarta Site (under elsewhere 8-). I'll let you do the various announce@ mailing lists. Stefan
Re: having datatypes load classes
On Tue, 08 Apr 2003, Marc Portier [EMAIL PROTECTED] wrote: but since that pattern is to be seen more around ant iteself, I was hoping for some reuse here One would think so, but the truth is that you'll find copy-paste reuse in this area instead of delegation or something. Patches for a nice little utility class are welcome 8-) Stefan
Re: [PATCH] add regular expressions to ContainsSelector.java
On Thu, 10 Apr 2003, Jay [EMAIL PROTECTED] wrote: I was thinking that the filters were more geared to changing text, not just identifiying a file has a specific content. You are absolutely correct. What I tried to say in my clumsy way: We have to tasks that perform replacements, replace and replaceregexp. We have two filter readers that select lines based on matching, linecontains and linecontainsregexp. Following that it would be consistent to have to selectors based on matching, contains and containsregexp. So would it be ok to make ContainsRegexpSelector under /ant/types/selectors that is basically the same as ContainsSelector but just accepts a single parm and does the regular expression search only? Exactly. Thanks for your time on this. Thank you Stefan
Re: having datatypes load classes
On Thu, 10 Apr 2003, Marc Portier [EMAIL PROTECTED] wrote: seems to me however the current LoaderUtil more has somewhat of a jdk-version match-up function? It used to be used for that, yes. But this part of its functionality is no longer needed in Ant 1.6 as we've dropped JDK 1.1 compatibility. CVS HEAD is going to drop Java 1.1 compatibility, so some changes in the whole classloader area are to be expected. could you elaborate, and maybe be explicit on how this can affect my doing ATM? If only I knew 8-) One thing that looks as if it was changing is that Ant's classes themselves will be loaded by a classloader that is not the system classloader. I don't think it is going to affect your doing, but I'm not 100% sure. The other thing is that you may be able to simplify things when you know you don't have to care about 1.1 compatibilty. Stefan
Re: [Patch] es to be submitted
On Fri, 11 Apr 2003, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: There are several bug reports where I have prepared code, and documentation and testcases , and I would like them to be submitted before the code patches are obsolete : There are certain constants in life, one is there will always be a huge patch backlog in Ant 8-) http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17007 allow to define ZipFileSet(s) outside of Zip task this is an easy one, And at the same time something that I wouldn't want to apply. It interferes with several proposals to introduce some kind of polymorphism in Ant. I'm sure that you are not aware of them, but there've been plans and even complete code for such things. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15434 MimeMailer doesn't work properly with national charset I looked into it, but I'm not really familiar with JavaMail. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18431 new p4labelsync task this one has been requested by one user; and even less with Perforce. When things like this happen, I usually hope that a patch is confirmed (i.e. works for me) by at least one other (Perforce in this case) user. since it is a new task, it should not harm any one. Sorry, this is somewhat short sighted, every new task that no committer can maintain does harm to Ant in some way or the other. Stefan
Re: [Patch] es to be submitted
On Fri, 11 Apr 2003, Jan Materne [EMAIL PROTECTED] wrote: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18849 Adds a new skip attribute to HeadFilter and TailFilter. We (or at least I) have some informal segmentation in Ant's code base. Bruce is the selector guy, Magesh is the filter guy and so on. Unless Magesh finds time for this, I'll assign it to myself sometime later this months. Note that your patch - just like Antoine's - are not really targeting a piece of code that was changing every day, so it is unlikely a patch would go bad within the next weeks. The patch command itself does a reasonably good job to merge things, even if there were changes. Stefan
[VOTE] Antoine Levy-Lambert as committer
Hi all, Antoine has continuously been sending in patches since months now, he's played an important role in the zip refactoring and is answering more question on the user list than most of us here. Furthermore Antoine has access to a perforce installation, so he's able to test and fix those tasks. 8-) Finally he's expressed interest in reviving the antlib proposal. I feel it is time to make him a committer and ask you to vote on this. Let me start with my +1 Stefan
Re: cvs commit: ant/xdocs contributors.xml
On 14 Apr 2003, [EMAIL PROTECTED] wrote: Add myself to the list as a test of write access welcome! Further commit mails should go through without delay (this one was waiting in the moderation queue). Stefan
Re: FileUtils.createTempFile() - should we delete on exit?
On Mon, 14 Apr 2003, Jesse Stockall [EMAIL PROTECTED] wrote: Should the fix be applied to each task that creates temp files, or should it be put in FileUtils.createTempFile(). The later (and I agree with Conor on the optional additional argument). Stefan
Test failures (Gump is coming to tell us anyway ...)
Like for Jesse, testTailSkip and testTailLinesSkip fail on Linux for me, I bet it is a line ending problem. As the nightly Gump build is performed on Linux as well, we are going to get nagged. 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
Re: cvs commit: ant/xdocs contributors.xml
On 15 Apr 2003, [EMAIL PROTECTED] wrote: Add myself to contributors list Welcome! again, future commit mails should go by without further delay. Stefan
Re: cvs commit: ant/src/etc/testcases/taskdefs/optional/vss vss.xml
On Tue, 15 Apr 2003, Jesse Stockall [EMAIL PROTECTED] wrote: It's fixed now. Yep, compiles again, thanks. Stefan
Re: junit.jar in Ant 1.5.3 distro?!?!?
On Tue, 15 Apr 2003, Dominique Devienne [EMAIL PROTECTED] wrote: Why is Ant 1.5.3 shipping with junit.jar in ANT_HOME/lib??? It is? Which download? Without shipping the license of JUnit and all that, we can't do it. Stefan
Re: junit.jar in Ant 1.5.3 distro?!?!?
On Wed, 16 Apr 2003, Conor MacNeill [EMAIL PROTECTED] wrote: I'll rebuild the distribution tonight. One thing that you'll need to consider is that people may download the old distribution from a mirror and try to check it with the signature for the new distribution from www.apache.org. You will probably have to chose different names for the archives. Stefan
Re: [GUMP] Test Failure - Ant
On 16 Apr 2003, Diane Holt [EMAIL PROTECTED] wrote: [junit] Testcase: testCheckoutCommandLine(org.apache.tools.ant.taskdefs.optional.vss.MSVSSTest): FAILED [junit] extra args [junit] junit.framework.AssertionFailedError: extra args [junit] at junit.framework.Assert.fail(Assert.java:47) [junit] at org.apache.tools.ant.taskdefs.optional.vss.MSVSSTest.checkCommandLines(MSVSSTest.java:455) [junit] at org.apache.tools.ant.taskdefs.optional.vss.MSVSSTest.testCheckoutCommandLine(MSVSSTest.java:323) happens on my machine (Linux, in case this is important) as well. Stefan
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
On Tue, 22 Apr 2003, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: From: Stefan Bodewig [EMAIL PROTECTED] Which documentation? I meant the ant manual page under docs/manual/CoreTasks/war.html Nested elements lib The nested lib element specifies a FileSet. Well, yes. This doesn't rule out zipfileset, I'd call it an implementation detail that the user shouldn't have to be aware of. Which also measn that using a reference to a plain fileset must work. What about changing the method signature of War#addLib from addLib(ZipFileSet fs) to addLib(FileSet fs) ? Would break this here war ... lib src=foo.zip/ /war which should work right now (and in Ant 1.3+). Yes this is new, it was possible to do fileset ... id=xyz/ war lib refid=xyz/ /war before I did my changes. Yes, I've seen Gianugo's post as well 8-) Stefan
Re: cvs commit: ant/src/main/org/apache/tools/ant/types ZipFileSet.java
On 22 Apr 2003, [EMAIL PROTECTED] wrote:
+if (o instanceof FileSet) {
+ return (AbstractFileSet)(new ZipFileSet((FileSet)o));
the cast is not needed here.
+}
+else if (!(o instanceof ZipFileSet)) {
will always be true as instanceof ZipFileSet implies instanceof
FileSet.
Maybe you really wanted something like
if (o instanceof FileSet) {
return (AbstractFileSet) o;
} else if (o instanceof FileSet) {
return (new ZipFileSet((FileSet) o));
} else {
String msg = getRefid().getRefId() + doesn\'t denote a zipfileset
or a fileset;
throw new BuildException(msg);
}
Stefan
ZipFileSet test failures in CVS HEAD
[junit] Testcase: testAttributes(org.apache.tools.ant.types.ZipFileSetTest):Caused an ERROR [junit] null [junit] java.lang.NullPointerException [junit] at org.apache.tools.ant.types.ZipFileSetTest.testAttributes(ZipFileSetTest.java:149) [junit] at java.lang.reflect.Method.invoke(Native Method) [junit] at junit.framework.TestCase.runTest(TestCase.java:154) [junit] at junit.framework.TestCase.runBare(TestCase.java:127) [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at junit.framework.TestResult.run(TestResult.java:109) [junit] at junit.framework.TestCase.run(TestCase.java:118) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:208) [junit] at junit.framework.TestSuite.run(TestSuite.java:203) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:318) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnitTask.java:872) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:562) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:538) [junit] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:231) [junit] at org.apache.tools.ant.Task.perform(Task.java:399) [junit] at org.apache.tools.ant.Target.execute(Target.java:309) [junit] at org.apache.tools.ant.Target.performTasks(Target.java:336) [junit] at org.apache.tools.ant.Project.executeTarget(Project.java:1404)[junit] at org.apache.tools.ant.Project.executeTargets(Project.java:1278) [junit] at org.apache.tools.ant.Main.runBuild(Main.java:611) [junit] at org.apache.tools.ant.Main.start(Main.java:198) [junit] at org.apache.tools.ant.Main.main(Main.java:245) [junit] Testcase: testCircularReferenceCheck(org.apache.tools.ant.types.ZipFileSetTest):FAILED [junit] Dir is basedir expected:null but was:/home/bodewig/ASF/jakarta/jakarta-ant [junit] junit.framework.AssertionFailedError: Dir is basedir expected:null but was:/home/bodewig/ASF/jakarta/jakarta-ant [junit] at junit.framework.Assert.fail(Assert.java:47) [junit] at junit.framework.Assert.failNotEquals(Assert.java:282) [junit] at junit.framework.Assert.assertEquals(Assert.java:64) [junit] at org.apache.tools.ant.types.AbstractFileSetTest.testCircularReferenceCheck(AbstractFileSetTest.java:281) [junit] at java.lang.reflect.Method.invoke(Native Method) [junit] at junit.framework.TestCase.runTest(TestCase.java:154) [junit] at junit.framework.TestCase.runBare(TestCase.java:127) [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at junit.framework.TestResult.run(TestResult.java:109) [junit] at junit.framework.TestCase.run(TestCase.java:118) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:208) [junit] at junit.framework.TestSuite.run(TestSuite.java:203) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:318) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnitTask.java:872) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:562) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:538) [junit] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:231) [junit] at org.apache.tools.ant.Task.perform(Task.java:399) [junit] at org.apache.tools.ant.Target.execute(Target.java:309) [junit] at org.apache.tools.ant.Target.performTasks(Target.java:336) [junit] at org.apache.tools.ant.Project.executeTarget(Project.java:1404)[junit] at org.apache.tools.ant.Project.executeTargets(Project.java:1278) [junit] at org.apache.tools.ant.Main.runBuild(Main.java:611) [junit] at org.apache.tools.ant.Main.start(Main.java:198) [junit] at org.apache.tools.ant.Main.main(Main.java:245)
Re: [PATCH] add test case for containsregexp
I'm taking care of it. Stefan
Re: antlib
On Tue, 22 Apr 2003, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: If we do this, then we can concentrate here on the local antlib while someone else can take care of the external work. +1 Stefan
Re: antlib
On Mon, 21 Apr 2003, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: 1) antlib antjar deployment descriptor called antlib.xml which would go in the META-INF subdirectory of the antlib I prefer an XML descriptor over manifest entries as well, because it is easier to extend in the future. Say centipede wants to add information in that descriptor that antlib doesn't need to care about. looks like that antlib version=1.5 Is that the version of the antlib parser, i.e. does version define the format of the file? The minimal version of Ant the antlib needs? Or is that the version of the antlib itself? I think we'll have to provide all three items, while the first two may in fact be just one. 2) type definitions -- allowing to define new implementations of mappers, selectors, paths, conditions, We definitely need this, roles may be the key here. With that, do we really need separate task and data-type in antlib or are they just special cases of roles? 3) A scoping framework for the symbol tables needed to manage the antlib definitions Management of a hash symbol table containing names, classes, and roles. Roles are currently task or datatype. It is possible to define new roles. Works for me. 4) A framework for managing classloaders where you can specify which classloader to use when loading an antlib. This is the hardest part IMHO. Sorry, I haven't looked at the proposal thoroughly so far. Is there such a classloading framework in place? What does it provide and how do you use it? Stefan
Re: antlib
On Wed, 23 Apr 2003, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: I am not even sure the code today was examining the value. 8-) It's been a long time, I know. we probably should define more meaningful attributes ant-required-version, antlib-version (version used to buils the library) that would probably mate things more clear. Fine with me. With that, do we really need separate task and data-type in antlib or are they just special cases of roles? They should be. So if they are just roles, why treat them in a different way than other roles? Why a task element? define classname=... name=... role=task/ could do the same and be more consistent. I don't have a strong feeling here, just trying to find my way through the ideas without having to read the code ;-) Maybe something could even be in different roles at the same time? See available, checksum or uptodate for things that are tasks and conditions in one. Let me first say that this feature appeared by the need to be able to say, antlib name=A classpathref=XYZ/ antlib name=B classpathref=XYZ/ And being able to make sure that B and A use the same classLoader and therefore they can use each other components. I understand that usecase and think it's important. See Steve Loughran's comment on the .NET tasks wanting to have access to the datatypes defined in the cpptasks project for example. My solution at the time was this idea of a named classloader that you could define using a classpath, and then tell your antlibs use this or that classloader, if you use the same classloader visibility is guaranteed. Take a look at what Costin had done to taskdef and typedef with the loaderref attribute. This has now (i.e. CVS HEAD) been generalized in ClasspathUtils, the infrastructure for named classloaders is there - at least the foundation for it. Stefan
Re: Cleanup for ClasspathUtils
On Fri, 18 Apr 2003, Marc Portier [EMAIL PROTECTED] wrote:
1. ClasspathUtils duplicates (i.e. stole) some code from the
o.a.t.a.taskdefs.Definer: the least I should do is refactor that one
to now use what is in the ClasspathUtils.
This is now in CVS.
I noted at least one difference, and I'm not sure whether it is going
to have any effect right now, but we may need to address this: If no
classpath had been defined, Definer would first check the project's
core loader and use that if set. ClasspathUtils ignores this.
While this is not that much of code I still would like to add to
this some Helper that does all of this for you,
It's also in.
BTW
public void setClasspathRef(Reference r) {
this.cpHelper.setClasspathRef(r);
}
I wouldn't implement this and setClasspath(Path) at all if I were to
write a new task today. I'd simply stick with the nested element.
(what about these ./proposal things?)
Ignore them for now.
I take it the prefered patch format is cvs -q diff -u -N ?
Yep. The -q is your choice, off course.
tests are currently not working in cvs head
I think some of the failures you've seen are due to the copy
changes the line-end style bug that is supposed to be fixed now. If
things keep failing, nag this list. ant test is supposed to pass.
Stefan
Re: antlib
On Wed, 23 Apr 2003, Dominique Devienne [EMAIL PROTECTED] wrote: If everything is defined as a component at a low level, then they can be easily introspected to find out what interfaces components implement. This breaks down if there is no specific interface for a role - like task or data-type. And also doesn't address things that can be in multiple roles. At least for task I'd expect some strong opposition against an interface that marks them up. Hi Costin ;-) Stefan
Re: antlib
On Wed, 23 Apr 2003, Dominique Devienne [EMAIL PROTECTED] wrote: Forcing roles to map to an interface is probably a *good* idea! Maybe, hmm, probably, not convinced ... Every single bean would become implicitly a data-type, and the ones with an execute() method implicitly become tasks. Beyond that, all other roles are interfaces. How would you have a task that also is a condition? It implements Condition and has an execute method? How would you have a datatype that also is a condition? This may be far-fetched, not sure. Stefan
Re: antlib
On Thu, 24 Apr 2003, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: Two years ago (or was it three?) One. this proposal got nowhere because it got picked appart to death. I've seen the danger myself, this is why I've delayed my responses today. In the end we are not that far apart at all. Let's get the things together then. * antlib needs a way to define mappings between names and classes. Costin prefers a properties file. Most others prefer XML. My argument for XML is the extensibility. We will need versioning, we will need some statement of pre-reqs (like this antlib requires log4j), we will need additional capabilities we do not see now. We certainly could put this into MANIFEST.MF, but it would be hard to put all of this into a properties file. I like to keep the information in a single place, so properties plus manifest is no good idea IMHO. * if we are having problems with roles right now, lets start small. Let's make a version of antlib that knows about two predefined roles, task and data-type. I think this is already feature complete in the proposal (which does even more). Let's move this code with the restriction to tasks and types into the main branch ASAP. Let's sort out the classloading requirements as well as the interplay of antlib with taskdef and typedef here. After this flies, I'd expect us to get roles sorted out. If we feel like removing the difference between tasks and types, we can do so then as well. Stefan
Re: antlib
On Thu, 24 Apr 2003, Dominique Devienne [EMAIL PROTECTED] wrote: I'm not fond of this pre-req thing you're describing, I didn't make myself clear, that's obvious. In good old Ant terms: available classname=org.apache.log4j.Category property=Log4j.present/ failThe antlib requires log4j version XYZ to run/fail Maps to the idea of reusing Ant's existing vocabulary. I want to enable the antlib to state what it needs, I didn't think of a way to satisfy the pre-reqs (at least not yet). I think classloading issues would be greatly simplified if Ant loaded only its core in the system CL, and everything else in child AntLoaders. It would simplify a lot but break backwards compatibility - the impact depends on how broad you define what belongs to the core 8-) Is the Java task part of the core? There are several optional tasks that create Java task internally in Ant itself, much more to be expected outside of Ant. Sequential? ExecTask? Mkdir? Soon you'll end up having almost everything back on the system classloader (or at least on a classloader common to all tasks). We should enable such a mechanism, but we need to keep the door open for the old mechanism. We may even be forced to make the old classloading scheme the default for everything that could be loaded from the system classloader in Ant 1.5.3. Stefan
Re: antlib
On Thu, 24 Apr 2003, Costin Manolache [EMAIL PROTECTED] wrote: Look - adding roles concept to ant, and adding antlib are 2 separate issues. I tend to agree - that's why I proposed to get antlib into the main trunk with support for types and tasks only. At least for starters. If you want a custom mapper you can do so right now with a data type and refid. The same is not true for filter readers, conditions or selectors. But I feel that enabling that would inevitably lead us to the more general polymorphism discussion and this is what I wanted to avoid 8-). Stefan
Re: antlib
On Thu, 24 Apr 2003, Dominique Devienne [EMAIL PROTECTED] wrote: So how do *you* propose we plug in custom implementations of all the things mentioned above, if not with roles? That other thing we discuss and discuss over and over again without getting anywhere 8-) Polymorphism. Stefan
Re: antlib
On Fri, 25 Apr 2003, peter reilly [EMAIL PROTECTED] wrote: I have implemented a generalization of FilterChain's usage of DynamicConfigurator in IntrospectionHelper. This extends the introspection support to include methods of the form: Yes, that's one way to implement it. The tricky part starts if you want to support polymorphism for more than one nested element. Say class PathThatIgnoresBuildSysclassPathToTrickGump extends Path and you want to use it in javac which has several nested elements that are Paths. My, will I ever by able to keep focused on one thread at a time 8-) 2) As a consequence of 1), the same identifier by be used to point to different classes. I see manifest as data type - the one you'd use for refid usage - is implemented by a different class than the manifest task. Luckily we never declared a data-type named manifest. 3) they provide an optional adaptor to allow classes that do not support a requred interface. This may be out of scope for antlib and in scope for the polymorphism debate. My feeling is that roles are not needed to support dynamic conditions, filters ..., in fact I do not think that typedef is needed: I agree. At least no formal definition of a role. Stefan
