Re: Unit tests results with current head
Antoine Levy-Lambert wrote: We should also move the starteam tasks to an antlib or or find another project wanting to have them so that we sometime reach the situation where an automated process (gump ?) could build a release candidate of ant legally on an ASF computer. Regards, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Heh. Starteam. Those were my first contributions to Ant. It's been about 3 years since I last used StarTeam. Did anyone ever come along to take that over? I'm guessing not. I don't know what's involved in making something into an Antlib, but I might have some time to devote to that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: echo task documentation error
Dominique Devienne wrote:
empty. If foo is empty by mistake, how will one troubleshoot this?
and not a blank line. Undefined properties are echoed as literal
text, not skipped.
I'm well aware of that ;-) That's why I wrote empty, not not
defined. As in empty string vs null string.
The proper way to output a line separator is by using
echo${line.separator}/echo. That this doesn't work in Maven is a
bug for Maven, not a feature of Ant.
AFAIK, *any* task output is prefixed by the task's name. A line
separator is output in my book ;-) I fail to see why it would be good
to make an exception for echo/ somehow.
Go ahead and fix the doc bug if you want. Strictly speaking this is
in keeping with BC; but this is yet another one of these little quirks
Ant is full of. --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I stand corrected, thanks.
I checked in the manual change.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: echo task documentation error
Dominique Devienne wrote:
unless someone comes up with a good reason
why this is a bug rather than a feature.
It's a bug if it doesn't prefix that line with [echo] in non-emacs mode.
echo/ is not much different from echo${foo}/echo with foo being
empty. If foo is empty by mistake, how will one troubleshoot this?
Sure, not a very good example, but still. Any task output should be
prefixed with the task name in non-emacs mode. --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This is the sort of input I wanted before I went off blindly changing
documentation to match current behavior.
But your example isn't quite correct either.
echo${foo}/echo (with foo not defined)
will produce
[echo] ${foo}
and not a blank line. Undefined properties are echoed as literal text, not
skipped.
So, although the omission of the task tag may be unintended, I don't see it as
quite as bad a thing as you do. It is handy to be able to emit a totally blank
line. Although, to be perfectly consistent, we should probably define something
like echo blank=true/ or some such to get that behavior rather than this
accidental thing.
My feeling for now is to simply update the doc to say (on echo.html, for the
required column of the message attribute):
No. Text may also be included in a character section within this element. If
neither is included a blank line will be emitted in the output.
leaving the question of the missing task label to be disposed of separately.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: echo task documentation error
Antoine Levy-Lambert wrote: Hi Steve, I think you are a committer too. Feel free to edit the documentation. Regards, Antoine Steve Cohen wrote: A very minor point: The ant manual states that the echo task's message attribute is required unless data is included in a character section within this element. This appears to be false. I have by accident discovered that echo/ has the effect of inserting a totally blank line into the output. It doesn't even show the normal [echo] prefix. I don't know if this is intentional, but it is actually quite useful. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] You're right. I have been quite inactive, but I can certainly do this. That is, unless someone comes up with a good reason why this is a bug rather than a feature. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: [VOTE] migrate to svn
+1 Matt Benson wrote: Sorry I kept forgetting... Here's my +1. -Matt --- [EMAIL PROTECTED] wrote: I´m just getting the results of the vote. But I´m not sure which action from the bylaws to use. An Adoption of New Codebase needs 2/3 majority of committers which we havent (~ 1/3). Many committers havent voted, but we have consensus. How to proceed? Jan +1 - Bruce Atherton pmc Stephane Bailliez pmc Steve Loughran pmc Conor MacNeill pmc Jan Materne pmc Alexey Solofnenko committer Kev Jackson user +0 - Martijn Kruithofcommitter PMC: 13 members - +1: 5 +0: 0 -1: 0 no vote: 8 Committer: 13+6=19 - +1: 6 +0: 1 -1: 0 no vote: 12 -Ursprüngliche Nachricht- Von: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 3. August 2005 09:17 An: Ant Developers List Betreff: Re: [VOTE] migrate to svn +1 Antoine --- Ursprüngliche Nachricht --- Von: [EMAIL PROTECTED] An: dev@ant.apache.org Betreff: [VOTE] migrate to svn Datum: Tue, 2 Aug 2005 14:40:46 +0200 Ok, I got some +1, but sooner is not a timeframe you could really vote on - IMO :-) So I suggest: Migrate Ant from CVS to SVN on the weekend of 13./14. August 2005. That would be the first weekend after the one-week voting timeframe. After passing the vote we should add a note on the homepage. Let me start with +1 Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FTP Connection as Referenced Object
Having spent a week thinking over the issues raised in this discussion: http://issues.apache.org/bugzilla/show_bug.cgi?id=31744 I have come to the conclusion that the best place to start would be creating a connection as a referenceable object. I'm trying to find a model to look at so that I can better understand the internal workings of this structure. Looking over the classes in the o.a.t.a.types package tree I don't see any of them that stands out as being in any way a close analog of the FTP connection in terms of functionality or lifecycle. Does anybody have a suggestion for me here? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ant Logging isVerbose()?
In log4j, commons-logging, etc. a common pattern is
if (isDebugEnabled()) {
// some expensive string building to put message together
log.debug(expensiveMessage);
}
The point is that without the isXXXEnabled(), the expensive string
building must occur even if the most verbose logger activated is not
verbose enough to cause the log message to be written.
I don't see such functionality in Ant and yet it seems to me like an
obviously useful extension. Has there been discussion before about this
and a conscious decision not to do it?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant Logging isVerbose()?
Stefan Bodewig wrote:
On Mon, 30 May 2005, Steve Cohen [EMAIL PROTECTED] wrote:
In log4j, commons-logging, etc. a common pattern is
if (isDebugEnabled()) {
// some expensive string building to put message together
log.debug(expensiveMessage);
}
I don't see such functionality in Ant
Because Ant doesn't have a way to determine isDebugEnabled().
XmlLogger, for example, logs everything and ignores the command line
switches. So the only thing which would know it is the listeners
themselves.
Since the listener API doesn't expose the verbosity - and changing the
interface is no good idea either - I don't see how we could do it.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Yeah, that's what I thought. I found the BuildLogger interface with
setters and no getters and couldn't see a way around that, without
changing the interface, which of course, has problems of its own.
Oh well.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/docs/manual/OptionalTasks ftp.html
Steve Loughran wrote: [EMAIL PROTECTED] wrote: scohen 2005/05/29 17:40:21 Modified:src/testcases/org/apache/tools/ant/taskdefs/optional/net FTPTest.java src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java src/etc/testcases/taskdefs/optional/net ftp.xml docs/manual/OptionalTasks ftp.html Added: src/main/org/apache/tools/ant/util Retryable.java RetryHandler.java Log: Based on a patch submitted by Neeme Praks, allow support for a retry count on FTP transfers. Some servers are unreliable for unknown - this allows for a retry count to be specified to accomodate work on such flaky servers. nice. Are you doing any kind of back-off algorithm to deal with load problems? If so, add a bit of jitter to increase the randomness. (I remember an embedded system without back-off but not jitter failing to deal with the situation of an entire building with 120+ nodes having its power toggled...) -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I'm not entirely sure what you mean. By jitter, are you referring to varying the time delay? I asked Neeme Praks why he didn't put in a time delay and he said he didn't need one. In his use case, he simply sets it up to run forever, and that works for him. Eventually it succeeds. But I wonder about this. Sounds like it could be a tight loop that eats all processing under the wrong conditions. And I'm not sure at all what you mean by a back-off algorithm. So please elaborate. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to write a JUnit test for this new functionality?
Neeme Praks has sent me an interesting patch that allows the ftp task
to execute with a certain number of retries specified. That is, it
won't fail until the specified number of retries has passed.
I want to write some JUnit tests to test this patch. My idea was to
simulate failure by subclassing the FTP task class
(o.a.t.a.taskdefs.optional.net.FTP) within the JUnit test with a version
that allows setting a numberOfFailuresToSimulate member, and a modified
transferFiles() method that would, if numberOfFailuresToSimulate 0,
simply decrement this value by 1 and throw a dummy BuildException,
otherwise, simply execute the regular transferFiles. This seems like a
good way to test Neeme's retry handler. Then this can be tested with a
build file that specifies the number of retry times, and the test can
then illustrate what happens with this buildfile when numbers , , or
== to the specified number of simulated failures occur.
To wit:
private static class myRetryableFTP extends FTP {
private int numberOfFailuresToSimulate;
int getNumberOfFailuresToSimulate() {
return numberOfFailuresToSimulate;
}
void setNumberOfFailuresToSimulate(int numberOfFailuresToSimulate) {
this.numberOfFailuresToSimulate = numberOfFailuresToSimulate;
}
protected int transferFiles(FTPClient ftp, FileSet fs)
throws IOException, BuildException
{
if (this.numberOfFailuresToSimulate 0) {
this.numberOfFailuresToSimulate--;
throw new BuildException(Simulated failure for testing);
}
return super.transferFiles(ftp, fs);
}
}
However, my knowledge of Ant internals is somewhat limited. How can I
tell an ant project in my test code that when it sees an ftp tag, it
should delegate the performance of this task to myRetryableFTP, instead
of to the standard FTP as it would normally do? Is there an example of
this sort of thing within the existing Ant test suite?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to write a JUnit test for this new functionality?
Stephane Bailliez wrote: Steve Cohen wrote: However, my knowledge of Ant internals is somewhat limited. How can I tell an ant project in my test code that when it sees an ftp tag, it should delegate the performance of this task to myRetryableFTP, instead of to the standard FTP as it would normally do? Is there an example of this sort of thing within the existing Ant test suite? . project.addTaskDefinition(ftp, MyRetryableFtp.class) ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks. I found something else that works, using ComponentHelper, but this seems simpler. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: installation instructions for ant under jpackage
Peter Reilly wrote: Steve Loughran wrote: Steve Cohen wrote: There have been some comments on the jpackage.org mailing list to the effect that our manual doesn't really have correct installation instructions for that environment, although elsewhere on our site we do link to them. I have rewritten the install manual page to add this content, but rather than commit it and then draw comments, I decided to post it on my own site temporarily for comment. If there is none, I'll just commit it. I had a quick read of the section - looks good. Perhaps you could mention ) that if ant has been installed by jpackage (at least the current versions), the env variable ANT_HOME will be ignored, ) and that one can use the --noconfig switch to ignore the jpackage installation. Peter It's nice. I'm thinking of adding fetch.xml to the end user distro, as it can then pick up many of the optional extra jar files (the OSS ones). It needs tweaking to autoretrieve the maven task to do the downloads, which leads to a problem: the version of that task when ant1.7 ships will be less than the latest version by the end of the lifetime of the tool. Either we do hard code a version# into a shipped property file, or we provide some way of getting the latest version (property url off the ant site to get the list of latest JARS for that version, perhaps) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Good point! Changes made to http://www.javactivity.org/jpackage/install.html#jpackage As for future enhancements, we can update as they come in, I think. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: installation instructions for ant under jpackage
Peter Reilly wrote: Steve Loughran wrote: Steve Cohen wrote: There have been some comments on the jpackage.org mailing list to the effect that our manual doesn't really have correct installation instructions for that environment, although elsewhere on our site we do link to them. I have rewritten the install manual page to add this content, but rather than commit it and then draw comments, I decided to post it on my own site temporarily for comment. If there is none, I'll just commit it. I had a quick read of the section - looks good. Perhaps you could mention ) that if ant has been installed by jpackage (at least the current versions), the env variable ANT_HOME will be ignored, ) and that one can use the --noconfig switch to ignore the jpackage installation. Peter It's nice. I'm thinking of adding fetch.xml to the end user distro, as it can then pick up many of the optional extra jar files (the OSS ones). It needs tweaking to autoretrieve the maven task to do the downloads, which leads to a problem: the version of that task when ant1.7 ships will be less than the latest version by the end of the lifetime of the tool. Either we do hard code a version# into a shipped property file, or we provide some way of getting the latest version (property url off the ant site to get the list of latest JARS for that version, perhaps) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Peter, what is fetch.xml? Sounds interesting. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: installation instructions for ant under jpackage
Steve Loughran wrote: Steve Cohen wrote: what is fetch.xml? Sounds interesting. I thought you knew; you updated lib/libraries.properties like you did, that being the property file that drives it. Actually, I grepped through the source for jakarta-commons and found libraries.properties that way. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
installation instructions for ant under jpackage
There have been some comments on the jpackage.org mailing list to the effect that our manual doesn't really have correct installation instructions for that environment, although elsewhere on our site we do link to them. I have rewritten the install manual page to add this content, but rather than commit it and then draw comments, I decided to post it on my own site temporarily for comment. If there is none, I'll just commit it. http://www.javactivity.org/jpackage/install.html#jpackage is the main link. There's also an internal link a few lines above. Otherwise, I kept the content the same. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/src/etc/testcases/taskdefs/optional/net ftp.xml
Antoine Levy-Lambert wrote: Hello Steve, what about using a class derived from EnumeratedAttribute as type for timestampGranularity ? Cheers, Antoine [EMAIL PROTECTED] wrote: scohen 2005/05/22 11:48:42 Modified:src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java src/etc/testcases/taskdefs/optional/net ftp.xml Log: Add new timestampGranularity attribute to account for the typical case in PUT operations where the client is HH:mm:ss and the ftp server is HH:mm. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I'll take a look. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/src/etc/testcases/taskdefs/optional/net ftp.xml
Antoine: OK, I've taken a look. Here is the problem, or maybe I don't understand EnumeratedAttribute fully. In response to a suggestion of Steve Loughran the other day, I've implemented all of my new attributes with the convention that a value of means Don't set the attribute - leave the default value in place. This was to accomodate Steve's suggestion of wanting property-file driven scripts. Such a script would define property name=timestampGranularity value=/ An optional property file could define timestampGranularity=MINUTE or timestampGranularity=NONE. If neither specified, the default to be used (whose value varies depending on the chosen action). I'm having difficulty understanding how this convention would fit into the pattern of EnumeratedAttribute. There may be such a way that I'm just not understanding. I'm still open to whatever suggestions you might have on this score or alternative ideas to improve this code. Steve Cohen wrote: Antoine Levy-Lambert wrote: Hello Steve, what about using a class derived from EnumeratedAttribute as type for timestampGranularity ? Cheers, Antoine ... I'll take a look. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can Ant know ANT_HOME?
Stefan Bodewig wrote: On Mon, 23 May 2005, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: we should add a line about in in the table explainning the different system properties used by Ant. Keep in mind that it is our wrapper script that sets the property. If you launch ant any other way (IDE, script of your own, embedded), there is no guarantee that it will be defined. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] But that's precisely my use case. In an environment where there is more than one way to launch ant, I sometimes get unexpected results. In my case I've got a JPackage install, plus various trees of various versions of ant in various stages of development. When something hasn't worked they way I want, I need to go see what ANT_HOME was defined as at the moment Ant launched. I don't want to do anything with it, I just want to see how it was defined, without reading a lot of shell scripts trying to understand which path got me where I am. In fact, knowing what ANT_HOME was eventually chosen makes it easier to follow the shell scripts. If ANT_HOME is not defined, that also is worth knowing. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Ant 1.6.5 release
Antoine Levy-Lambert wrote: Hello, I propose to release Ant 1.6.5 on Thursday, June 2nd. This will be a pure bug fix release. [] Yes [] No Let's begin with my +1 Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Shut down the 1.6 branch after 1.6.5
Stefan Bodewig wrote: Hi, it's my strong belief that part of the reason the javah and move bugs made it into 1.6.3 is that our branches are living too long. The same happened to 1.5.2 (which required 1.5.3 quickly) because the 1.5 branch lived to long (IMHO). In my day-to-day Ant usage I use CVS HEAD, all the time, exclusively. Sometimes I merge changes into the 1.6 branch without merging the unit tests as well. Sometimes I don't merge changes at all. Sometimes I forget to pull a change from the branch when it has been pulled from HEAD ... I bet, other committers have similar experiences. It's not enough to say users don't beta-test our releases, in all honesty, after X.Y.1 or maybe X.Y.2 we don't even alpha-test them sufficiently ourselves. This leads me to the subject of this vote. Let's get rid of the branch, stabelize CVS HEAD and release 1.7.0-beta in a reasonable time-frame. Cheers Stefan PS: I also intend to start a vote that branches shouldn't live as long as the 1.5 and 1.6 branches did but we do new releases from HEAD more quickly. This will wait until this vote has been decided. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Can Ant know ANT_HOME?
I am trying to write a simple build.xml for debugging Ant setups. One
of the things I would like to know is what ANT_HOME was defined as when
Ant launched. But this does not seem to be a predefined ant property.
I naively thought that I could do
property environment=env/
echoANT_HOME=${env.ANT_HOME}/echo
this will not work unless ANT_HOME is predefined in the environment.
The typical ant launch scripts will define ANT_HOME but not export it
into the environment.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can Ant know ANT_HOME?
Alexey Solofnenko wrote:
Please use ${ant.home} property.
- Alexey.
On 5/22/05, Steve Cohen [EMAIL PROTECTED] wrote:
I am trying to write a simple build.xml for debugging Ant setups. One
of the things I would like to know is what ANT_HOME was defined as when
Ant launched. But this does not seem to be a predefined ant property.
I naively thought that I could do
property environment=env/
echoANT_HOME=${env.ANT_HOME}/echo
this will not work unless ANT_HOME is predefined in the environment.
The typical ant launch scripts will define ANT_HOME but not export it
into the environment.
Yes, I found that. It's not documented, however.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Release Notes Link Broken
The release notes link on http://ant.apache.org/srcdownload.cgi, which points to http://mirrons.combose.com/apache/ant/README.html is broken. I get a 403 Forbidden error. Is this where the link should point? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Notes Link Broken
Antoine Levy-Lambert wrote: Hello Steve, the URL sounds correct in its syntax (README.html is on other mirrors also under [root]/apache/ant/README.html. I cannot open this mirrons.combose.com right now in my browser, it is not found. I guess you have a list of mirrors (from which to make the download) to choose from in scrdownload.cgi I would expect other mirrors in the USA/Canada not to have this problem. The master ant distribution directory seems OK, so I am not too concerned, may be it is just a problem with one of n mirrors. Cheers, Antoine --- Ursprüngliche Nachricht --- Von: Steve Cohen [EMAIL PROTECTED] An: Ant Developers List dev@ant.apache.org Betreff: Release Notes Link Broken Datum: Sat, 21 May 2005 06:15:06 -0500 The release notes link on http://ant.apache.org/srcdownload.cgi, which points to http://mirrons.combose.com/apache/ant/README.html is broken. I get a 403 Forbidden error. Is this where the link should point? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Why mirror this particular document at all? Why not just keep it on the Ant site? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: cvs commit: ant/docs/manual/OptionalTasks ftp.html
[EMAIL PROTECTED] wrote: Little test on IE6 and Firefox 1.0.4 html body And now test html: pre lt;html style=test lt;body lt;/html /pre /body /html That works for me. You have to mask the character. After that the closing sign is ignored, because no opening sign was there. Jan -Ursprüngliche Nachricht- Von: Alexey N. Solofnenko [mailto:[EMAIL PROTECTED] Gesendet am: Mittwoch, 18. Mai 2005 06:05 An: Ant Developers List Betreff: Re: cvs commit: ant/docs/manual/OptionalTasks ftp.html Actually, gt; is also not required. - Alexey. Steve Cohen wrote: To be honest, I never thought about it. The previous version of the page used them and I just assumed they were required, and followed the pattern with my new examples. I didn't even assume, actually, I just followed the pattern unthinkingly. But you're quite right. The quot; are not necessary. The lt; and gt;, however, are. The source file is an html page. We aren't seriously suggesting formatting these emails, are we? To me, that makes no sense at all. This is a cvs-generated diff. Modifying it would be incorrect, making the diff unusable as a patch, which is, I guess, why these emails include them. I will, however, remove the unnecessary quot; marks. -- -- -- / Alexey N. Solofnenko home: http://trelony.cjb.net/ / - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Right again. I don't, however, think we should do this. I don't think it adds anything in clarity and is rather ugly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FTP.isUpToDate()
Antoine Levy-Lambert wrote: Do not worry if you are sure that the current behavior is buggy. Cheers, Antoine Well, I went and logged a bug on the issue thinking that this might provoke a little more discussion. Unfortunately, bugzilla seems to not have sent out an email about it, so it will get lost. Does this happen often? See http://issues.apache.org/bugzilla/show_bug.cgi?id=34941 Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/docs/manual/OptionalTasks ftp.html
Peter Reilly wrote: Martin Gainty wrote: Not to mention gt and other escaped characters No, Dominique was correctly compaining about the needless escaping of the quote characters Peter Can the Ant mail server either parse the html escaped characters and insert the correct character representation -OR- Reject the transmission altogether? Vielen Danke, Martin- - Original Message - From: Dominique Devienne [EMAIL PROTECTED] To: Ant Developers List dev@ant.apache.org Sent: Monday, May 16, 2005 10:21 PM Subject: Re: cvs commit: ant/docs/manual/OptionalTasks ftp.html On 14 May 2005 13:14:15 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: +pre + lt;ftp action=quot;getquot; + server=quot;ftp.hypthetical.frquot; + userid=quot;anonymousquot; + password=quot;[EMAIL PROTECTED]quot; + defaultDateFormatConfig=quot;d MMM quot; + recentDateFormatConfig=quot;d MMM HH:mmquot; + serverLanguageCodeConfig=quot;frquot;gt; + lt;fileset dir=quot;htdocs/manualquot;gt; + lt;include name=quot;**/*.htmlquot;/gt; +lt;/filesetgt; + lt;/ftpgt; +/pre The quot; are not necessary, are they Steven? Makes it a lot harder to read, no? --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To be honest, I never thought about it. The previous version of the page used them and I just assumed they were required, and followed the pattern with my new examples. I didn't even assume, actually, I just followed the pattern unthinkingly. But you're quite right. The quot; are not necessary. The lt; and gt;, however, are. The source file is an html page. We aren't seriously suggesting formatting these emails, are we? To me, that makes no sense at all. This is a cvs-generated diff. Modifying it would be incorrect, making the diff unusable as a patch, which is, I guess, why these emails include them. I will, however, remove the unnecessary quot; marks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FTP.isUpToDate()
Martijn Kruithof wrote:
Steve Cohen wrote:
In trying to bring over new commons-net timezone functionaility, I
discover the following:
protected boolean isUpToDate(FTPClient ftp, File localFile,
String remoteFile)
throws IOException, BuildException {
...
if (this.action == SEND_FILES) {
return remoteTimestamp + timeDiffMillis localTimestamp;
} else {
return localTimestamp remoteTimestamp + timeDiffMillis;
}
}
Off the top of my head, and given the general logic associated with
the name of the method, can anyone think of a reason why the two
greater-than signs in the above code should not be greater-than-or-equal?
In the test case I am developing from the new code, my first iteration
didn't produce the expected results. I expected one or two files to
be gotten, not the entire directory of 300 files. When I changed the
's above to ='s, the code worked as expected. Can anyone see
something I'm missing?
Hi
Depends on what error is actually wanted. I'd expect
remoteTimestamp + timeDiff + (remote)granularity localTimestamp -
(local)granularity
when no risk is to be taken that the file is not copied while it should
have been
or
remoteTimestamp + timeDiff - (remote)granularity = localTimestamp +
(local)granularity
when no rist is to be taken that the file is copied while it should not
have been.
When leaving out the granularity I'd say you are right an = should
always be used.
Martijn
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I agree with you. I suppose that with the current code, you can always
fudge the granularities by summing them together as timediffmillis in
the above code which is a settable parameter.
The case I have in mind is this:
ftp action = get
...
preservelastmodified=true
newer=true/
Repeating that twice in succession with the current code will ALWAYS
result in fetching the entire fileset twice whether the source files
change or not. This seems like an incorrect result, even a bug.
So I want to make this change.
But before I rush off and do that, I want, as a reality check, an idea
of a use case that this change would break. I can't think of one.
My thought is that anyone who would want to use this task with
newer=true and preservelastmodified=false isn't going to care about
granularity-based differences. That person is simply using the task
coarsely. And anyone who would do it as in the above snippet would want
= rather than .
Please, if someone can come up with a contradictory use case or other
argument, lay it out here, otherwise I am going to make the change.
The only plausible argument I can think of is backward compatibility of
existing scripts. I am guessing that anyone who is trying to use the
task precisely may already be adding or subtacting 1 in the
timediffmillis to overcome this problem.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] include FTP task revisions in 1.6.4 release
Steve Cohen wrote: Shall the newly added FTP task revisions be incorporated into release 1.6.4? I'm withdrawing this vote request. Although commons-net functions as expected, the relationship with the FTP task is a little more complicated than I'd thought, and those who have expressed fears are correct in doing so, in spite of any carping I might still want to do about remarks indicating that the remarkers considered this is an unwanted maintenance chore being thrust upon them rather than something motivated in the first place by bug reports and feature requests in Ant's own bug system. I had assumed that tying commons-net timezone functionality into the task's newer logic would be simpler than it has turned out to be. There are still a few wrinkles I need to work out. Since Steve Loughran is talking about a July release rather than the six months I'd heard bandied about earlier, I am less insistent on getting it in for 1.6.4. Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FTP.isUpToDate()
In trying to bring over new commons-net timezone functionaility, I
discover the following:
protected boolean isUpToDate(FTPClient ftp, File localFile,
String remoteFile)
throws IOException, BuildException {
...
if (this.action == SEND_FILES) {
return remoteTimestamp + timeDiffMillis localTimestamp;
} else {
return localTimestamp remoteTimestamp + timeDiffMillis;
}
}
Off the top of my head, and given the general logic associated with the
name of the method, can anyone think of a reason why the two
greater-than signs in the above code should not be greater-than-or-equal?
In the test case I am developing from the new code, my first iteration
didn't produce the expected results. I expected one or two files to be
gotten, not the entire directory of 300 files. When I changed the 's
above to ='s, the code worked as expected. Can anyone see something
I'm missing?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] include FTP task revisions in 1.6.4 release
Shall the newly added FTP task revisions be incorporated into release 1.6.4? Motivation: I understand this comes in under the wire and may cause justifiable trepidation among some. I still favor adding it to the release because: 1) The tasks add some important new capabilities (in order of importance): a) the ability for the newer attribute to recognize timezone differences between client and server b) the ability to handle the all-numeric timestamp format that some unixes (Debian for example) are now shipping with. c) the ability to handle legacy systems that still use locale-specific timestamp formatting (becoming rare but still encountered). Documentation of the new features has also been checked in. 2) Care has been taken to avoid adding new dependency requirements to Ant. The new features require commons-net-1.4.0 and the task cannot be compiled without it, but users with an earlier version of commons-net can still use the task exactly as before. Existing scripts will function exactly as before. 3) Just to reiterate - in spite of earlier postings the the contrary, including this in release 1.6.4 WOULD NOT REQUIRE USERS TO UPGRADE COMMONS-NET. This has been tested against commons-net-1.2.2 (the previous recommended system) and all tests passed. My vote: +1 List of files that would have to be tagged with the new release if this passes /org/apache/tools/ant/taskdefs/optional/net/FTP.java 1.71 /org/apache/tools/ant/taskdefs/optional/net/FTPConfigurator.java (new) 1.2 /ant/docs/manual/OptionalTasks/FTP.html 1.32 /ant/docs/manual/install.html 1.83 /ant/lib/libraries.properties 1.3 Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] include FTP task revisions in 1.6.4 release
Shall the newly added FTP task revisions be incorporated into release 1.6.4? Motivation: I understand this comes in under the wire and may cause justifiable trepidation among some. I still favor adding it to the release because: 1) The tasks add some important new capabilities (in order of importance): a) the ability for the newer attribute to recognize timezone differences between client and server b) the ability to handle the all-numeric timestamp format that some unixes (Debian for example) are now shipping with. c) the ability to handle legacy systems that still use locale-specific timestamp formatting (becoming rare but still encountered). Documentation of the new features has also been checked in. 2) Care has been taken to avoid adding new dependency requirements to Ant. The new features require commons-net-1.4.0 and the task cannot be compiled without it, but users with an earlier version of commons-net can still use the task exactly as before. Existing scripts will function exactly as before. 3) Just to reiterate - in spite of earlier postings the the contrary, including this in release 1.6.4 WOULD NOT REQUIRE USERS TO UPGRADE COMMONS-NET. This has been tested against commons-net-1.2.2 (the previous recommended system) and all tests passed. My vote: +1 List of files that would have to be tagged with the new release if this passes /org/apache/tools/ant/taskdefs/optional/net/FTP.java 1.71 /org/apache/tools/ant/taskdefs/optional/net/FTPConfigurator.java (new) 1.2 /ant/docs/manual/OptionalTasks/FTP.html 1.32 /ant/docs/manual/install.html 1.83 /ant/lib/libraries.properties 1.3 Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] include FTP task revisions in 1.6.4 release
Steve Loughran wrote: Steve Cohen wrote: Shall the newly added FTP task revisions be incorporated into release 1.6.4? Motivation: I understand this comes in under the wire and may cause justifiable trepidation among some. I still favor adding it to the release because: 1) The tasks add some important new capabilities (in order of importance): a) the ability for the newer attribute to recognize timezone differences between client and server b) the ability to handle the all-numeric timestamp format that some unixes (Debian for example) are now shipping with. c) the ability to handle legacy systems that still use locale-specific timestamp formatting (becoming rare but still encountered). Documentation of the new features has also been checked in. 2) Care has been taken to avoid adding new dependency requirements to Ant. The new features require commons-net-1.4.0 and the task cannot be compiled without it, but users with an earlier version of commons-net can still use the task exactly as before. Existing scripts will function exactly as before. 3) Just to reiterate - in spite of earlier postings the the contrary, including this in release 1.6.4 WOULD NOT REQUIRE USERS TO UPGRADE COMMONS-NET. This has been tested against commons-net-1.2.2 (the previous recommended system) and all tests passed. My vote: -1 I dont think I've -1'd anything before, at least not in recent memory. Here is my thinking (a) 1.6.4 is an emergency release to fix some defects that didnt show up during beta testing Fair enough. (b) any feature added now would go into the release without beta testing. It runs the risk of breaking. Fair enough, although it's worth repeating that existing tests that test existing functionality do not break, either with the old commons-net lib or the new. (c) We'd be effectively obliged to maintain the API forever. Its good to use something in a few of your own build files first to see what works, and what doesnt. What is there about this API compared to any others that Ant is obliged to maintain that you don't like? This objection is meaningless and insulting. These features have been extensively tested in commons-net. Commons-net is under the jakarta umbrella with an active team of developers. Meanwhile Ant maintains APIs adapting it to various commercial products for which it has no serious maintainers. I myself maintained the starteam tasks for Ant for as long as I had a job that gave me access to a StarTeam server. (late 2003). Looking back through CVS at the entire starteam package I find one substantive change made in a year and a half (a NPE fix). There have been no enhancements, and nothing but boilerplate changes. Okay, there's probably not too much demand for those tasks and, at any rate, no one has stepped forward. But please don't put jakarta-commons-net into that bag. If I sound a little resentful, it's because these changes were designed by me specifically with Ant in mind. I resisted suggestions from others that would have implemented these changes in fashions that were less compatible with Ant. Now this effort seems to be being treated as an unwanted intrusion. Summary: its too new a change to push into a release that we arent going to beta test. You should have stopped there. Once Ant1.6.4 ships we can start the push towards Ant1.7. That is: no more 1.6 releases barring disasters with the 1.6.4 version, instead we can decide on the feature set and release schedule for the version of ant that will have this change, and bring out a beta in, say, july. Anyone who wants the new features should be pushed towards this public beta, which will help test the while release. -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/docs/manual install.html
Stefan Bodewig wrote: On Thu, 12 May 2005, Steve Cohen [EMAIL PROTECTED] wrote: I don't know, though, guys. What do you think? Is it really worth it to avoid making the users upgrade? For me it depends on when you wanted to see the new task. If you wanted to include it in 1.6.4 (which is unlikely to happen anyway, given Steve's and Matt's comments) then you wouldn't get a +1 from me if it forced people to upgrade commons-net. This is just too fresh IMHO. If you are shooting for 1.7, having the code depend on commons-net 1.4.x is fine with me. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Well, I've done it. 1.4.0 is no longer required. Have a look. It isn't too ugly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: [patch] FTP.java - adding support for new features in com mons-net 1.4.0 and performance improvement
Antoine Levy-Lambert wrote: Steve Cohen wrote: However, it does seem to me that this test case is rather incomplete, and could be beefed up in several ways to test these and other recent features of commons-net which are not being tested here. Feel free to expand this test. I created this test to check that the pattern selection features of the ftp task work, when I refactored it. Makes sense, I suppose. You would presume that commons-net has its own tests (indeed it does) and therefore only test the interaction with Ant. I guess what I am asking is what the scope of these tests is. Who runs them, when, and how? (Do they change the password as I had to?). I believe almost no one runs these tests, except committers who are changing the ftp task. To make this test work in gump, there would be the need to install on the gump machine a standard ftp server used to run the tests. In commons-net we have tests that ARE part of gump and can be run anywhere and then we have tests that are NOT part of gump (we call them functional tests) since they depend on various ftp servers over which we have no control. These tests are only run manually, although they should pass, assuming the server is up, from anywhere, without modification or -D definition. (they use anonymous FTP). Do you think it would make sense to add such tests here? Or should I just be testing that the new attributes are accepted by Ant properly? I am eager to test the time zone feature in Ant, which virtually requires an external ftp server and could be very useful in Ant. The other new features, concerning languages other than English, etc., are, in my experience harder to test because there are so few servers that work that way anymore. Almost all the publicly accessible ftp servers have converted to English month names. I know because I looked all over the place and could find not a single one that didn't! I presume that the non-English server complaints we occasionally hear about concern various private intra-company servers that use older ftp servers. If it ain't broke, don't fix it. Apparently older ftp servers actually called ls and the newer ones don't. This will become even more moot as all-numeric timestamps become more prevalent in unix ftp servers - I recently learned that Debian is now shipping this way and hope this a wave of the future. I've also committed install.html to indicate that from here forward, commons.net = 1.4.0 is required. If commons.net 1.4.0 is required, is it not a big constraing for the 1.6.4 release ? Indeed. I was proceeding on Stefan's instructions to put it into the HEAD and have a vote later about adding them to 1.6.4. If the Ant team does not feel confident about requiring 1.4.0 so soon this vote will fail. I am working on revised manual page for the ftp task which has optional new attributes but I want to tweak that a bit more. +1 Antoine Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] FTP.java - adding support for new features in com mons-net 1.4.0 and performance improvement
Stefan Bodewig wrote: On Wed, 11 May 2005, Steve Cohen [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: If the tests pass - why not? :-) I wanted to discuss the tests and what is meant by that. When I saw Jan's remark I thought he must have been joking. I wouldn't call the existing ftp tests tests. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] D'oh! You'd have thought that smileyface would have alerted me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement
Stefan Bodewig wrote: On Wed, 11 May 2005, Steve Cohen [EMAIL PROTECTED] wrote: I recently spent some time looking over jpackage.org. Have you guys seen this operation? More than that. We modified the Ant wrapper script to suit their needs, so that they could stop distributing their version, for example. We've had some fruitful collaboration in the past. I used to be subscribed to their dev list but had to cut down on activities, so I dropped out of it. They don't like builds that depend on downloading stuff from the internet. Etc. They hate circular dependencies. Like me ;-) And me. I've come to live with these things, however. It was sort of refreshing to see these guys pounding away at making something better. I'm still subscribed to their list but I don't really have time to read it. They're somewhat annoyed with Ant. It's hard to talk to them. I've not seen that, if so, something must have changed over the past six months. Anything special? I was starting to get into flame wars that I pulled back from, since that was not my intent, and then had nicer conversations with one of the leading posters off-list. It seemed to me that they were SO frustrated with the circular dependencies of Ant that they always assumed the worst and didn't understand a few things. A little too much us-against-the-world. But very intriguing, nonetheless. Trying to figure out the right way to build Ant in that environment can not help but give the ant developer some new perspectives. If only I had the time. In that world, they have a heck of a time building Ant from source since Ant (its optional tasks, anyway) depend on things like commons-net, which depend on Ant to build. Chicken-egg again. Not really. They have separate RPMs for Ant and for ant with optional tasks. You only need the Ant RPM to build commons-net, and you need Ant and commons-net to build the ant-apache-commons-net RPM. I never succeeded in building ant from their source RPMs. Eventually I had to go with a binary RPM. Once I had that, I could build commons-net, etc. I was looking for an ant-core rpm (the rough equivalent of running just the bootstrap) but never found it. It seems to me that Ant is really at least two beasts: 1. a tool for running strictly java compiles and packaging into jars, wars, etc. But everybody will have a different opinion what makes up this core. copy? You bet. chmod? For those RPM builders probably yes. war? _I_ don't think so. (this may or may not equate exactly to Ant's core vs. optional tasks - e.g. why is cvs core, but other vcs optional?) historical reasons. cvs was there before any optional task came along. I guess script was ther first one labeled optional. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement
Jose Alberto Fernandez wrote: From: news [mailto:[EMAIL PROTECTED] On Behalf Of Nicola Ken Barozzi Stefan Bodewig wrote: On Wed, 11 May 2005, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: I do not think we can continue maintaining tasks for every project in the world just because they do not want to depend on ANT. Likewise, you cannot ask for every project to keep an Ant task just because Ant does not want to depend on them ;-) We ask exactly that from other projects. We would like the SVN people to maintain their SVN tasks. And the ClearCase people to maintain theirs because then you can upgrade and deliver them in sync with their new versions. On the other hand we promise not to break the API they use so that they do not need to worry about forward compatibility with ANT (within reason). If we want this effort to succeed, Would it make sense to release this interface as a separate package required by ant and the antlibs to be maintained by others. It might make the promise a little more concrete - and break some of the circular dependencies. Calm down. We are talking about an existing Ant task that gets used a lot. And so far nobody has asked the commons-net people whether they'd want to maintain it. If you ask me, Ant is the owner of the ftp task and commons-net only a support library. The javacc, antlr or weblogic tasks (for example) are completely different beasts IMHO. Yes. Ant tasks - like any piece of code really - should simply reside where people care about them, fix bugs and enhance them. IMHO this usually happens in Ant if the task is generic enough to be used by most committers, and ftp seems to be the case. Ok, but with that view. Any features of common-net will not be available until 1.7 is out some six month from now. Or people will have to use nightly builds. If you want the new features to be made available, then either common-net provides the task or has to coordinate the release cycles. Not sure who is the winner on this. I may not have made myself clear on one issue: When I talk about common-net's ftp task, I am not talking about the current task supported within ANT (which will have to stay there and get eventually deprecated). I am talking of a new ftp task, lets call it net:ftp/ that provides all the features and benefits of using the common-net libraries. It will be common-net's new replacement task and it will be under common-net control. That is the whole point of the antlibs. Jose Alberto Although I have committed the code into Ant proper, I still may have a go at this approach if I can find the time. I'd like to understand it a little better first. Can you point me at a good example? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: [patch] FTP.java - adding support for new features in com mons-net 1.4.0 and performance improvement
[EMAIL PROTECTED] wrote: Any chance one of you guys could also incorporate my simple patch to the FTP task that adds the initialcommand attribute? http://issues.apache.org/bugzilla/show_bug.cgi?id=34853 Thanks, John This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally. Steve Cohen [EMAIL PROTECTED] wrote on 12/05/2005 08:38:39 PM: Antoine Levy-Lambert wrote: Steve Cohen wrote: However, it does seem to me that this test case is rather incomplete, and could be beefed up in several ways to test these and other recent features of commons-net which are not being tested here. Feel free to expand this test. I created this test to check that the pattern selection features of the ftp task work, when I refactored it. Makes sense, I suppose. You would presume that commons-net has its own tests (indeed it does) and therefore only test the interaction with Ant. I guess what I am asking is what the scope of these tests is. Who runs them, when, and how? (Do they change the password as I had to?). I believe almost no one runs these tests, except committers who are changing the ftp task. To make this test work in gump, there would be the need to install on the gump machine a standard ftp server used to run the tests. In commons-net we have tests that ARE part of gump and can be run anywhere and then we have tests that are NOT part of gump (we call them functional tests) since they depend on various ftp servers over which we have no control. These tests are only run manually, although they should pass, assuming the server is up, from anywhere, without modification or -D definition. (they use anonymous FTP). Do you think it would make sense to add such tests here? Or should I just be testing that the new attributes are accepted by Ant properly? I am eager to test the time zone feature in Ant, which virtually requires an external ftp server and could be very useful in Ant. The other new features, concerning languages other than English, etc., are, in my experience harder to test because there are so few servers that work that way anymore. Almost all the publicly accessible ftp servers have converted to English month names. I know because I looked all over the place and could find not a single one that didn't! I presume that the non-English server complaints we occasionally hear about concern various private intra-company servers that use older ftp servers. If it ain't broke, don't fix it. Apparently older ftp servers actually called ls and the newer ones don't. This will become even more moot as all-numeric timestamps become more prevalent in unix ftp servers - I recently learned that Debian is now shipping this way and hope this a wave of the future. I've also committed install.html to indicate that from here forward, commons.net = 1.4.0 is required. If commons.net 1.4.0 is required, is it not a big constraing for the 1.6.4 release ? Indeed. I was proceeding on Stefan's instructions to put it into the HEAD and have a vote later about adding them to 1.6.4. If the Ant team does not feel confident about requiring 1.4.0 so soon this vote will fail. I am working on revised manual page for the ftp task which has optional new attributes but I want to tweak that a bit more. +1 Antoine Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Not in the 1.6.4 timeframe, but I will be happy to take a look, soon. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/docs/manual install.html
Stefan Bodewig wrote: On 12 May 2005, [EMAIL PROTECTED] wrote: +For all users, a minimum version of commons-net of 1.4.0 is now required. Is this really true? I understand it is required to compile ftp or if you use one of the new features. But if you use ftp the same way you did before and use a binary installation of Ant, 1.2.x should work as well, not? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] You are correct, sir. It won't compile but it will run against the older jar, as long as the new functionalities are not called. I forget that not everyone wants to build ant :-). The existing tests can be run successfully if you ignore the errors. You see, Antoine, your tests have already proven their value! I will revise this documentation, and also change the code to output a more meaningful error message if anyone tries to use the new features with an older jar. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/docs/manual install.html
Steve Cohen wrote: Stefan Bodewig wrote: On 12 May 2005, [EMAIL PROTECTED] wrote: +For all users, a minimum version of commons-net of 1.4.0 is now required. Is this really true? I understand it is required to compile ftp or if you use one of the new features. But if you use ftp the same way you did before and use a binary installation of Ant, 1.2.x should work as well, not? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] You are correct, sir. It won't compile but it will run against the older jar, as long as the new functionalities are not called. I forget that not everyone wants to build ant :-). The existing tests can be run successfully if you ignore the errors. You see, Antoine, your tests have already proven their value! I will revise this documentation, and also change the code to output a more meaningful error message if anyone tries to use the new features with an older jar. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Nope, spoke too soon. I wasn't running against what I thought I was. With commons-net-1.2.2 jar, the bad import statement makes the test constructor throw. This is so ugly. I wonder if I could do a Class.forName(), and if it doesn't throw, I know I can use reflection to do the new stuff, and avoid importing the new class. This is so ugly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/docs/manual install.html
Steve Cohen wrote: Steve Cohen wrote: Stefan Bodewig wrote: On 12 May 2005, [EMAIL PROTECTED] wrote: +For all users, a minimum version of commons-net of 1.4.0 is now required. Is this really true? I understand it is required to compile ftp or if you use one of the new features. But if you use ftp the same way you did before and use a binary installation of Ant, 1.2.x should work as well, not? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] You are correct, sir. It won't compile but it will run against the older jar, as long as the new functionalities are not called. I forget that not everyone wants to build ant :-). The existing tests can be run successfully if you ignore the errors. You see, Antoine, your tests have already proven their value! I will revise this documentation, and also change the code to output a more meaningful error message if anyone tries to use the new features with an older jar. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Nope, spoke too soon. I wasn't running against what I thought I was. With commons-net-1.2.2 jar, the bad import statement makes the test constructor throw. This is so ugly. I wonder if I could do a Class.forName(), and if it doesn't throw, I know I can use reflection to do the new stuff, and avoid importing the new class. This is so ugly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] OK. I found a way that isn't quite so ugly. I moved all the code that references the new class in commons-net off to a separate compilation unit, a new class in the org.apache.tools.ant.taskdefs.optional.net package. Now there are no issues with bad import statements in the FTP class itself. Since the new class is in the same package as FTP.java it doesn't need to be imported in order to compile. The new class isn't referenced unless the right commons-net version is present. As long as the new code isn't called, there is no problem when using older versions of commons-net. Otherwise, a BuildException is thrown. I don't know, though, guys. What do you think? Is it really worth it to avoid making the users upgrade? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement
Stefan Bodewig wrote: On Tue, 10 May 2005, Steve Cohen [EMAIL PROTECTED] wrote: As the author of the commons-net code that Mr. Praks is relying on, and an Ant committer, I would be happy to take a look at his code and sponsor it for the 1.6.4 release. There is no need to sponsor, you are a committer. We usually work in commit-then-review mode, at least for CVS HEAD, so go ahead and commit it to HEAD. After you've done that, you could call for a vote for merging the change over to the 1.6 branch. Personally I don't think a vote would be necessary, though. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I may be a committer but Mr Praks is not. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement
Neeme Praks wrote:
Steve Loughran wrote:
I worry about releasing any change to code without giving it time to
stabilise and beta test. Last minute this won't break anything
patches always break something. Always. At least in my experience.
If commons1.4.0 is incompatible with shipping ftp then yes, we have
no choice but to upgrade. But if it is a feature enhancement, then it
needs
to go into CVS_HEAD
Very legitimate concern.
However, this is a trivial change.
commons-net 1.4.0 added a configuration javabean for FTP client.
It is a simple value-object that has some setters and then it can be
used to configure a FTP client instance.
All the added code does is expose this javabean on the FTP task through
delegating setters.
Let me illustrate with some code:
public class FTP extends Task {
[...]
private FTPClientConfig configuration = null;
/**
* Gets a FTPClientConfig. If the configuration object has not been
* created yet, it is created also.
*/
private FTPClientConfig getConfiguration() {
if (this.configuration == null) {
this.configuration = new FTPClientConfig();
}
return this.configuration;
}
/**
* Delegate method for
codeFTPClientConfig.setDefaultDateFormatStr(String)/code.
* @param defaultDateFormatStr
* @see #getConfiguration()
* @see FTPClientConfig
*/
public void setDefaultDateFormat(String defaultDateFormatStr) {
getConfiguration()
.setDefaultDateFormatStr(defaultDateFormatStr);
}
[...there are 5 more delegating setters like this, but I'm skipping them
here for clarity...]
public void execute() throws BuildException {
[...]
ftp = new FTPClient();
if (this.configuration != null) {
ftp.configure(this.configuration);
}
ftp.connect(server, port);
[...]
}
[...]
}
Simple enough, no?
Assuming that commons-net code is bug-free, this code cannot possibly
break anything. And it is backwards compatible, if there is no
configuration set, no configuration is used.
Rgds,
Neeme
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Well, you're both right. The new commons-net code is not incompatible
with Ant. This is just a new feature of commons-net.
However, it's an extremely simple feature, just passing bean attributes
around. I am quite confident that we can add just the support for the
new commons-net feature and have all the tests pass.
Other parts of Mr. Praks' patch are less simple (retry handler, etc.)
and I've asked him to remove those for now. These definitely belong in
CVS_HEAD after the release.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement
Stefan Bodewig wrote: On Wed, 11 May 2005, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: I do not think we can continue maintaining tasks for every project in the world just because they do not want to depend on ANT. Calm down. We are talking about an existing Ant task that gets used a lot. And so far nobody has asked the commons-net people whether they'd want to maintain it. If you ask me, Ant is the owner of the ftp task and commons-net only a support library. The javacc, antlr or weblogic tasks (for example) are completely different beasts IMHO. Maybe Sun should ship the Javac compiler adapter? Just kidding. Maybe people would be less scare about it if we provide a task that is able to produce a ready to go plugin JAR containing all the pieces necessary for your antlib to work using an antlib:package URL. Do we have such a thing already, if nor it should be quite easy to do. I'm not sure what you mean. A task that creates antlib.xml and puts it into the proper place inside the jar? I'm having a hard time to come up with a syntax for the task (you still have to tell it which taskname maps to which task) that doesn't look like antlib.xml. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] On decoupling in general: I recently spent some time looking over jpackage.org. Have you guys seen this operation? Their basic mission is to convert all of open-source java into RPMs. They don't like builds that depend on downloading stuff from the internet. Etc. They hate circular dependencies. They're somewhat annoyed with Ant. It's hard to talk to them. There is a real culture clash between the Java open-source world as it has evolved and their world. I am not convinced that what they are doing is practical (and it's certainly a HUGE task they've set for themselves), but I did spend a little time looking at what they're doing and it did get me thinking about the structure of Ant. In that world, they have a heck of a time building Ant from source since Ant (its optional tasks, anyway) depend on things like commons-net, which depend on Ant to build. Chicken-egg again. It seems to me that Ant is really at least two beasts: 1. a tool for running strictly java compiles and packaging into jars, wars, etc. 2. other related tools that are very useful to the typical build-meister (ftp, support for version control systems, etc.) I think Ant does somewhat recognize this distinction in the business of bootstrap vs. build when building ant. The bootstrap stuff is core, the other stuff is somewhat peripheral. (this may or may not equate exactly to Ant's core vs. optional tasks - e.g. why is cvs core, but other vcs optional?) I don't know what any of this means, going forward, probably nothing, but it's food for thought. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement
Stefan Bodewig wrote: On Wed, 11 May 2005, Steve Cohen [EMAIL PROTECTED] wrote: Other parts of Mr. Praks' patch are less simple (retry handler, etc.) and I've asked him to remove those for now. These definitely belong in CVS_HEAD after the release. The release comes from a branch, so you can go ahead and commit to HEAD whenever you see fit. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] So commit to head as we see fit and maybe it will be moved to the branch? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: [patch] FTP.java - adding support for new features in com mons-net 1.4.0 and performance improvement
[EMAIL PROTECTED] wrote: Neeme Praks wrote: Ok, commons-net 1.4.0 has been released now. How can we proceed? Since there is apparently an Ant 1.6.4 version coming out on May 19th and since Neeme Praks has already submitted a patch to accomodate it, why not try to get this into that release? As the author of the commons-net code that Mr. Praks is relying on, and an Ant committer, I would be happy to take a look at his code and sponsor it for the 1.6.4 release. I realize that there may be other deadlines here. What do other Ant committers think? Steve Cohen If the tests pass - why not? :-) Jan I realize that the discussion has moved well beyond this point, but I wanted to discuss the tests and what is meant by that. I think you mean, in this case, /src/testcases/org/apache/tools/ant/taskdefs/optional/net/FTPTest.java, right? I have applied the latest revised patch from Neeme Praks with a few modifications. We had a couple of iterations as I explained to him the way I thought the task should work, and he has coded it to those specifications, including only support for the new commons-net features and not including the retry and speedup improvements from his original patch which need more study. The tests mentiuned above all passed, once I changed /src/etc/testcases/taskdefs/optional/net/ftp.xml so that the ftp.password property was redefined as my password on my system. The original had a password of sunshine. Without that change all the tests failed. Is that the recommended practice for this test? Or is the test assuming some particular ftp server configuration that most servers have and my system does not? (I do not normally turn an ftp server on on my system and just accepted the default). Assuming that all the above is correct, I am satisfied that the code breaks nothing and am therefore committing it. However, it does seem to me that this test case is rather incomplete, and could be beefed up in several ways to test these and other recent features of commons-net which are not being tested here. I guess what I am asking is what the scope of these tests is. Who runs them, when, and how? (Do they change the password as I had to?). I've also committed install.html to indicate that from here forward, commons.net = 1.4.0 is required. I am working on revised manual page for the ftp task which has optional new attributes but I want to tweak that a bit more. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: [ANNOUNCEMENT] Commons-Net 1.4.0 Released]
The new release of jakarta-commons-1.4.0 contains some features that were specifically designed with Ant in mind. In particular the FTPClientConfig class was designed with the thought of enabling the enhancement of the ant ftp task to 1. handle ftp servers with file listing formats that format dates in other than the standard (i.e. US English) ways. More importantly, perhaps, for Ant 2. handle time zone differences between client and server. This would enable dependency checking to be more usefully associated with the task. In the next few weeks (months) I am intending to rework the ftp task to take advantage of these new capabilities. This would involve adding some new attributes to the task and transmitting these to the commons-net implementation. ---BeginMessage--- The Commons-Net team are pleased to announce the release of version 1.4.0. This release provides several fixes and enhancements, including: - The addition of a new configuration mechanism that enables the FTPClient component to work with a much larger range of server formats and locales; - The addition of missing NTP unit tests; - The addition of a new FTP parser implementation for MVS; - Various fixes to the TFPClient and NTPClient components A list of changes can be found at http://jakarta.apache.org/commons/net/changes-report.html#1_4_0 _ Sign up for eircom broadband now and get a free two month trial.* Phone 1850 73 00 73 or visit http://home.eircom.net/broadbandoffer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [ANNOUNCEMENT] Commons-Net 1.4.0 Released]
Stefan Bodewig wrote: On Tue, 10 May 2005, Steve Cohen [EMAIL PROTECTED] wrote: In the next few weeks (months) I am intending to rework the ftp task to take advantage of these new capabilities. Maybe Neeme Praks' patch[1] would provide a nice starting point? Stefan Footnotes: [1] http://marc.theaimsgroup.com/?l=ant-devm=111523085825979w=2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Neeme Praks was very helpful in debugging the new commons code. I suggested that he modify the task. I didn't realize that he had contributed the code and I will have a look at it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [ANNOUNCEMENT] Commons-Net 1.4.0 Released]
Jose Alberto Fernandez wrote: Why not move the task or its new version into jakerta-commons and provide us with a ready to go feature full antlib. That would allow us to start decoupling things from the main ANT release. Jose Alberto I have not been as active in Ant circles as in the past. Is decoupling now a strategic priority for Ant? Can you please provide me with more details, examples? I'd be happy to use that approach if that's the direction the community is taking. I think it's a good idea. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [ANNOUNCEMENT] Commons-Net 1.4.0 Released]
Steve Loughran wrote: Jose Alberto Fernandez wrote: From: Steve Cohen [mailto:[EMAIL PROTECTED] Jose Alberto Fernandez wrote: Why not move the task or its new version into jakerta-commons and provide us with a ready to go feature full antlib. That would allow us to start decoupling things from the main ANT release. Jose Alberto I have not been as active in Ant circles as in the past. Is decoupling now a strategic priority for Ant? Can you please provide me with more details, examples? I'd be happy to use that approach if that's the direction the community is taking. I think it's a good idea. My point here is that Ant's ftp/ will not be re-release until the next release of Ant, God knows when. If you want the new features to be available sooner it may be a better idea the have the new task as part of jakarta-commons or some pluggable jar that can be released faster. We are all under Apache so borrowing from the current code should be no issue (am I wrong?). We can then point people to the new ftp task provided by commons. We may talk about cross-distribution later as we are all under apache, but maybe a link in our documentation to yours will be good enough. As to how define the antlib is almost trivial :-) Thoughts? There is actually one big weakness of independent releases, and that is you have to support older versions of Ant. I have to make sure the smartfrog tasks and build files work with ant1.6.x, and get deprecated warnings related to FileUtils when I build on 1.7, because they may be deprecated there but there is no alternative to their use in the 1.6 codebase. Moving stuff out of the main branch simplifes some things, but adds others. Yes. I think you're right. As it stands now, Ant, or at least this optional ftp task of ant, depends on commons-net. The suggestion that the ant task be moved to commons-net, is, in my opinion a non-starter because it would make commons-net depend on ant and I don't want to go down that circular path. I admit I know next to nothing about antlib, and in fact it was nothing until I googled it just now. If the code for such an ftp task were made to reside in such a structure (rather than in commons-net itself) there would be no circularity. However, unless there is a general move to decouple ant, which I would support on general principles, I think these changes belong on the main stem of ant going forward. There has been more than one request/bug report concerning these features, and these requests should be granted now that there is finally a means of doing so. For the time being, Neeme Praks' contributions or something like them fill the gap until the next release. These are not subsidiary features of commons-net and they should not be subsidiary features of the ant ftp task. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement
Neeme Praks wrote: Ok, commons-net 1.4.0 has been released now. How can we proceed? Meanwhile I also implemented the feature of retry-on-IOException, for FTP task. Stefan Bodewig wrote: The vote has passed and release is being prepared (see below). Hopefully it will be ready in a day or two. Sounds good. Original Message Subject: [ANNOUNCEMENT] Commons-Net 1.4.0 Released Date: Tue, 10 May 2005 09:22:31 +0100 From: Rory Winston [EMAIL PROTECTED] To: announcements@jakarta.apache.org, commons-dev@jakarta.apache.org, commons-user@jakarta.apache.org The Commons-Net team are pleased to announce the release of version 1.4.0. This release provides several fixes and enhancements, including: - The addition of a new configuration mechanism that enables the FTPClient component to work with a much larger range of server formats and locales; - The addition of missing NTP unit tests; - The addition of a new FTP parser implementation for MVS; - Various fixes to the TFPClient and NTPClient components A list of changes can be found at http://jakarta.apache.org/commons/net/changes-report.html#1_4_0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Since there is apparently an Ant 1.6.4 version coming out on May 19th and since Neeme Praks has already submitted a patch to accomodate it, why not try to get this into that release? As the author of the commons-net code that Mr. Praks is relying on, and an Ant committer, I would be happy to take a look at his code and sponsor it for the 1.6.4 release. I realize that there may be other deadlines here. What do other Ant committers think? Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.6.2 - where do we stand?
Stefan - I find that I am able to connect and commit. So I guess you're right. But I cannot find that email anywhere in my mailbox (my apache.org mail gets forwarded), nor did I find anything on the commons-dev mailing list indicating that the vote had passed. On Monday 28 June 2004 6:33 am, Stefan Bodewig wrote: On Mon, 28 Jun 2004, Steve Cohen [EMAIL PROTECTED] wrote: I'd do it myself, please do. but I'm wondering what is the status of the committer vote that was taken on me a couple of weeks ago. please check your apache.org mail ;-) You should have commit access already. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.6.2 - where do we stand?
Indeed you did, as I can now see. I guess I missed it. I wasn't looking for the right thing. The things I searched for trying to find this message were the presence of my name in the body or subject of the email, which weren't there because the message was sent directly to me, and the presence of the word committer in the subject and body, which weren't there either, karma being the word you used instead. Whatever, glad to be aboard. Anyway, sorry to have inadvertently hijacked the thread. Ant 1.6.2 - where DO we stand? On Tuesday 29 June 2004 1:50 am, Conor MacNeill wrote: Steve, I did you a welcome to Ant email on 18-Jun to this email address. Anyway, whatever, the vote passed and we are glad to have you aboard as a committer. Conor Steve Cohen wrote: Stefan - I find that I am able to connect and commit. So I guess you're right. But I cannot find that email anywhere in my mailbox (my apache.org mail gets forwarded), nor did I find anything on the commons-dev mailing list indicating that the vote had passed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.6.2 - where do we stand?
FTP task was broken in some cases by changes in commons-net. These were fixed in the recent release 1.2.2 of commons-net. All that needs to happen in ant now is for the docs to be updated to mandate use of commons-net 1.2.2. I'd do it myself, but I'm wondering what is the status of the committer vote that was taken on me a couple of weeks ago. On Monday 28 June 2004 6:06 am, Stefan Bodewig wrote: Hi all, we've brought the TODO file to two items and both indicate they might not go into 1.6.2. I'd like to wait for some confirmation on the Tomcat 5.x jspc issue, but other than that I think we could roll a 1.6.2 release candidate. WDYT? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCEMENT][NET] jakarta-commons/net 1.2.2 Released
The Jakarta Commons team announces the release of version 1.2.2 of the Jakarta Commons/Net component. This release fixes a problem introduced with recently released version 1.2.0 in which file listings would not correctly 'remember' the current directory when no directory was specified. This had particularly hampered the Ant ftp task. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: [ANNOUNCEMENT][NET] jakarta-commons/net 1.2.1 Released (fix release)
Ant users wanting the autodetect-server-type functionality recently released as commons-net-1.2.0, should now be targeting commons-net-1.2.1. -- Forwarded Message -- Subject: [ANNOUNCEMENT][NET] jakarta-commons/net 1.2.1 Released (fix release) Date: Wednesday 05 May 2004 11:33 pm From: Steve Cohen [EMAIL PROTECTED] To: announcements@jakarta.apache.org, commons-dev@jakarta.apache.org, commons-user@jakarta.apache.org The Jakarta Commons team announces the release of version 1.2.1 of the Jakarta Commons/Net component. This release fixes recently released version 1.2.0 which would not compile on versions of the Java JDK earlier than 1.4. Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE][NET] Release commons-net 1.2.1
This will be a fix release to fix the problem introduced in 1.2.0 that it will not compile using jdk 1.4 and nothing else. Details at http://issues.apache.org/bugzilla/show_bug.cgi?id=28775, which I've already fixed (and verified against jdk 1.2). Also, per the advice of Stephen Colburne, this release will be COMPILED with JDK 1.3, something I did not do with 1.2.0. This problem has been pointed out today on the jakarta-commons list and the ant list as well. Daniel Savarese has already voted +1 and now, so do I. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: [ANNOUNCEMENT][NET] jakarta-commons/net 1.2 Released
Those Ant users (of version 1.6.0 or above) who use or who would like to use the ftp task against non-unix ftp servers but have found it to fail there should replace the existing version of commons-net.jar on their Ant classpath with this one. It can autodetect the type of server it is accessing and react accordingly. The only other requirement is that a version of jakarta-oro.jar 2.0.1 also be on the classpath, but this has been the case since the release of ant 1.6.0 for using the ftp task.---BeginMessage--- The Jakarta Commons team is pleased to announce the release of version 1.2.0 of the Jakarta Commons/Net component. Commons/Net is an Internet protocol suite Java library which supports Finger, Whois, TFTP, Telnet, POP3, FTP, NNTP, SMTP, and some miscellaneous protocols like Time and Echo as well as BSD R command support. This release adds, for the first time, autodetection of FTP server type when retrieving an FTP listing so that non-unix FTP servers can automatically provide usable listings with valid dates, etc. Server types supported in this are Windows NT, OS2, VMS, OS400. Formerly only unix was supported in this way. This enables its automatic use in Ant's FTP task, for example, for these server types as well as the original unix. Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: [ANNOUNCEMENT][NET] jakarta-commons/net 1.2 Released
With the release of jakarta-commons/net 1.2, I would like to propose that Ant update its use of commons/net to use this new version in time for the next version which I see is being discussed. Doing so should greatly reduce the incidence of complaints about the FTP task when run against non-unix servers. 1.2 automatically detects the server type, recognizing, in addition to unix, which was supported in all previous versions, NT, OS2, VMS and OS400 servers. This functionality will work out of the box if this version of commons-net is used. I will also be preparing a patch that would enable parsers that cannot be autodetected, including user-developed FTP list parsers, to be plugged into the ant task. There is also some verbiage under the FTP task that should be changed to reflect this.---BeginMessage--- The Jakarta Commons team is pleased to announce the release of version 1.2.0 of the Jakarta Commons/Net component. Commons/Net is an Internet protocol suite Java library which supports Finger, Whois, TFTP, Telnet, POP3, FTP, NNTP, SMTP, and some miscellaneous protocols like Time and Echo as well as BSD R command support. This release adds, for the first time, autodetection of FTP server type when retrieving an FTP listing so that non-unix FTP servers can automatically provide usable listings with valid dates, etc. Server types supported in this are Windows NT, OS2, VMS, OS400. Formerly only unix was supported in this way. This enables its automatic use in Ant's FTP task, for example, for these server types as well as the original unix. Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ---End Message--- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: possible patch for FTP task
I won't comment on the quality of Mr. Peer's patch, but, in response to Antoine's question I would say that Ant and not commons-net is the proper place to handle this. Commons-net's FTPClient class has no concept of a session during which a connection stays open to perform multiple tasks. Nor are there methods there for getting a list of files. The Ant code is building a collection of files to transfer, and then, one-by-one, calling getFile(), sendFile() etc., on a connection that it has opened. In other words, Ant is already managing the session and it can hardly be otherwise. Therefore if this functionality is desired, I believe that Ant is the right place to implement it. I might also suggest looking into why the ftp server is resetting so often. There might be simpler server-level fix that could make this problem go away. On Tuesday 23 March 2004 3:28 pm, Antoine Lévy-Lambert wrote: Hi Joe, I suggest you create a bugzilla report ( http://issues.apache.org/bugzilla) concerning this, and you attach your patch there. I am not sure however whether this problem should best be handled in the ant task or in commons-net. I hope that Steve Cohen will see these postings. Cheers, Antoine Joe Peer wrote: dear Ant developers, today i tried the FTP task and I ran into the problem that my FTP server (runs on windows) resetted the connections quite frequently (i've used the most recent versions of ant and commons-net), resulting in an abort of the FTP task and build failure. Therefore, i slightly adjusted the sourcecode of org.apache.tools.ant.taskdefs.optional.net.FTP to re-connect to the server in case of an error, just like many of the GUI based FTP clients do (e.g. SmartFTP). I have added an attribute maxAttempts to define how often the FTP task should re-connect/retry before it gives up (default value is 1, to ratain un-patched behavior). pls. let me know if you think that this patch could be helpful and where i should send it to, kind regards, Joe Peer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incorrect documentation of FTP task [net]
On Tuesday 17 February 2004 10:11 am, Dominique Devienne wrote: From: Steve Cohen [mailto:[EMAIL PROTECTED] While it is true that the CVS HEAD of commons-net is required and while it is true that jakarta-oro is required (jakarta-oro is now required for any uses of the ftp task using commons-net), I don't believe it is true that 2.0.8 of oro is required. As far as I know, any jakarta-oro verson greater than VERSION 2.0.1 will work. Certainly, the latest commons-net code takes no special advantage of the latest oro-code. Why can't commons-net use java.util.regex when running under JDK1.4+, rather than requiring Jakarta-oro, when a good Regular Expression is already built in? Ant already does this (use ORO or JDK regex). Thanks, --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To have relied on the JDK regex would tie commons-net to JDK 1.4+ unless we could somehow have managed this conditiionality. The decision to go with oro was made when JDK 1.4 was in much less widespread use, and may even have come before the release of 1.4. How does Ant do it? Is Ant now using preprocessed code? Please point me at the place in ant where you accomplish this. This comes up more frequently now in Ant because Ant 1.6 made the switch to commons-net from NetComponents. NetComponents did not rely on oro because it did not do regular expression parsing of the listings. It was also much less flexible because of that - it could only handle unix FTP servers. Using regexes opened up a path to implement support of other server types more easily. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incorrect documentation of FTP task [net]
On Tuesday 17 February 2004 8:27 pm, Steve Cohen wrote: On Tuesday 17 February 2004 10:11 am, Dominique Devienne wrote: From: Steve Cohen [mailto:[EMAIL PROTECTED] While it is true that the CVS HEAD of commons-net is required and while it is true that jakarta-oro is required (jakarta-oro is now required for any uses of the ftp task using commons-net), I don't believe it is true that 2.0.8 of oro is required. As far as I know, any jakarta-oro verson greater than VERSION 2.0.1 will work. Certainly, the latest commons-net code takes no special advantage of the latest oro-code. Why can't commons-net use java.util.regex when running under JDK1.4+, rather than requiring Jakarta-oro, when a good Regular Expression is already built in? Ant already does this (use ORO or JDK regex). Thanks, --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To have relied on the JDK regex would tie commons-net to JDK 1.4+ unless we could somehow have managed this conditiionality. The decision to go with oro was made when JDK 1.4 was in much less widespread use, and may even have come before the release of 1.4. How does Ant do it? Is Ant now using preprocessed code? Please point me at the place in ant where you accomplish this. This comes up more frequently now in Ant because Ant 1.6 made the switch to commons-net from NetComponents. NetComponents did not rely on oro because it did not do regular expression parsing of the listings. It was also much less flexible because of that - it could only handle unix FTP servers. Using regexes opened up a path to implement support of other server types more easily. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Answering my own question, I now see what Ant is doing - in the ant/src/main/org/apache/tools/ant/util/regexp package. http://cvs.apache.org/viewcvs.cgi/ant/src/main/org/apache/tools/ant/util/regexp/ You've built an interface to encapsulate the choice in regex implementations with automatic checking. Sweet! Perhaps we could port it to commons-net - it's too ant-specific as it stands. But, do we really want all jars used by ant to make their own copy of this functionality? I don't think so. That starts to get messy really quick. Perhaps this checker mechanism could be ported to commons (a la commons-logging). Then it could be available to other clients, in particular, to commons clients. But of course then we'd be requiring yet another jar in order to use ant! Doh! Unless this jar were on the DEFAULT classpath of ant. I think we ought to think seriously about what we are doing here before we rush into coding anything like this. There is also another ant task that unconditionally requires oro, by the way - perforce. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incorrect documentation of FTP task [net]
This is all true, Daniel, but I think the initial motivation of Dominique
Devienne was to REMOVE the requirement that oro be on ant's runtime classpath
when running the ftp taks, not to make oro a central dispatch point for other
regex processors. In case it wasn't clear, I don't really support Dominique
on this, unless it can be done right which is not quite so trivial becasue
the wrong ways simply replace the requirement to use one jar with the
requirement to use another.
At the end of the day, is it that hard to put a jar on your classpath?
On Wednesday 18 February 2004 1:05 am, Daniel F. Savarese wrote:
In message [EMAIL PROTECTED], Steve Cohen writes:
You've built an interface to encapsulate the choice in regex
implementations with automatic checking. Sweet! Perhaps we could port
it to commons-net -
...
Perhaps this checker mechanism could be ported to commons (a la
commons-logging). Then it could be available to other clients, in
particular, to commons clients. But of course then we'd be requiring yet
...
I think we ought to think seriously about what we are doing here before we
rush into coding anything like this.
*sigh* No one ever brings these things up on the oro or regexp mailing
lists. This is one of those really easy things to do with oro, which
most folks don't realize implements three different regular expression
engines. I know I promised to do the vpp-based conditional compilation
to provide a J2ME/JDK1.1 compatible version of oro, but I just haven't
found the time. This however is easy stuff. I just added two new
interfaces to org.apache.oro.text.regex: PatternMatchingEngine and
PatternCompilerOptions. I implemented these interfaces for the
Perl5, Awk, and Glob engines. I then wrote a PatternMatchingEngineFactory
class to generate engines. You can put the J2SE 1.4 detection code
in there and add an org.apache.oro.text.java package that wraps
java.util.regex. All you have to do is implement PatternMatcher,
PatternCompiler, and Pattern for J2SE 1.4. If someone will step up
to do this, I'm sure the PMC will grant commit access immediately.
I'd actually rather if all of jakarta had commit access to oro for
this very kind of situation. When you don't have commit access, there
is sometimes a tendency to reinvent the wheel.
I've appended a modified version of the grep example that shows how
you might pick an engine based on a set of preferences. At any rate,
I very much thing oro is the place for generic regular expression
engine support since it was designed with that in mind from the
start (although the pattern compilation options could have been
abstracted better at its genesis). I invite anyone and everyone to
do a checkout of the latest jakarta-oro files in CVS and start
improving my 30 minute hack.
daniel
package examples;
import java.io.*;
import java.util.*;
import org.apache.oro.text.*;
import org.apache.oro.text.regex.*;
/**
* This is a no-frills implementation of grep that demos the use of
* PatternMatchingEngineFactory to choose different
* regular expression engines. It performs case insensitive matching
* to demonstrate the use of the PatternCompilerOptions interface.
*
* @version @version@
*/
public final class engineExample {
static int _file = 0;
static final String[] _preferences = {
PatternMatchingEngineFactory.JAVA_KEY,
PatternMatchingEngineFactory.PERL5_KEY,
PatternMatchingEngineFactory.POSIX_KEY,
PatternMatchingEngineFactory.AWK_KEY,
PatternMatchingEngineFactory.GLOB_KEY
};
// args[] is declared final so that Inner Class may reference it.
public static final void main(final String[] args) {
PatternMatchingEngineFactory factory;
PatternMatchingEngine engine = null;
PatternCompiler compiler;
PatternCompilerOptions options;
PatternMatcher matcher;
MatchActionProcessor processor;
int mask;
if(args.length 2) {
System.err.println(Usage: grep pattern filename ...);
System.exit(1);
}
factory = new PatternMatchingEngineFactory();
// Demonstration of choosing engine based on preferences.
for(int i = 0; i _preferences.length; ++i) {
if(factory.containsKey(_preferences[i])) {
engine = factory.get(_preferences[i]);
break;
}
}
if(engine == null)
engine = factory.get(PatternMatchingEngineFactory.DEFAULT_KEY);
compiler = engine.createCompiler();
matcher = engine.createMatcher();
options = engine.getOptions();
mask = options.getMask(PatternCompilerOptions.CASE_INSENSITIVE);
processor = new MatchActionProcessor(compiler, matcher);
try {
if(args.length 2) {
// Print filename before line if more than one file is specified.
// Rely on file to point to current file being processed.
processor.addAction(args[0], mask, new MatchAction() {
public void
Incorrect documentation of FTP task
I see that someone has tried to incorporate my suggestion for using the latest commons-net.jar in order to use ant's ftp task with NT-based servers. However, the documentation is not quite correct. It says: To use the FTP task with Microsoft FTP servers, you need CVS HEAD of commons-net and jakarta-oro after 2004-02-01 or a release of commons-net after 1.1.0 and jakarta-oro after 2.0.8. While it is true that the CVS HEAD of commons-net is required and while it is true that jakarta-oro is required (jakarta-oro is now required for any uses of the ftp task using commons-net), I don't believe it is true that 2.0.8 of oro is required. As far as I know, any jakarta-oro verson greater than VERSION 2.0.1 will work. Certainly, the latest commons-net code takes no special advantage of the latest oro-code. So while users do need to get the latest commons-net code to take advantage of this, I think they don't really need to upgrade their jakarta-oro jar above what ant uses, although it can't hurt anything. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
optional jars
Can someone please clarify the optional jar requirement for ant = 1.6? The manual says in one place that you must build ant with the library dependencies present, and in another place (Installing ant-Optional Tasks) it states that you can simply drop the dependency jar into ant's lib directory (making no mention of building). I know building was required pre 1.6 but I'm not sure what the status is post 1.6. There's a guy asking this question now on the user's list in regard to the FTP task and I don't want to steer him wrong. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant 1.6.1
On Friday 16 January 2004 4:56 am, Steve Loughran wrote: Steve Cohen wrote: Another issue to consider. I don't know if it's strictly a 1.6.1 issue or further down the line but the ant developers should consider it. I have been working with the jakarta-commons/net project to create a more capable system, able to detect what system its FTPClient class is connecting with. You may remember several complaints over the last couple of months about our ftp task not working on non-unix ftp servers. The improvements in commons/net will allow the correct server to be auto-detected in the most common cases, and in those odd cases where this is not possible, it will be possible to indicate explicitly which parser is to be used (i.e. in ant, a new parameter to the task). Thus it will be possible to rewrite our ftp task to solve these long standing problems. This version of commons-net (1.2.0) has not yet been released but can probably be released in less than a week. It seems from this thread that these changes will come too late for ant 1.6.1. Please correct me if that's wrong. Can someone tell me what plans, if any, are contemplated for ant 1.6.2? I'd prefer to target this as a 1.7 rework, as it would have side effects (specifically, need a newer version of commons.net) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To be honest, this is the response I was expecting, and it makes sense. In fact, without any changes to Ant, simply dropping in the 1.2.0 release of commons-net (when it's released) will gain the advantage of autodetection for Unix, Windows NT, OS/2 and VMS ftp systems. It is only for any outliers to this group that Ant would have to be recoded. Realizing this, I would say it's better to wait until 1.7 (but why not 1.6.2?) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Launcher and JPackage RPMs
Well, we at commons-net would have been rushing the release to meet ant's
deadline and there are internal refactorings which we would have liked to
have included that we were planning to postpone in the rush, but now will
take the time to get right, so I doubt that commons-net-1.2.0 will be done in
time for ant 1.6.1 and therefore we shouldn't update the ant manual just yet.
I think the best procedure will be for commons-net to work at it's own best
pace and when it's done, notify the ant list, via bugzilla and via posts to
the ant-dev and ant-user lists. At that point, any ant users needing this
functionality would be able to grab the commons-net-1.2.0 jar and get the
basic functionality. At that point also, coding could begin on the HEAD
branch of ant and the documentation in time for 1.7 (or maybe 1.6.2 if that
comes to pass).
On Friday 16 January 2004 9:31 am, Antoine Lévy-Lambert wrote:
Peter Reilly wrote:
Antoine Lévy-Lambert wrote:
I am +1 to get this into ant 1.6.1.
(in relation to static map of jarfile-manifest class path in
AntClassLoader2).
Ok I will commit that.
Another optimization I tried was a quick hack to DefBase to have a
static field containing the default classloader, so it
gets set once. This did speed up the typedef the second and
subsequent times and reduced the
time for the test to 1.6 second (from 3 and thus below the 1.5.4 times
(2 second) when using the crimson xml parser).
Sounds useful.
However it is a complete hack, and does not deal with non-default
classpaths like:
typedef classpath=${antlib.jar}
resource=net/sf/antcontrib/antcontrib.properties/
Do you mean : your change is bringing an optimization for taskdefs which
are done based on jars which have already been loaded by the launcher,
presumably because they are in $ANT_HOME/lib or in a -lib directory ?
And not if the taskdef is requiring extra jars or directories which were
not included when ant got started ?
Cheers,
Antoine
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: New Launcher and JPackage RPMs
Please ignore. This last comment by me was added in a reply to the wrong
message.
On Friday 16 January 2004 11:18 am, Steve Cohen wrote:
Well, we at commons-net would have been rushing the release to meet ant's
deadline and there are internal refactorings which we would have liked to
have included that we were planning to postpone in the rush, but now will
take the time to get right, so I doubt that commons-net-1.2.0 will be done
in time for ant 1.6.1 and therefore we shouldn't update the ant manual just
yet.
I think the best procedure will be for commons-net to work at it's own best
pace and when it's done, notify the ant list, via bugzilla and via posts to
the ant-dev and ant-user lists. At that point, any ant users needing this
functionality would be able to grab the commons-net-1.2.0 jar and get the
basic functionality. At that point also, coding could begin on the HEAD
branch of ant and the documentation in time for 1.7 (or maybe 1.6.2 if that
comes to pass).
On Friday 16 January 2004 9:31 am, Antoine Lévy-Lambert wrote:
Peter Reilly wrote:
Antoine Lévy-Lambert wrote:
I am +1 to get this into ant 1.6.1.
(in relation to static map of jarfile-manifest class path in
AntClassLoader2).
Ok I will commit that.
Another optimization I tried was a quick hack to DefBase to have a
static field containing the default classloader, so it
gets set once. This did speed up the typedef the second and
subsequent times and reduced the
time for the test to 1.6 second (from 3 and thus below the 1.5.4 times
(2 second) when using the crimson xml parser).
Sounds useful.
However it is a complete hack, and does not deal with non-default
classpaths like:
typedef classpath=${antlib.jar}
resource=net/sf/antcontrib/antcontrib.properties/
Do you mean : your change is bringing an optimization for taskdefs which
are done based on jars which have already been loaded by the launcher,
presumably because they are in $ANT_HOME/lib or in a -lib directory ?
And not if the taskdef is requiring extra jars or directories which were
not included when ant got started ?
Cheers,
Antoine
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant 1.6.1
Well, we at commons-net would have been rushing the release to meet ant's deadline and there are internal refactorings which we would have liked to have included that we were planning to postpone in the rush, but now will take the time to get right, so I doubt that commons-net-1.2.0 will be done in time for ant 1.6.1 and therefore we shouldn't update the ant manual just yet. I think the best procedure will be for commons-net to work at it's own best pace and when it's done, notify the ant list, via bugzilla and via posts to the ant-dev and ant-user lists. At that point, any ant users needing this functionality would be able to grab the commons-net-1.2.0 jar and get the basic functionality. At that point also, coding could begin on the HEAD branch of ant and the documentation in time for 1.7 (or maybe 1.6.2 if that comes to pass). On Friday 16 January 2004 10:28 am, Peter Reilly wrote: Steve Cohen wrote: On Friday 16 January 2004 4:56 am, Steve Loughran wrote: Steve Cohen wrote: Another issue to consider. I don't know if it's strictly a 1.6.1 issue or further down the line but the ant developers should consider it. I have been working with the jakarta-commons/net project to create a more capable system, able to detect what system its FTPClient class is connecting with. You may remember several complaints over the last couple of months about our ftp task not working on non-unix ftp servers. The improvements in commons/net will allow the correct server to be auto-detected in the most common cases, and in those odd cases where this is not possible, it will be possible to indicate explicitly which parser is to be used (i.e. in ant, a new parameter to the task). Thus it will be possible to rewrite our ftp task to solve these long standing problems. This version of commons-net (1.2.0) has not yet been released but can probably be released in less than a week. It seems from this thread that these changes will come too late for ant 1.6.1. Please correct me if that's wrong. Can someone tell me what plans, if any, are contemplated for ant 1.6.2? I'd prefer to target this as a 1.7 rework, as it would have side effects (specifically, need a newer version of commons.net) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To be honest, this is the response I was expecting, and it makes sense. In fact, without any changes to Ant, simply dropping in the 1.2.0 release of commons-net (when it's released) will gain the advantage of autodetection for Unix, Windows NT, OS/2 and VMS ftp systems. It is only for any outliers to this group that Ant would have to be recoded. Realizing this, I would say it's better to wait until 1.7 (but why not 1.6.2?) Since it does not involve any changes to ant, the only change would be a doc change in the manual ? Rewriting the ftp task would be a 1.7 activity. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant 1.6.1
Another issue to consider. I don't know if it's strictly a 1.6.1 issue or further down the line but the ant developers should consider it. I have been working with the jakarta-commons/net project to create a more capable system, able to detect what system its FTPClient class is connecting with. You may remember several complaints over the last couple of months about our ftp task not working on non-unix ftp servers. The improvements in commons/net will allow the correct server to be auto-detected in the most common cases, and in those odd cases where this is not possible, it will be possible to indicate explicitly which parser is to be used (i.e. in ant, a new parameter to the task). Thus it will be possible to rewrite our ftp task to solve these long standing problems. This version of commons-net (1.2.0) has not yet been released but can probably be released in less than a week. It seems from this thread that these changes will come too late for ant 1.6.1. Please correct me if that's wrong. Can someone tell me what plans, if any, are contemplated for ant 1.6.2? Steve Cohen On Thursday 15 January 2004 9:50 am, Antoine Lévy-Lambert wrote: Hi, do we want to make ant 1.6.1 next week ? I could release 1.6.1 on Thursday, Jan 22 in the evening (my usual 11pm to 12pm CET) do we need to make a beta before the release ? Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Jose Alberto Fernandez as committer
I have no vote, but if I did it would be +1. I was surprised to learn, a few weeks ago, that Jose was not a committer. -Original Message- From: Antoine Lévy-Lambert [mailto:[EMAIL PROTECTED] Sent: Friday, December 12, 2003 4:09 AM To: Ant Developers List Subject: [VOTE] Jose Alberto Fernandez as committer Hi, I would like to propose a vote for Jose Alberto Fernandez as new ant committer. Jose has expressed a lot of interest in ant, and had made a very interesting antlib proposal. His contributions to the discussions on the dev list are always interesting. Let me begin with my +1. Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: groovy and ant
At first I thought you were making a joke, but I now see that these are
serious people. More info on this language can be found at
http://wiki.codehaus.org/groovy/FrontPage
-Original Message-
From: Peter Reilly [mailto:[EMAIL PROTECTED]
Sent: Friday, December 12, 2003 9:54 AM
To: Ant Developers List
Subject: groovy and ant
Goovy is a new language. It looks like they have a nice
ant builder class:
ant = *new* AntBuilder()
/// lets just call one task
/ant.echo(*hello*)
/// heres an example of a block of Ant inside GroovyMarkup
/ant.sequential {
echo(*inside sequential*)
myDir = *target/AntTest/*
mkdir(dir:myDir)
copy(todir:myDir) {
fileset(dir:*src/test*) {
include(name:***/*.groovy*)
}
}
echo(*done*)
}
from:
http://cvs.groovy.codehaus.org/viewcvs.cgi/groovy/groovy-core/src/test/g
roovy/util/AntTest.groovy?rev=HEADview=auto
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: bug fixes!! WAS: ant 1.6beta3 released
There are improvements to commons-net over the old NetComponents to handle Windows FTP servers. However, the ant tasks would need to be recoded to take advantage of these. -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 09, 2003 1:48 AM To: [EMAIL PROTECTED] Subject: Re: bug fixes!! WAS: ant 1.6beta3 released On Mon, 8 Dec 2003, Filip Hanik [EMAIL PROTECTED] wrote: snip 3. FTP - I have a file parser for Windows FTP servers, modified the FTP task to take a parameter for which OS the FTP server is. Even better would be if it could auto detect. I'm not sure, maybe commons-net can already do that? I'd prefer to see fixes in that area to go upstreams so that all customers of commons-net can take advantage of them. snip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: bug fixes!! WAS: ant 1.6beta3 released
Yes, I wrote the changes to commons-net several months ago. NetComponents only had support for unix ftp systems, with some documentation about how to roll your own i.e. write your own implementations of their interface. Not very suitable for ant. One developer wrote some simple parsers and I enhanced these. You can find the different parsers in the package org.apache.commons.net.ftp.parser. However, be careful with the documentation, especially the documentation under the class org.apache.commons.net.ftp.parser.NTFTPEntryParser. The usage section there seems to be a bit out of date. There is more up to date documentation in the javadoc comment in the file org.apache.commons.net.ftp.FTPClient.java, under the method createFileList(FTPFileEntryParser parser). For some reason I do not understand, this usage information did not make it into the javadoc that is actually displayed on the commons-net javadoc site. Basically, as I see it, the ant task would be rewritten to allow specification of the system types. It would decode this attribute to allow a FTPFileEntryParser object to be instantiated, and then use that object as described in this documentation. Frankly, it would be a wonderful thing if the ant-user community found other types of FTP systems not supported or incorrectly supported in commons-net and then commons-net could be updated with even better support. I would be happy to volunteer for this task myself, except that at the moment I am about to be unemployed and may or may not have a job right away. If I do not, this might be a good way to spend my time in between interviews and pounding the pavement looking for work. If I get a new job soon, I may not have time. But at least I have moved my subscription to this list away from my work email address and will be able to follow the discussions from home. -Original Message- From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 09, 2003 9:21 AM To: Ant Developers List Subject: AW: bug fixes!! WAS: ant 1.6beta3 released Hi Steve, can you explain what needs to be done to take advantage of what commons-net is doing ? do we not get it automatically ? BTW I have tested the ftp task in ant1.6 against 3 sorts of ftp servers (GNU Inetutils, Hummingbird, FreeBSD). Not against a Microsoft ftp server. Cheers, Antoine -Ursprungliche Nachricht- Von: Steve Cohen [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 9. Dezember 2003 16:14 An: Ant Developers List Betreff: RE: bug fixes!! WAS: ant 1.6beta3 released There are improvements to commons-net over the old NetComponents to handle Windows FTP servers. However, the ant tasks would need to be recoded to take advantage of these. -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 09, 2003 1:48 AM To: [EMAIL PROTECTED] Subject: Re: bug fixes!! WAS: ant 1.6beta3 released On Mon, 8 Dec 2003, Filip Hanik [EMAIL PROTECTED] wrote: snip 3. FTP - I have a file parser for Windows FTP servers, modified the FTP task to take a parameter for which OS the FTP server is. Even better would be if it could auto detect. I'm not sure, maybe commons-net can already do that? I'd prefer to see fixes in that area to go upstreams so that all customers of commons-net can take advantage of them. snip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
test
test
RE: Ant 1.6 local and macrodef attributes
moving this discussion to ant dev list and including Jacob Kjome
Thanks, Jacob, for continuing to pursue this, and deepening my awareness of the
problem.
I appreciate your dilemma, even though I still agree with what has become
consensus that textual substitution is right for macrodef. The whole
business with the scope of properties is already complicated enough. The
local patch or something like it will be necessary to solve your use case.
But is local the right thing? Maybe we need to think more generally (not,
heaven forbid, for 1.6!!!) about tasks that return values in properties and how
these should be implemented in the context of macrodefs.
The key point is that when such a property was called inside of an antcall that
created a property locally within the execution context of the antcall call.
Textual substitution destroys that. A macrodef looks like a separate
execution context but is not, at least not as currently set up.
Since that is unlikely to be resolved in time for 1.6, can we suggest a
workaround for the interim?
I think we can. It's a bit ugly, but it does allow us to replace macrodefs
calling tasks that return properties, even without local. We just add one
level of indirection.
Instead of this:
macrodef name=A
attribute name=test.file/
sequential
available property=file.available value = yes file=@{test.file}/
property name=file.available value=no/
echoIs @{test.file} available? ${file.available}./echo
/sequential
/macrodef
...
A test.file=foo.bar/
...
A test.file=bar.food/
where the problem is that the property file.available cannot be redefined a
second time now because the macrodef lives outside of any target and this
property therefore resides on top level
we can instead do this:
macrodef name=A2
attribute name=test.file/
attribute name=available.prop/
sequential
available property=@{available.prop}
value = yes
file=@{test.file}/
property name=@{available.prop} value=no/
echoIs @{test.file} available? [EMAIL PROTECTED]/echo
/sequential
/macrodef
...
A2 test.file=foo.bar available.prop=foo.bar.available/
...
A2 test.file=bar.food available.prop=peanuts.available/
This is annoyingly less simple than local but still allows macrodef to be
used in 1.6 with tasks that return values in properties. I am assuming that
[EMAIL PROTECTED] would be handled correctly by textual expansion. Someone
please correct me if I'm wrong.
-Original Message-
From: Jacob Kjome [mailto:[EMAIL PROTECTED]
Sent: Fri 11/28/2003 6:39 PM
To: Ant Users List
Cc:
Subject:RE: Ant 1.6 local and macrodef attributes
Thanks for explaining that Peter.
I took a look and found your latest proposal here...
http://marc.theaimsgroup.com/?l=ant-devm=106993855725136w=2
Seems that Stefan liked it...
http://marc.theaimsgroup.com/?l=ant-devm=106994393230831w=2
So, I guess that means that proposal #1 below is going to be implemented
for Ant-1.6. However, does this still leave local properties out to
dry? I'm totally fine with using @{x} syntax for attributes, but macrodef
is still mostly useless to me unless I can do...
macrodef name=A
attribute name=test.file/
sequential
local name=file.available/ !-- this is the part that makes
this macrodef non-useless. --
available property=file.available value = yes
file=@{test.file}/
property name=file.available value=no/
echoIs @{test.file} available? ${file.available}./echo
/sequential
/macrodef
Jake
At 06:33 PM 11/27/2003 +, you wrote:
Hi Jacob,
Most of this discussion is on the dev listing.
I can understand your confusion.
A brief history.
(You can search with keyword local at
http://marc.theaimsgroup.com/?l=ant-devr=1w=2
to get the full gory details)
When macrodef was written originally, attributes
were (and are) implemented as textual substitution.
This was ok but they looked like normal properties
(using the ${x} notation). This caused a lot of
debate/confusion but I resisted changing the notation as I
do not like using different notation.
After using macrodefs for a little while I and other
people became aware that ant uses properties for
passing information between tasks and only having
non-mutable properties reduce the usefulness of
macrodefs a lot.
One can use ant-contrib's propertyregex and (via antelope)
var, and just overwrite properties - but this felt
like a big hack.
So one week-end I said what the heck and attempted to
implement local properties. It when through a number
of iterations.
When this was done, I realized that attributes could
be implemented by local properties and the problems
with notation would go away.
This interpretation of reality was not (to say the
least) universally accepted.
After the 1000'th e-mail explaining what was wrong
with this, I realized that there may be a point
in the argument.
So now there is two proposals:
1) to
RE: Macrodef attributes and Local revisited again
Peter -
but if macrodef properties are to be implemented as textual substitution
and not as local properties, the two issues can be separated.
Did you mean to say but if macrodef ATTRIBUTES are to be implemented as
textual substitution and not as local properties ...
Or are you talking about properties defined within the execution of a call to
a macrodef?
-Original Message-
From: Peter reilly [mailto:[EMAIL PROTECTED]
Sent: Thu 11/27/2003 7:08 AM
To: [EMAIL PROTECTED]
Cc:
Subject:Macrodef attributes and Local revisited again
Yesterday I said that macrodef attributes should be implemented as
properties and not as textual substitution.
On overnight reflection, I have changed by mind.
MacroDef has been using textual substitution in the ant beta
builds without much problems (*.. well not quite see below).
The only issue is the notation used is the same as for properties.
The proposed new notation is @{x} where x is the attribute.
I have implemented the new notation and added the following:
* the escape sequence @@{x} is used to allow @{x} to be
placed in the text without substitution of x. - this
corresponds to the $${x} escape sequence for properties.
* the macro replacement is now done on the default values for
the attributes - this allows Jan's use case to work:
target name=jan
macrodef name=dep
attribute name=root/
attribute name=file default=@{root}.dep/
sequential
script language=javascript ![CDATA[
// attribute expansion from macrodef (script cant reach the
// values)
root = @{root};
file = @{file};
importClass(java.lang.System);
System.out.println(
root is + root + and file is + file);
]]
/script
/sequential
/macrodef
dep root=foo/
/target
This prints out
jan:
[script] root is foo and file is foo.dep
The order of the attributes is important -
macrodef name=dep
attribute name=file default=@{root}.dep/
attribute name=root/
will set file to @{root}.dep.
A problem encountered in using macrodef for any not trivial macros
is the need to isolate the use of properties.
For this I have proposed using the local property patch, but if
macrodef properties are to be implemented as textual substitution
and not as local properties, the two issues can be separated.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Ant 1.6 local and macrodef attributes
Not a committer but my votes on Jose's ballots:
1) Vote on @{x} as the syntax for textual substitutions
of attributes in macrodef.
+1
2) Vote on local, must include decision on syntax,
scope (i.e., passing things on ant co., etc.)
I do not think all these have been settle.
0
-Original Message-
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
Sent: Wed 11/26/2003 6:15 AM
To: Ant Developers List
Cc:
Subject:RE: Ant 1.6 local and macrodef attributes
Here is my proposal for you guys to vote on.
Two completely separate votes:
1) Vote on @{x} as the syntax for textual substitutions
of attributes in macrodef.
Once this is settle, we can move on releasing macrodef
in B3 with its fixed syntax.
2) Vote on local, must include decision on syntax,
scope (i.e., passing things on ant co., etc.)
I do not think all these have been settle.
If (2) is resolved and acepted on 1.6, then Peter
gets most of what he wants, if not, then at least
we can release move on on the rest of ANT.
Jose Alberto
From: peter reilly [mailto:[EMAIL PROTECTED]
On Wednesday 26 November 2003 11:09, Stefan Bodewig wrote:
On Wed, 26 Nov 2003, peter reilly [EMAIL PROTECTED] wrote:
a)
I sent a vote last week on local properties
and the result was:
committers others (+ votes in
bugzilla)
have local in ant 1.6 2 1 + 6
not 0 0
+0 1 0
Based on this and other feedback I think that local does
belong in
ant 1.6.
I agree with your opinion (that locals should be there,
after all I'm
one of the two +1s), but disagree with the conclusion that this is
going to happen. 2 +1s is simply not enough to make a vote pass.
I'm not trying to argue from a procedural standpoint but
merely from
the fact that a change like this needs community support - and it
doesn't seem to have it.
Well as least not Yet..
b)
I send an vote the week before about local properties being
s/local properties/macrodef attributes/
Opps..
implemented by textual replacement or by using local
properties. The
result was:
committers others
local properties2 1
textual replacement 1 4
+0 1 0
I would like to implement attributes using local properties,
-0.8
Ok, The reason (as I said before) I do not like textual subs
is the use of a different notation.., but I can live with it
if other people think it is a good thing,
most if not all things that could be done when we implement the
attributes as local properties are possible with textual expansion.
Textual expansion enables things that local properties don't.
This is true.
I propose to commit local properties and implement
attributes using
local properties for the ant 1.6 beta3 release.
-1 on both. Both parts lack committer support. We could try to
revote or something.
Indeed.
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: macrodef - do attributes as properties or substitutions
True, that was from the 1.4/1.5 days. -Original Message- From: Dominique Devienne [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 8:52 AM To: 'Ant Developers List' Subject: RE: macrodef - do attributes as properties or substitutions From: Steve Cohen [mailto:[EMAIL PROTECTED] I have used a similar idea with a build file full of template targets that use a fileset reference. The reference must be defined globally or the build will break, but only some of the users of the file of templates actually need the reference. So, since references can be overridden, the solution is, similar to Stefan's, fileset id=globaltlds dir=. include name=no.real.file/ /fileset Later, a user of this buildfile can redefine the globaltlds reference, if it needs to, to something real. Yeah, this sounds a lot like the Null Object idiom you can read about in Martin Fowler's Refactoring book. OTOH, now that there is the isreference condition, a cleaner approach might be to conditionaly execute the target only of the reference is defined at all, rather than defining a null/dummy one. Probably not applicable all the time, but still. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: macrodef - do attributes as properties or substitutions
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 18, 2003 2:06 AM
To: [EMAIL PROTECTED]
Subject: RE: macrodef - do attributes as properties or substitutions
macrodef name=macro
attribute name=one/
attribute name=two default=${one}/
/macrodef
macro one=hello/
I don't think we should need any special cludges just to support this
usecase. 8-)
Give two a completely bogus, impossible to be used in any real world
usage value and check for that. Should be easier than comparing it to
a literal ${one} or @one or whathever.
macrodef name=macro
attribute name=one/
attribute name=two
default=nobody-with-a-sane-mind-would-ever-want-to-use-this-value/
/macrodef
Nice idea - usually such nice words don´t come into my mind when I´m
programming :-) But the string comparison would be easier.
Jan
I have used a similar idea with a build file full of template targets that
use a fileset reference. The reference must be defined globally or the build
will break, but only some of the users of the file of templates actually need
the reference. So, since references can be overridden, the solution is,
similar to Stefan's,
fileset id=globaltlds dir=.
include name=no.real.file/
/fileset
Later, a user of this buildfile can redefine the globaltlds reference, if it
needs to, to something real.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] macrodef - do attributes as properties or substitutions
What about {$x}? Or is it too close to a typo for a regular property?
way too confusing, IMHO. And departs significant from our pattern
which seems to be
identifier type marker, open curly brace, identifier, close curly brace
The more I look at this, the clearer my clear choice becomes for @{x}.
It maintains the ant pattern of identifier naming while being quite
significantly different in an important way so that visual confusion
will be unlikely, even when the script writer is tired :-)
-Original Message-
From: Shatzer, Larry [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 18, 2003 10:09 AM
To: 'Ant Developers List'
Subject: RE: [VOTE] macrodef - do attributes as properties or
substitutions
-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 18, 2003 2:08 AM
To: [EMAIL PROTECTED]
Subject: Re: [VOTE] macrodef - do attributes as properties or
substitutions
[ ] as $(x)
[ ] as @{x}
either one works for me - as well as [EMAIL PROTECTED]
What about {$x}? Or is it too close to a typo for a regular property?
-- Larry
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] macrodef - do attributes as properties or substitutions
Another non committer here.
I don't like $(x) because it looks too much like ${x}, although I
suppose I could get used to that. Therfore, I am drawn to
@{x}. ${attribute:x} is possible but way too much typing for my taste.
Abbreviated to ${att:x} or ${attrib:x} my negativity level goes down
accordingly.
Before voting, though, could someone list all the conflicting usages
with other systems that ant must interface with.
-Original Message-
From: peter reilly [mailto:[EMAIL PROTECTED]
Sent: Monday, November 17, 2003 12:10 PM
To: Ant Developers List
Subject: Re: [VOTE] macrodef - do attributes as properties or
substitutions
OK, how do we want to implement macrodef attributes:
current
[ ] as textual substitution~ 4
[ ] as real Ant properties ~ 2
undecided ~ 1
If macrodef attribute are to be implements as substitutions, what should
be the notation? (where x is the attribute name)
[ ] as ${x} (look like ant properties)
[ ] as $(x)
[ ] as @x
[ ] as ${attribute:x}
[ ] as @{x}
[ ] some thing else
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: macrodef - do attributes as properties or substitutions
I want macrodef for when all I need to do is to put toguether
a group of calls to other tasks in a sequence, which could be
quite complex, but it does not require any additional computation
from my part
Hear, hear!
Used in this way, you can use ant, cutting out expensive antcall calls and
most taskdef's. I myself have never written a taskdef and don't want to
start unless I really have to do something specialized. taskdef's and what
they do are a mystery to readers of a build script and IMHO should not be used
just to glue targets together in some particular way unless there is a very
good reason for it.
That's what I want from macrodef.
-Original Message-
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 12:37 PM
To: Ant Developers List
Subject: RE: macrodef - do attributes as properties or substitutions
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
On Tue, 11 Nov 2003, Jose Alberto Fernandez
To me macrodefs are for writing all those tasks that I am
too lazy, or
they are too simple for me to need to go and write and
maintain some
Java code.
I'm not sure that this is the intention of macrodef - maybe
you would rather use scriptdef with beanshell as your
scripting language then?
I do use it extensively. And believe me, every time we have a
syntax or logical error in the code it takes 1o times longer
to find it. Line numbers never match with that of the srcfiles.
But back to the topic.
I want macrodef for when all I need to do is to put toguether
a group of calls to other tasks in a sequence, which could be
quite complex, but it does not require any additional computation
from my part:
macrodef name=preferential-copy
attribute name=app-pref.name/
attribute name=app-pref.dir/
sequential
mkdir dir=${app-prefs.dir}/
dependset
srcfileset dir=${basedir}
include name=${app-prefs.name}/**/
include name=${containers.dir}/${app-prefs.name}/**/
include name=${descriptor.dir.app}/${app-prefs.name}/**/
include
name=${descriptor.container.dir.app}/${app-prefs.name}/**/
/srcfileset
targetfileset dir=${app-prefs.dir}/
/dependset
if
available file='${descriptor.container.dir.app}/${app-prefs.name}'
type=dir/
then
copy todir='${app-prefs.dir}'
fileset dir=${descriptor.container.dir.app}/${app-prefs.name}
includes=**/
/copy
/then
/if
if
available file='${descriptor.dir.app}/${app-prefs.name}' type=dir/
then
copy todir='${app-prefs.dir}'
fileset dir=${descriptor.dir.app}/${app-prefs.name}
includes=**/
/copy
/then
/if
if
available file='${containers.dir}/${app-prefs.name}' type=dir/
then
copy todir='${app-prefs.dir}'
fileset dir=${containers.dir}/${app-prefs.name} includes=**/
/copy
/then
/if
if
available file='${app-prefs.name}' type=dir/
then
copy todir='${app-prefs.dir}'
fileset dir=${app-prefs.name} includes=**/
/copy
/then
/if
/sequential
/macrodef
Today, I need to do this by calling antcall because I need to pass diferent
parameters in different places. It will look much better that instead of:
antcall target=prefs.app
param name=app-prefs.name value=war-res/
param name=app-prefs.dir value=${war-res.app}/
/antcall
I can just say:
preferential-copy app-prefs.name=war-res
app-prefs.dir=${war-res.app}/
You can see that using scriptdef to do this job is absolute madness. Since all
you need is
to put toguether some tasks.
Substitution is the least interfearing behavior.
I hear you and to a certain degree I agree with you.
Actually I haven't really made up my mind myself yet - no
vote from me so far.
But if atributes modify properties, then there is no way
for me to
stop them for happening.
In which situation would atributes modify properties have
negative effects on what you are planing to do with
macrodef? Do you have an enlightening example?
macrodef name=myMacro
attribute name=debug/
element name=code/
sequential
if
istrue value=${debug}
then
echomyMacro: Entering my macro/echo
code/
echomyMacro: Entering my macro/echo
/then
else
code/
/else
/if
/sequential
/macrodef
So here we have this simple macro that adds some debug information.
So I use it like:
myMacro debug=true
code
my.javac srcdir=test/src .../
/code
/myMacro
Still, very naïve code. Until you see that the definition of my.java is:
presetdef name=my.javac
javac srcdir=src destdir=classes deprecation=${deprecation}
debug=${debug}/
/presetdef
No here the intention of the code writer was to control javac using the
debug property. But just
RE: [VOTE] macrodef - do attributes as properties or substitutions
I don't have a vote but if I did, I'd be [X] as textual substitution [ ] as real Ant properties -Original Message- From: Dominique Devienne [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 11, 2003 10:14 AM To: 'Ant Developers List' Subject: RE: [VOTE] macrodef - do attributes as properties or substitutions From: Stefan Bodewig [mailto:[EMAIL PROTECTED] OK, how do we want to implement macrodef attributes: [X] as textual substitution [ ] as real Ant properties - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: macrodef attributes as properties or as textual substitutions [was local]
This makes a lot of sense to me, especially given your willingness to
consider a different notation (very important, IMHO). To me, a macro IS
a textual substitution, and anything that leaves things in an undefined
or difficult-to-explain middle state is asking for trouble. They're
different sorts of beasts and this should not be muddied.
Steve Cohen
Sr. Software Engineer
Sportvision, Inc.
scohenATSportvisionDOTcom
-Original Message-
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 05, 2003 10:30 AM
To: Ant Developers List
Subject: RE: macrodef attributes as properties or as textual
substitutions [was local]
Sorry to have taken so long for me to answer this message but I am
quite busy at work and haven't had the time.
I would like to give some of my perspective on the issue of macrodef/
and local/.
My first comment is that I really believe these two features should be
kept apart. I do not think macrodef/ should use local in the
implementation of atribute. I am in the camp of macrodef doing a
textual expansions (and here I would relent my objections to
a different syntax for attribute variables, in exchange for having
textual replacement done right).
By textual replacement done right, I mean that the scope of the textual
replacement is static on the text of the macro at the time of
definition. That is the replacement should not apply to the value of
attributes or elements passed in the call. So in the famous example:
macrodef name=inner
attribute name=a/
attribute name=b/
sequential
echo name=a value=$(a)/echo
echo name=b value=$(b)/echo
/sequential
/macrodef
macrodef name=outer
attribute name=work/
attribute name=play/
element name=precompile optional=true/
element name=additional optional=true/
sequential
precompile/
additional/
/sequential
/macrodef
target name=test.outer
outer work=this is work play=this is play
precompile
inner a=${work} b=${play} /
/precompile
/outer
/target
The output will still be:
test.outer:
[echo] name=a value=${work}
[echo] name=b value=${play}
More over, the following call (see usage of attribute notation):
target name=test.outer
outer work=this is work play=this is play
precompile
inner a=$(work) b=$(play) /
/precompile
/outer
/target
Will also output:
test.outer:
[echo] name=a value=$(work)
[echo] name=b value=$(play)
Because the substitutions of $(work)/$(play) attributes MUST occur
before the expansion of precompile/.
Why am I so adamant about it? Because I believe a user of a macro should
be isolated from the implementation of the task sa macro. I should be
able to reimplement a macrodef as a java task and maintain complete
compatibility. This means that macros, like tasks, must set properties
or references to pass information between them. I shouldn't be able to
do with a macro something that cannot be done cleanly with a task.
Now, with respect to local. The way I originally envisioned local
was very similar params of ant. They redefine (overide) the value of
a property for a well defined period of time (the local nesting) and
after that the property reverts to its original value (state). Very
simple. Since then there has been added functionality for multithreading
which I think has made local a little too complex for my taste.
I think we should try to simplify this feature so it touches core the
least possible. Today I think the implementation touches a lot of places
of core, that should be reduced to just a few (making local a subtask
of sequential would help on some of that simplification).
Will stop here now I here your comments,
Jose Alberto
-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Sent: 03 November 2003 14:08
To: [EMAIL PROTECTED]
Subject: Re: macrodef attributes as properties or as
textual substitutions [was local]
On Fri, 31 Oct 2003, Antoine Levy-Lambert [EMAIL PROTECTED]
wrote:
What are the advantages of leaving macrodef with attributes
implemented as textual substitutions ?
attributes don't hide properties.
If we implement attributes as properties, we have to decide
whether they are allowed to override existing
(user-)properties of the same name as well. I don't think it
would be problematic, as long as we state the rules clear enough.
If they are only textual substitutions, they get confusing
when we use the property expansion syntax.
Otherwise, of course, if we leave macrodef as it is with just a new
notation for the attributes, then we can release 1.6 sooner.
I'd rather get this right as in community supported and
unlikely to break bc in Ant 1.7 now.
If we choose a notation $() for macro attributes (for
instance), can
we implement macrodef with local/ in 1.7 ?
You mean we make them textual
RE: macrodef attributes as properties or as textual substitutions [was local]
Doing this corresponds more closely to current usage of antcall/ for
templates.
Yes, but I think this may not be such a good thing. I have, as I
recall, oftentimes been tripped up on the question of when a variable is
defined. I know java has no preprocessor, but it doesn't have macros
either. If we are going to introduce macros in ant, I think that the
clarity of knowing that they are defined at load time, and not at
runtime is an advantage. antcall
has never been a good way to do templates.
Although I might be open to a convincing counter-example.
Steve Cohen
Sr. Software Engineer
Sportvision, Inc.
scohenATSportvisionDOTcom
-Original Message-
From: peter reilly [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 05, 2003 11:38 AM
To: Ant Developers List
Subject: Re: macrodef attributes as properties or as textual
substitutions [was local]
My view is that we should use (local) properties for macrodef
attributes. Doing this corresponds more closely to current usage of
antcall/ for templates.
If however, one uses textual substitutions, I agree that one should use
a different syntax/notation for the attributes.
$(x) may however be too similar to ${x}
As regards local/. I think that the local properties should be thread
local. I.e. the following should not cause grief.
parallel
sequential
local name=x value=1/
echox is ${x}/echo
/sequential
sequential
local name=x value=2/
echox is ${x}/echo
/sequential
/parallel
Peter
On Wednesday 05 November 2003 16:30, Jose Alberto Fernandez wrote:
Sorry to have taken so long for me to answer this message but I am
quite busy at work and haven't had the time.
I would like to give some of my perspective on the issue of
macrodef/ and local/.
My first comment is that I really believe these two features should be
kept apart. I do not think macrodef/ should use local in the
implementation of atribute. I am in the camp of macrodef doing a
textual expansions (and here I would relent my objections to a
different syntax for attribute variables, in exchange for having
textual replacement done right).
By textual replacement done right, I mean that the scope of the
textual replacement is static on the text of the macro at the time of
definition. That is the replacement should not apply to the value of
attributes or
elements passed in the call. So in the famous example:
macrodef name=inner
attribute name=a/
attribute name=b/
sequential
echo name=a value=$(a)/echo
echo name=b value=$(b)/echo
/sequential
/macrodef
macrodef name=outer
attribute name=work/
attribute name=play/
element name=precompile optional=true/
element name=additional optional=true/
sequential
precompile/
additional/
/sequential
/macrodef
target name=test.outer
outer work=this is work play=this is play
precompile
inner a=${work} b=${play} /
/precompile
/outer
/target
The output will still be:
test.outer:
[echo] name=a value=${work}
[echo] name=b value=${play}
More over, the following call (see usage of attribute notation):
target name=test.outer
outer work=this is work play=this is play
precompile
inner a=$(work) b=$(play) /
/precompile
/outer
/target
Will also output:
test.outer:
[echo] name=a value=$(work)
[echo] name=b value=$(play)
Because the substitutions of $(work)/$(play) attributes MUST occur
before the expansion of precompile/.
Why am I so adamant about it? Because I believe a user of a macro
should be isolated from the implementation of the task sa macro. I
should be able to reimplement a macrodef as a java task and
maintain complete compatibility. This means that macros, like tasks,
must set properties or references to pass information between them.
I shouldn't be able to do with a macro something that cannot be done
cleanly with a task.
Now, with respect to local. The way I originally envisioned local
was very similar params of ant. They redefine (overide) the value
of a property for a well defined period of time (the local nesting)
and after that the property reverts to its original value (state).
Very simple. Since then there has been added functionality for
multithreading which I think has made local a little too complex for
my taste.
I think we should try to simplify this feature so it touches core the
least possible. Today I think the implementation touches a lot of
places of core, that should be reduced to just a few (making local a
subtask of sequential would help on some of that simplification).
Will stop here now I here your comments,
Jose Alberto
-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Sent: 03 November 2003 14:08
To: [EMAIL PROTECTED]
Subject: Re: macrodef attributes
RE: MARC - spam enabler
All right, Stefan, I'll stop worrying about it. I hadn't thought that spammers would subscribe to these lists just to harvest addresses, but that's obviously possible too. -Original Message- From: Stefan Bodewig Sent: Monday, November 03, 2003 2:17 AM To: [EMAIL PROTECTED] Subject: Re: MARC - spam enabler On Fri, 31 Oct 2003, Steve Cohen wrote: Can't MARC be fixed to munge email addresses? Even if it could, it wouldn't help you. but whenever I am replied to, my full unmunged email address gets published in MARC. I've just removed your email address from the attribution my MUA generates. 8-) Marc is by far not the only way a spammer can get at your address you use for posting here. Eyebrowse is another option, as are our mbox archives. It's even quite easy to subscribe an address collecting bot to the list. I am sick of seeing my postings to these lists turn into spam cannons pointed back at myself. There is no way to avoid that, all you can do is to use smart spam detection software on your side, sorry. Spammers will get your address if you use it on public lists and no address munging will stop them from doing so. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: macrodef attributes as properties or as textual substitutions [was local]
From my point of view, I am sitting with a massive, slow, and messy build script that I would love to convert to using macrodefs instead of antcalls. I am waiting for this to be resolved before proceeding. On the other hand, I can live with what I have for awhile. Some preliminary experiences have indicated problems which I shared with the dev list earlier this week. I imagine that whatever scheme is chosen will require some sizable effort to convert. I would rather not do this in 1.6 and then again in 1.7, unless the conversion path is easy. What I don't understand in Antoine's question is whether the new notation would have to be scrapped for the new implementation of local in 1.7 or whether it would still apply. Unless this is going to delay the release for months, I would say, get it right, now. Steve Cohen Sr. Software Engineer Sportvision, Inc. scohenATSportvisionDOTcom -Original Message- From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED] Sent: Friday, October 31, 2003 10:31 AM To: Ant Developers List Subject: macrodef attributes as properties or as textual substitutions [was local] Here is a new subject. What are the advantages of leaving macrodef with attributes implemented as textual substitutions ? My impression is that the local properties are more powerful. Otherwise, of course, if we leave macrodef as it is with just a new notation for the attributes, then we can release 1.6 sooner. If we choose a notation $() for macro attributes (for instance), can we implement macrodef with local/ in 1.7 ? or will we have a problem of backward compatibility in any case ? Cheers, Antoine -Ursprungliche Nachricht- Von: Stefan Bodewig [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 31. Oktober 2003 17:13 An: [EMAIL PROTECTED] Betreff: Re: local On Fri, 31 Oct 2003, peter reilly [EMAIL PROTECTED] wrote: On Friday 31 October 2003 15:55, Stefan Bodewig wrote: On Fri, 31 Oct 2003, peter reilly [EMAIL PROTECTED] wrote: No, it matters if the attributes in macrodef are implemented as properties or if they are implemented as textual subsitutions. OK, but then this becomes the question to decide and not whether we need local in 1.6, right? Yes Do we need a different thread to get a wider audience? If they are properties, we don't need an alternative. What are the difficulties you expect when they are not properties? Only the choice of the notation. MSBuild uses $() for its properties and @() for something else - probably Item references at first glance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
MARC - spam enabler
Can't MARC be fixed to munge email addresses? I notice that everything I post has my email address munged up pretty good in MARC, but whenever I am replied to, my full unmunged email address gets published in MARC. I am sick of seeing my postings to these lists turn into spam cannons pointed back at myself. I just got rid of one email address, and soon I'll be forced to do so again. Can nothing be done about this? Steve Cohen Sr. Software Engineer Sportvision, Inc. scohenATSportvisionDOTcom
RE: Tale from the front: macrodef nesting
You're correct about working around this problem. However, I think it's
still a problem that the same
${identifier} notation can either indicate a macrodef attribute or an
ant property with completely different times of resolution.
In other words, the line of warning in the ant manual --
This attribute is placed in the body of the templated task using the
ant property notation - ${attribute name}. Note that is not an actual
ant property
--will certainly confuse users and may therefore indicate a problem in
design.
-Original Message-
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
Sent: Monday, October 27, 2003 5:37 AM
To: Ant Developers List
Subject: RE: Tale from the front: macrodef nesting
From: Steve Cohen [mailto:[EMAIL PROTECTED]
I am now trying to experiment with some of the new features
of ant 1.6. Here's a real-world example of the difficulties
of trying to replace antcalls with macrodefs.
Given the following definitions, notice that I am trying to
nest a call to the macrodef make.precompiled.web.xml inside a
call to the macrodef make.se.war.
This is failing because I am trying to use the ATTRIBUTE
war.webxml inside the ELEMENT precompile which contains a
call to the nested macrodef make.precompiled.web.xml.
The issue is not that you are calling make.precompile.web.xml,
the issue is that you are using ${war.webxml} at a point where
there is no property (nor attribute) called war.webxml defined.
If you look at your target make.admin.war there is no property
or defined called war.webxml at that point, so you cannot just
look inside the task implementation and assume that it may exist
be the time is half way executing (that is too late, you need it
at the point of the call to make.se.war.
I could easily fix this by substituting the actual value of
the war.webxml attribute for the ${war.webxml} token. But
then I lose the advantage of defining this in a single place.
Or I can create properties in the macrodef and pass them
around, but that feels wrong too.
What you should do is define this in a property on the target
and they use that property to expand the value in all the
places that is needed.
Maybe there should be some mechanism for allowing inner
macrodefs for inheriting attributes from an outer macrodef.
Maybe elements should be able to be defined with nested
attributes. Or something.
This will not solve your problem. Your problem is that you
are using ${war.webxml} on target make.admin.war and there
is no property defined at that point in time.
Jose Alberto
But this experience with trying to use this feature leads me
to the feeling that using the same notation for macrodef
attributes and ant properties is not a good thing. It will
definitely cause confusion. At a minimum more documentation
of this is required.
macrodef name=make.precompiled.web.xml
attribute name=src.web.xml/
attribute name=dest.web.xml/
sequential
ant antfile=${basedir}/se/build-precomp.xml
target=create.precompiled.web.xml
property name=src.web.xml value=${src.web.xml}/
property name=dest.web.xml
value=${dest.web.xml}/
/ant
/sequential
/macrodef
macrodef name=make.se.war
attribute name=work.dir/
attribute name=war.webxml/
attribute name=war.basedir/
attribute name=war.destfile/
element name=precompile optional=true/
element name=assemble optional=false/
element name=additional optional=true/
sequential
delete dir=${work.dir}/
mkdir dir=${work.dir}/temp/
mkdir dir=${work.dir}/war/
precompile/
assemble/
replace file=${war.webxml}
token=#build#
value=${project.version}.${project.maintenance.build}.${proje
ct.fix.build}/
war destfile=${war.destfile}
webxml=${war.webxml}
basedir=${war.basedir}
additional/
/war
/sequential
/macrodef
target name=make.admin.war
depends=make.precompilation
make.se.war
work.dir=${dir.admin.ear}
war.webxml=${dir.build.precomp.webxml}/${admin.web.xml}
war.basedir=${dir.admin.ear}/temp
war.destfile=${dir.admin.ear}/war/${admin.war}
precompile
make.precompiled.web.xml
src.web.xml=${dir.src.web.xmls}/${admin.web.xml}
dest.web.xml=${war.webxml}
/
/precompile
assemble
copy todir=${war.basedir}
fileset dir
RE: Tale from the front: macrodef nesting
Sorry to say I wasn't involved in the discussion at that time. What
were the arguments against using an alternative notation?
-Original Message-
From: Dominique Devienne [mailto:[EMAIL PROTECTED]
Sent: Monday, October 27, 2003 9:33 AM
To: 'Ant Developers List'
Subject: RE: Tale from the front: macrodef nesting
From: Steve Cohen [mailto:[EMAIL PROTECTED]
You're correct about working around this problem. However, I think
it's still a problem that the same ${identifier} notation can either
indicate a macrodef attribute or an ant property with completely
different times of resolution.
In other words, the line of warning in the ant manual --
This attribute is placed in the body of the templated task using the
ant property notation - ${attribute name}. Note that is not an actual
ant property
--will certainly confuse users and may therefore indicate a problem in
design.
I argued long and hard on Ant-dev against this overloading of the
meaning of ${name}, to no avail. Glad to see I'm not alone in this
thinking. But then again, macrodef's subtleties might just be showing
the limits of my own abilities to grasp context-dependent behavior, when
sharper people apparently have no such limitations. --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Tale from the front: macrodef nesting
I am now trying to experiment with some of the new features of ant 1.6. Here's
a real-world example of the difficulties of trying to replace antcalls with
macrodefs.
Given the following definitions, notice that I am trying to nest a call to the
macrodef make.precompiled.web.xml inside a call to the macrodef make.se.war.
This is failing because I am trying to use the ATTRIBUTE war.webxml inside the
ELEMENT precompile which contains a call to the nested macrodef
make.precompiled.web.xml.
I could easily fix this by substituting the actual value of the war.webxml
attribute for the ${war.webxml} token. But then I lose the advantage of
defining this in a single place.
Or I can create properties in the macrodef and pass them around, but that feels
wrong too.
Maybe there should be some mechanism for allowing inner macrodefs for
inheriting attributes from an outer macrodef. Maybe elements should be able to
be defined with nested attributes. Or something.
But this experience with trying to use this feature leads me to the feeling
that using the same notation for macrodef attributes and ant properties is not
a good thing. It will definitely cause confusion. At a minimum more
documentation of this is required.
macrodef name=make.precompiled.web.xml
attribute name=src.web.xml/
attribute name=dest.web.xml/
sequential
ant antfile=${basedir}/se/build-precomp.xml
target=create.precompiled.web.xml
property name=src.web.xml value=${src.web.xml}/
property name=dest.web.xml value=${dest.web.xml}/
/ant
/sequential
/macrodef
macrodef name=make.se.war
attribute name=work.dir/
attribute name=war.webxml/
attribute name=war.basedir/
attribute name=war.destfile/
element name=precompile optional=true/
element name=assemble optional=false/
element name=additional optional=true/
sequential
delete dir=${work.dir}/
mkdir dir=${work.dir}/temp/
mkdir dir=${work.dir}/war/
precompile/
assemble/
replace file=${war.webxml}
token=#build#
value=${project.version}.${project.maintenance.build}.${project.fix.build}/
war destfile=${war.destfile}
webxml=${war.webxml}
basedir=${war.basedir}
additional/
/war
/sequential
/macrodef
target name=make.admin.war
depends=make.precompilation
make.se.war
work.dir=${dir.admin.ear}
war.webxml=${dir.build.precomp.webxml}/${admin.web.xml}
war.basedir=${dir.admin.ear}/temp
war.destfile=${dir.admin.ear}/war/${admin.war}
precompile
make.precompiled.web.xml
src.web.xml=${dir.src.web.xmls}/${admin.web.xml}
dest.web.xml=${war.webxml}
/
/precompile
assemble
copy todir=${war.basedir}
fileset dir=${dir.build.war.precomp}/
/copy
/assemble
/make.se.war
/target
RE: Question about MacroDef vs antcall
Thanks for the information on depends vs. antcall. My suspicion has been that antcall was a major cause of delay. Unnecessary operations are another area of optimization potential. -Original Message- From: Conor MacNeill [mailto:[EMAIL PROTECTED] Sent: Sun 10/26/2003 4:21 PM To: Ant Developers List Cc: Subject:Re: Question about MacroDef vs antcall On Sun, 26 Oct 2003 03:18 am, Steve Cohen wrote: The new ant features wiki http://nagoya.apache.org/wiki/apachewiki.cgi?NewAntFeaturesInDetail/MacroDe f says: If you are using antcall as a macro substitute, you really should look into this task. It is not only going to simplify your build files but also speed up your builds considerably as you skip the huge overhead connected with antcall. Re: the huge overhead connected with antcall: Does this also apply to calls made to other tasks via depends? No, there is no overhead associated with depends because it operates within the same context as the depending target. An antcall sets up a whole new context in which to exectue the targets tasks. This also includes re-parsing the XML and re-building the in-memory structure of the build file. And if so, is a macrodef callable via depends? (I don't see how.) No. depends does not really mean callable. The depends attribute is used to describe the dependency structure of your build. That causes Ant to execute those targets to satisfy the dependencies. It is a relationship between targets - i.e. the large scale things that happen within your build. Tasks, including those defined by macrodef are about the small, detail-level things that need to happen in your build. Does ant 1.6 offer a way around this problem, or is there perhaps another way in ant 1.5 even? My general feeling on ant scripts up to now has been, you can write an excellent quick and dirty script pretty easily or you can write a complicated system of build scripts, but it's very hard to make one script that serves both goals. I would probably need more info to understand your build system to see why it may be taking time. Are there custom tasks? What operations are being invoked which may not be necessary. Can uptodate be used to avoid sub-builds? etc. If you can use macrodef in place of antcall, you should save some time. OTOH, if the build invokes operations that take time and which need to be done, according to timestamps, etc, then you may be limited in what you can do. You can potentially save time by accepting some out-of-date components. This can be OK in dev situation and may be what your quick and dirty scripts are doing. Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Question about MacroDef vs antcall
The new ant features wiki http://nagoya.apache.org/wiki/apachewiki.cgi?NewAntFeaturesInDetail/MacroDef says: If you are using antcall as a macro substitute, you really should look into this task. It is not only going to simplify your build files but also speed up your builds considerably as you skip the huge overhead connected with antcall. Re: the huge overhead connected with antcall: Does this also apply to calls made to other tasks via depends? And if so, is a macrodef callable via depends? (I don't see how.) Here's where I am going with this. I am working on a large project that is built up from smaller projects. Most of the smaller projects are usually (but not always) untouched, but they are touched just often enough that it is important for the master build to always build them. However, most of the developers working on the project find the added delay of using the master script intolerable, even if they run a subsidiary target that does not rebuild everything. Their quick and dirty script is much faster. I am trying to wring extra performance out of the master script so that the delays in using its subsidiary targets will not be intolerable. But if many targets must depend on an assess target that tests whether the build is in lite mode and use that in an unless clause to avoid doing something, if these calls are outrageously expensive, the gain from this sort of thing will be small. Does ant 1.6 offer a way around this problem, or is there perhaps another way in ant 1.5 even? My general feeling on ant scripts up to now has been, you can write an excellent quick and dirty script pretty easily or you can write a complicated system of build scripts, but it's very hard to make one script that serves both goals.
RE: Starteam connect/disconnect
Hmm, I have never noticed this. While what you say certainly sounds
logical (clean up after yourself, basically, as you must do with
database connections, etc.) I have never experienced it myself. I can
certainly take a look at putting connection-closing logic into these
tasks, especially as the connection is not reused between task
invocations.
What client and server environments are you doing this in?
Steve Cohen
Sr. Software Engineer
Sportvision, Inc.
scohenATSportvisionDOTcom
-Original Message-
From: Ross Gibb [mailto:[EMAIL PROTECTED]
Sent: Friday, October 24, 2003 7:54 AM
To: [EMAIL PROTECTED]
Subject: Starteam connect/disconnect
Hi,
I am using ANT with Starteam and having some troubles. Right now my
build script makes around 30 separate calls to Starteam targets
(stcheckout, stlabel exclusively). When the build is finished Starteam
seems to get into a weird state where everything is extremely slow (i.e.
using the Starteam gui to checkin or checkout code is really slow). The
slowness eventually goes away, some sort of timeout I am guessing. I
tried to help myself and started poking around the ANT source code to
see how the Starteam API is used. I think I found the call to the
Starteam API that connects to the server, it is:
In class org.apache.tools.ant.taskdefs.optional.starteam.StarTeamTask
The function is:
/**
* All subclasses will call on this method to open the view needed
for
* processing. This method also saves a reference to the
* codeServer/code that may be accessed for information at
various
* points in the process.
*
* @return the codeView/code that will be used for processing.
* @see #createSnapshotView(View)
* @see #getServer()
*/
protected View openView() throws BuildException {
logStarteamVersion();
View view = null;
try {
view = StarTeamFinder.openView(getViewURL());
} catch (Exception e) {
throw new BuildException(
Failed to connect to + getURL(), e);
}
if (null == view) {
throw new BuildException(Cannot find view + getURL() +
in repository());
}
View snapshot = createSnapshotView(view);
this.server = snapshot.getServer();
return snapshot;
}
You can see from the comments that this code returns a Starteam view
(and keeps a connection to the server) to the caller. My question is,
does this connection have to be closed after you are finished using
it I have found no code in the ANT source that actually disconnects
( if there is some please point me to it). I have been in contact with
the Borland support who claim there is disconnect method that can be
called to disconnect from the server (I am not sure it applies in this
case). I have requested the Starteam API docs from Borland but they
seem to be ignoring me. Hoping someone here would know.
Ross
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Starteam connect/disconnect
OK, thanks, Ross. Please file a bugzilla report on this issue and I promise I'll handle it. Please append this email thread as an attachment to the bug report. I will put connection closing logic into each ant call. Without looking closely into it, I can see no reason not to as it's just basic connection hygiene. I won't be able to test whether it solves your problem, but you can be the arbiter of that. Fair enough? Steve Cohen Sr. Software Engineer Sportvision, Inc. scohenATSportvisionDOTcom -Original Message- From: Ross Gibb [mailto:[EMAIL PROTECTED] Sent: Friday, October 24, 2003 9:43 AM To: Ant Developers List Subject: RE: Starteam connect/disconnect Hi, The Starteam server exists on a Windows 2000 box using Microsoft Access as the database, 1 Gig of memory, 2GHz processor. Before you role your eyes and tell me to start using a real database understand that at the time it was all I could afford. Furthermore, I have asked Borland specifically whether my server configuration and the number of users I support would put load on the server slowing it down, they responded that everything should work with good performance. Also, when I have been experiencing slow performance I have gone to my server to see if the processor is maxed out or it is short of memory, each time the server has been fine. As far as running the ANT scripts, I have been using both Windows and Solaris with various graphical front ends (Antelope, and through Eclipse). When I started having these problems I have switched to ANT command line in hopes it was a problem with one of the GUI tools. Even ANT command line produces this problem. The exact actions that cause this problem are as follows. Assume I have just rebooted the server and there are no connections to it. I start my build script from Solaris using ANT command line. The build script uses approx 30 Starteam ANT task calls (stcheckout stlabel only). As the build script executes, all the Starteam tasks are fast, the 30th call is as fast as the first. The build script finishes. After the build finishes if I try and use the Starteam GUI to check out code it is extremely slow. If I were to run another build script all the Starteam ANT tasks (stcheckout, stlabel) are extremely slow. I wait some amount of time (I do not know the exact time but it is around 15 minutes) and everyhing is back to normal, Starteam GUI is fast again, if I run another build it will be fast again. When I first started my build script it was small, around 5 calls to Starteam ANT tasks, I never had these problems when there was a small amount of Starteam targets in the script. If I run a script that has 5 Starteam targets the server does NOT slow down after. I have run netstat on the Starteam server when the build is running and there seems to be a new connection to the build client for every Starteam target called. These connections are visible through netstat until the build ends, when the build is over the connections are no longer visible using netstat. Finally, if I restart the Starteam server when it is in a slow state when it comes back up everything is fine. Thanks for the help. Ross -Original Message- From: Steve Cohen [mailto:[EMAIL PROTECTED] Sent: Friday, October 24, 2003 9:54 AM To: Ant Developers List Subject: RE: Starteam connect/disconnect Hmm, I have never noticed this. While what you say certainly sounds logical (clean up after yourself, basically, as you must do with database connections, etc.) I have never experienced it myself. I can certainly take a look at putting connection-closing logic into these tasks, especially as the connection is not reused between task invocations. What client and server environments are you doing this in? Steve Cohen Sr. Software Engineer Sportvision, Inc. scohenATSportvisionDOTcom -Original Message- From: Ross Gibb [mailto:[EMAIL PROTECTED] Sent: Friday, October 24, 2003 7:54 AM To: [EMAIL PROTECTED] Subject: Starteam connect/disconnect Hi, I am using ANT with Starteam and having some troubles. Right now my build script makes around 30 separate calls to Starteam targets (stcheckout, stlabel exclusively). When the build is finished Starteam seems to get into a weird state where everything is extremely slow (i.e. using the Starteam gui to checkin or checkout code is really slow). The slowness eventually goes away, some sort of timeout I am guessing. I tried to help myself and started poking around the ANT source code to see how the Starteam API is used. I think I found the call to the Starteam API that connects to the server, it is: In class org.apache.tools.ant.taskdefs.optional.starteam.StarTeamTask The function is: /** * All subclasses will call on this method to open the view needed for * processing. This method also saves a reference to the * codeServer/code that may be accessed for information at various * points in the process. * * @return
RE: Getting people to test the beta
This is great - pretty much exactly what I was looking for a couple of weeks ago. Heck, if I could ever get out from behind the workload that sits on top of me, even I could take the time to test it. Perhaps next month. -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 14, 2003 4:22 AM To: [EMAIL PROTECTED] Subject: Getting people to test the beta Hi, this is just a random thought, but I have to share it anyway 8-) To me it seems that the only way to get people to test the beta is to better explain what the new really cool features will be. Not that I expect too much testing then either, most people will simply wait for the first final release, but we may get testing of those featured features. My idea is to use the Wiki and the user list together to improve our docs and attract testers at the same time. It goes along the following line * Add a Wiki page listing the things that we consider killer new features * For each such feature write a separate more tutorial/howto style introduction. Not too much, people should be able to improve on it. * Every second day or so pick one of the features and announce it on the user list, include a short introduction of the feature there. Invite people to participate in both testing and improving the documentation. When done, compile documentation for the new features from the Wiki and put it into / link it from the welcome.html file as well as release notes and announcements of the next release. Could that work? Would it be too much trouble? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 1.6 migration guide?
Thanks, Stefan. Anything would be better than nothing, and I'm not one to underestimate the limiting factor of time. -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2003 1:55 AM To: [EMAIL PROTECTED] Subject: Re: 1.6 migration guide? On Tue, 30 Sep 2003, Steve Cohen [EMAIL PROTECTED] wrote: In other words, I'm looking for a migration guide that shows off the 1.6 way of doing things against the 1.5 way wherever the 1.6 way is more powerful, Actually I've been thinking about putting together small tutorials for the really interesting stuff that's easy to miss. On the top of my list are Antlibs, presetdef and the new way to define custom filterreaders, conditions and so on. I feel that smaller tutorials may be easier to write and maintain than a single migration guide. The most limiting part here is time - as always. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
1.6 migration guide?
I haven't had much to do with the 1.6 release and am still using 1.5.4. (Actually, in fact, probably 1.5.3). I don't care which manual is online as long as I can get to the 1.5.4 manual without too much hassle. But my question has more to do with the 1.6 documentation itself. From following the discussion threads it seems that while a few things may break in 1.5.4 build scripts, there are whole new possibilities to do things elegantly in 1.6 that could only be done in a kludgey fashion in 1.5. My impression is that it's sort of like Java 1.2. When it came out you could still write Java 1.1 code with 1.2, but unless you were aiming for backward compatibility, why would you want to? In other words, I'm looking for a migration guide that shows off the 1.6 way of doing things against the 1.5 way wherever the 1.6 way is more powerful, not just the list of new features that is in the release notes. Is someone working on such documentation? I think it would be valuable.
