Re: antlib
On Thu, 22 May 2003 01:02 am, Jose Alberto Fernandez wrote: Whatever we adopt, it definetly need to be written from scratch. :-) Cool. All I had to go on was the code. If we agree that roles are based on the interface implemented by the nested element, that is good. It was my main concern. I still don't really see the need for roles but that's just me :-) Go for it. Conor
Re: antlib / proposal of Peter Reilly
Stefan Bodewig wrote: On 21 May 2003, Stefan Bodewig [EMAIL PROTECTED] wrote: I've seen that Costin and Conor prefer that antlibs specify their URI themselves. Could anybody please explain why OK, let me try to summarize your answers: Peter says - letting the user chose the URI may create problems if we want to add implicit meaning to URIs in the future. I think the same problem will arise if we let antlib writers chose the URI so we need to solve it differently. We could reserve all schema names starting with ant for internal use and prohibit anybody from using it, for example. To be consistent :-), I think we should let antlib writers pick arbitrary URIs either, at least in the first release. My proposal is to use the base package name of the implementation. Antlib authors can choose any package name they want - we should only require that the antlib URI matches the package. ( it's just one sugestion - I can live with any alternative, including UUIDs if that's what other people want :-) Conor and Costin - that's how you normally do it in the XML namespace context. Well, true. That doesn't necessarily mean it was a good idea 8-) There are quite a few bad ideas in XML ( schema is probably the winner in this category ). However requiring the namespace ( and the DTD ) URI to be stable is not a bad idea IMO. Costin Conor and Costin - if you read the build file and URIs are fixed you'll know which antlib is used. Well, that makes sense to me, thanks, the piece I was missing. Stefan
Re: antlib
Conor MacNeill wrote: On Thu, 22 May 2003 01:02 am, Jose Alberto Fernandez wrote: Whatever we adopt, it definetly need to be written from scratch. :-) Cool. All I had to go on was the code. If we agree that roles are based on the interface implemented by the nested element, that is good. It was my main concern. I still don't really see the need for roles but that's just me :-) Go for it. I don't think it's just you, I'm on the same side. Probably a small poll on the remaining issues would help clarify where the majority stands. I think most people are willing to accept a range of solutions, and a lot is a matter of taste and prefference. So far I've heard the strong opinion of Jose on roles - and I'm not sure on the other's opinions. There are 2 negative opinions so far. If we decide to add roles, I would like to be clear where other committers stand. Costin
Re: antlib
On Thu, 22 May 2003, Conor MacNeill [EMAIL PROTECTED] I still don't really see the need for roles I'm not convinced either. Stefan
DO NOT REPLY [Bug 20137] New: - Invalid creator ID on build of ant
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20137. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20137 Invalid creator ID on build of ant Summary: Invalid creator ID on build of ant Product: Ant Version: 1.1 Platform: PC OS/Version: Windows XP Status: NEW Severity: Blocker Priority: Other Component: Build Process AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I downloaded Rococo's Impronto Simulator software and with it came the ant executable. In building the echo_midp application that came with it, I have no problems. The problem arises when I try to duplicate a directory. ie. change the directory echo_midp to echo2_midp. I get the error Invalid creator ID when ant attempts to execute the last executable as specified in the XML buildfile, which is the jxe2prc executable. I duplicated all of the files, changing their names, and I changed all of the XML files, .jad files, etc according to my new naming convention. I also believe that because of this problem, the much needed .prc file isn't produced - only the jxe file. What do I need to do to fix this problem
Re: Enhance chgrp/chown? (was: Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs Chmod.java ExecuteOn.java)
On Wed, 21 May 2003, Gus Heck [EMAIL PROTECTED] wrote: Stefan Bodewig wrote: currently chmod has a fair number of additional features. Which are? dir, includes, excludes, defaultexcludes... Please don't! These attributes come from the pre-fileset time and are only kept for backwards compatibility. Please look at the special case in Chmod's execute that is needed to keep the old behavior of the dir attribute. Another logicical addition to all 3 of them might be allowing dirsets. I think the type=dir attribute covers this, doesn't it? It has been a core task of Ant virtually since Ant exists, so there is no way to move it from core to optional unless we restructure the set of built-in tasks completely IMHO. To clarify. I don't think we should move any core task to optional at all - until we restructure our task system completely, which I'd expect to go along with antlibs, yes. There are more tasks than just chmod that are in core but don't really fit there (cvs for example). Stefan
Re: antlib
I think that roles add clarity to description of datatypes or components. I liked the syntax of the antlib descriptor proposed by Jose Alberto, which in my example with shapes would have been : antlib version=1.5 task name=computearea class=org.apache.demo.ComputeAreaTask/ task name=computeperimeter class=org.apache.demo.ComputePerimeterTask/ role name=shape class=org.apache.demo.ShapeInterface/ ... shape name=circle class=org.apache.demo.Circle/ shape name=square class=org.apache.demo.Square/ ... /antlib Reading this, and knowing that computearea and computeperimeter accept shapes as nested element, a build file writer would know that circle/ and square/ can be nested inside computearea/ and computeperimeter/. This descriptor also says that ShapeInterface should have a special meaning for ant, which for instance Serializable, Cloneable, ... do not necessarily have. However, if , as it sounds, I am the only committer who expresses support for roles, I will give up on that subject. Antoine - Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 22, 2003 7:02 AM Subject: Re: antlib Conor MacNeill wrote: On Thu, 22 May 2003 01:02 am, Jose Alberto Fernandez wrote: Whatever we adopt, it definetly need to be written from scratch. :-) Cool. All I had to go on was the code. If we agree that roles are based on the interface implemented by the nested element, that is good. It was my main concern. I still don't really see the need for roles but that's just me :-) Go for it. I don't think it's just you, I'm on the same side. Probably a small poll on the remaining issues would help clarify where the majority stands. I think most people are willing to accept a range of solutions, and a lot is a matter of taste and prefference. So far I've heard the strong opinion of Jose on roles - and I'm not sure on the other's opinions. There are 2 negative opinions so far. If we decide to add roles, I would like to be clear where other committers stand. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlib / proposal of Peter Reilly
Sounds great. - Original Message - From: peter reilly [EMAIL PROTECTED] To: Ant Developers List [EMAIL PROTECTED] Sent: Thursday, May 22, 2003 10:56 AM Subject: Re: antlib / proposal of Peter Reilly On Saturday 17 May 2003 19:59, Costin Manolache wrote: My main concern is the same as Conor's - having this decoupled and done in few steps. Ok I will chop it up into a sequence of patches. That means you have to start with add(Type), then anttypdef, then onerror. The first patch adds the add(Type) introspection method and implements this in condition, filterchain, tokenfilter, selector and path. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlib
On Thu, 22 May 2003, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: Reading this, and knowing that computearea and computeperimeter accept shapes as nested element, a build file writer would know that circle/ and square/ can be nested inside computearea/ and computeperimeter/. So roles make the antlib descriptor more expressive, this is true. I'm not sure that the build file writer is going to read the antlib descriptor, though. This descriptor also says that ShapeInterface should have a special meaning for ant, which for instance Serializable, Cloneable, ... do not necessarily have. OK. With roles, would an arbitrary implementation of ShapeInterface that was not bundled with the antlib and was not declared to be in role shape be accepted as nested element in computearea/? If the answer is yes, then roles would be optional and would mainly be used to make things more explicit, right? This is fine with me. Stefan
DO NOT REPLY [Bug 19897] - Patch to implement the namespaced antlib + other changes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19897. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19897 Patch to implement the namespaced antlib + other changes --- Additional Comments From [EMAIL PROTECTED] 2003-05-22 10:01 --- Created an attachment (id=6453) updated tar gz patch for add(Type) after Stefan's review
Re: antlib / proposal of Peter Reilly
On Thursday 22 May 2003 10:29, Stefan Bodewig wrote: On Thu, 22 May 2003, peter reilly [EMAIL PROTECTED] wrote: Ok I will chop it up into a sequence of patches. Thanks. The first patch adds the add(Type) introspection method and implements this in condition, filterchain, tokenfilter, selector and path. I'm +1 for this patch, and only have three nits, none of which require yet another patch IMHO: I have made the patch anyway... * I'd like to have a null check on obj in ComponentHelper.createComponent before passing it to project or invoking init on it. Yikes I was using old (pre-anttypedefinition) code - I had fixed this but .. * I'd like to see some more braces in one-line ifs 8-) Ok.. * some more @since tags would be nice (I said it would be nits ;-) Added some more .. Cheers, Peter
Re: antlib
Stefan Bodewig wrote : With roles, would an arbitrary implementation of ShapeInterface that was not bundled with the antlib and was not declared to be in role shape be accepted as nested element in computearea/? If the answer is yes, then roles would be optional and would mainly be used to make things more explicit, right? This is fine with me. Stefan It is perfectly possible to program ant so that roles are optional and just make things more explicit. Roles could be used to disambiguate situations where a component class implements several interfaces which have a meaning for ant, say Shape and Block for instance, and a task accepts both shapes and blocks as nested elements. I will gladly wait until the patches of Peter Reilly are committed before implementing roles. In this case, to fit to the wish of Costin to develop roles so that they exist also outside of antlibs, I would : 1 ) create a roledef task, 2 ) add an optional role attribute to typedef, 3 ) make changes in helper classes so that if a typedef has a role assigned to it, it is only accepted as a nested element in the add method taking the role interface as parameter. Antoine Antoine
[VOTE] Peter Reilly as committer
Hi, I would like to propose Peter Reilly as an Ant committer. He has submitted a number of patches that advance the Ant core fanctions as well as helping out answering questions on the user list. I think we've all seen that he has the persistence required :-) I will start with my +1 Conor
Re: [VOTE] Peter Reilly as committer
+1 Cheers, Magesh - Original Message - From: Conor MacNeill [EMAIL PROTECTED] To: Ant Developers List [EMAIL PROTECTED] Sent: Thursday, May 22, 2003 7:26 AM Subject: [VOTE] Peter Reilly as committer Hi, I would like to propose Peter Reilly as an Ant committer. He has submitted a number of patches that advance the Ant core fanctions as well as helping out answering questions on the user list. I think we've all seen that he has the persistence required :-) I will start with my +1 Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Peter Reilly as committer
+1 Stefan
Re: [VOTE] Peter Reilly as committer
I also give my +1 Antoine - Original Message - From: Conor MacNeill [EMAIL PROTECTED] To: Ant Developers List [EMAIL PROTECTED] Sent: Thursday, May 22, 2003 1:26 PM Subject: [VOTE] Peter Reilly as committer Hi, I would like to propose Peter Reilly as an Ant committer. He has submitted a number of patches that advance the Ant core fanctions as well as helping out answering questions on the user list. I think we've all seen that he has the persistence required :-) I will start with my +1 Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20144] New: - Javadoc task running with cygwin
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20144.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20144
Javadoc task running with cygwin
Summary: Javadoc task running with cygwin
Product: Ant
Version: 1.5.3
Platform: PC
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I'm trying to use the javadoc task with Ant 1.5.3 running under cygwin. I'm
having trouble with the destdir attribute. If I specify the directory in the
Windows format h:\... the task works. If I use a cygwin format the task does
not work. Here's the debug output
[javadoc] scanning \\Fsvnode2\ITWDBW$\java_project\src for packages.
DirSet: Setup scanner in dir \\Fsvnode2\ITWDBW$\java_project\src with patternSet
{ includes: [com/**] excludes: [] }
[javadoc] Generating Javadoc
fileset: Setup scanner in dir \\Fsvnode2\ITWDBW$\java_project\lib with
patternSet{ includes: [**/*.jar] excludes: [] }
[javadoc] Executing 'C:\j2sdk1.4.1_02\bin\javadoc.exe' with arguments:
[javadoc] '-public'
[javadoc] '-d'
[javadoc] '\\Fsvnode2\ITWDBW$\java_project\docs'
[javadoc] '-bottom'
[javadoc] '
[javadoc] iCopyright Royal Caribbean Cruises Limited #169; 2003.
All Rights Reserved./i
[javadoc] '
[javadoc] '-classpath'
[javadoc] '\\Fsvnode2\ITWDBW$\java_project\external\junit\junit.jar;\\Fsvnode2
\ITWDBW$\java_project\lib\example.jar'
[javadoc] '-sourcepath'
[javadoc] '\\Fsvnode2\ITWDBW$\java_project\src'
[javadoc] '-version'
[javadoc] '-author'
[javadoc] 'com.rccl.ide.example'
[javadoc]
[javadoc] The ' characters around the executable and arguments are
[javadoc] not part of the command.
[javadoc] Javadoc execution
Execute:Java13CommandLauncher: Executing 'C:\j2sdk1.4.1_02\bin\javadoc.exe'
with arguments:
'-public'
'-d'
'\\Fsvnode2\ITWDBW$\java_project\docs'
'-bottom'
'
iCopyright Royal Caribbean Cruises Limited #169; 2003. All Rights
Reserved./i
'
'-classpath'
'\\Fsvnode2\ITWDBW$\java_project\external\junit\junit.jar;\\Fsvnode2
\ITWDBW$\java_project\lib\example.jar'
'-sourcepath'
'\\Fsvnode2\ITWDBW$\java_project\src'
'-version'
'-author'
'com.rccl.ide.example'
The ' characters around the executable and arguments are
not part of the command.
[javadoc] Loading source files for package com.rccl.ide.example...
[javadoc] Constructing Javadoc information...
[javadoc] Standard Doclet version 1.4.1
[javadoc] 1 error
[javadoc] javadoc: java.io.FileNotFoundException: \Fsvnode2
\ITWDBW$\java_project\docs\constant-values.html (The system cannot find the
path spe
cified) encountered
[javadoc] while attempting to create file: constant-values.html
Note that for some reason there is only one '\' at the beginning of the path in
the error message, whereas there seems to be two ('\\') every where else.
Also, I do not need to use the Windows path format for the sourcepath in the
same javadoc task. Nor do I need to use it in any other task. It just seems
to be a problem with the destir attribute on the javadoc task.
Thanks for any help you can provide.
RE: antlib
From: Stefan Bodewig [mailto:[EMAIL PROTECTED] On Thu, 22 May 2003, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: Reading this, and knowing that computearea and computeperimeter accept shapes as nested element, a build file writer would know that circle/ and square/ can be nested inside computearea/ and computeperimeter/. So roles make the antlib descriptor more expressive, this is true. I'm not sure that the build file writer is going to read the antlib descriptor, though. But remember we want to be able to say this same things inside build files so we can declare things not in antlibs. This descriptor also says that ShapeInterface should have a special meaning for ant, which for instance Serializable, Cloneable, ... do not necessarily have. OK. With roles, would an arbitrary implementation of ShapeInterface that was not bundled with the antlib and was not declared to be in role shape be accepted as nested element in computearea/? I would say you need to declare it as a shape or some other role-name defined by ShareInterface. The same way you need to declare something as a Task before you can use it as such. If the answer is yes, then roles would be optional and would mainly be used to make things more explicit, right? This is fine with me. Jose Alberto
Re: antlib
On Thu, 22 May 2003, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: From: Stefan Bodewig [mailto:[EMAIL PROTECTED] I'm not sure that the build file writer is going to read the antlib descriptor, though. But remember we want to be able to say this same things inside build files so we can declare things not in antlibs. OK. With roles, would an arbitrary implementation of ShapeInterface that was not bundled with the antlib and was not declared to be in role shape be accepted as nested element in computearea/? I would say you need to declare it as a shape or some other role-name defined by ShareInterface. Which means roles are not optional, even in a non-ambiguos case. What would be the benefit? The same way you need to declare something as a Task before you can use it as such. There are people who want to make this unnecessary 8-) Stefan
Re: [VOTE] Peter Reilly as committer
+1 Costin Conor MacNeill wrote: Hi, I would like to propose Peter Reilly as an Ant committer. He has submitted a number of patches that advance the Ant core fanctions as well as helping out answering questions on the user list. I think we've all seen that he has the persistence required :-) I will start with my +1 Conor
DO NOT REPLY [Bug 19181] - docs of subant task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19181. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19181 docs of subant task --- Additional Comments From [EMAIL PROTECTED] 2003-05-22 15:26 --- I got no feedback on this bug report, so I am closing it. Hopefully the documentation is OK now ?
DO NOT REPLY [Bug 19181] - docs of subant task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19181. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19181 docs of subant task [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED
Re: [VOTE] Peter Reilly as committer
Conor MacNeill wrote: Hi, I would like to propose Peter Reilly as an Ant committer. He has submitted a number of patches that advance the Ant core fanctions as well as helping out answering questions on the user list. I think we've all seen that he has the persistence required :-) I will start with my +1 +1
DO NOT REPLY [Bug 20163] New: - CvsChangeLog task support for branches
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20163. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20163 CvsChangeLog task support for branches Summary: CvsChangeLog task support for branches Product: Ant Version: 1.5.3 Platform: All OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] It would be nice to get the changelog for any or all branches. The cvschangelog task could have a branch optionnal parameter. By default, the branch would be HEAD. We could also have the possibility to get logs for all branches. In the XML file, there should be a branch nested element for file. Also, it seems to me that the date and time element of entry should actually be in file. This would allow a developer to commit two files at different time, using the same comment, and it would still be under the same changelog entry.
DO NOT REPLY [Bug 20153] - zip/unzip tasks - last modified dates off by an hour
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20153. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20153 zip/unzip tasks - last modified dates off by an hour --- Additional Comments From [EMAIL PROTECTED] 2003-05-22 17:15 --- Yes, it might be related to TZ (Time-Zone). Although, I could not figure out what it is. When I zip the file, the source files are located on remote file-server (Win2K- server) and the drive is mapped on my machine (Win2K). I checked the TZ on both and they are both (GMT-06:00) Central Time (US Canada). I checked the clocks on both and they are in sync. So I dont, where else to look ??? If its not really a bug, please mark this report as Invalid. I will find my answer from mailing list. Thanks for help.
Re: [VOTE] Peter Reilly as committer
+1 On Thursday, May 22, 2003, at 07:26 AM, Conor MacNeill wrote: Hi, I would like to propose Peter Reilly as an Ant committer. He has submitted a number of patches that advance the Ant core fanctions as well as helping out answering questions on the user list. I think we've all seen that he has the persistence required :-) I will start with my +1 Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20164] - File list generation needs to include date handling
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20164.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20164
File list generation needs to include date handling
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||WORKSFORME
--- Additional Comments From [EMAIL PROTECTED] 2003-05-22 19:44 ---
most tasks having to do with files in ant are done based on filesets.
filesets may be defined with a selector in them.
One of these selectors is based on date.
http://ant.apache.org/manual/CoreTypes/selectors.html
this example is the kind of things you want to do :
fileset dir=${jar.path} includes=**/*.jar
date datetime=01/01/2001 12:00 AM when=before/
/fileset
So I close this bug rep as works for me.
DO NOT REPLY [Bug 20153] - zip/unzip tasks - last modified dates off by an hour
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20153. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20153 zip/unzip tasks - last modified dates off by an hour --- Additional Comments From [EMAIL PROTECTED] 2003-05-22 20:23 --- I checked to make sure that both machines have day light savings turned ON. Another thing that comes to my mind is if the problem is related to timezone, it should affect copy task also, not just the zip/unzip task. As I tested, the copy task works fine (of course with preservelastmodified=true).
DO NOT REPLY [Bug 5969] - Is SMTP authorization possible for MailLogger ??
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5969. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5969 Is SMTP authorization possible for MailLogger ?? --- Additional Comments From [EMAIL PROTECTED] 2003-05-22 20:54 --- Erik and others : is it thinkable to say : the email task and the mail logger will be extended to support SMTP authentication, but only across Java Mail. The mail logger would remain based on plain mail if the user does not require authentication. If the user requires authentication, ie supplies a SMTP user/password combination, then the MailLogger would use Java Mail. Or are there very strong reasons why the mail logger should never use Java Mail ?
RE: [VOTE] Peter Reilly as committer
I would like to propose Peter Reilly as an Ant committer. He has submitted a number of patches that advance the Ant core fanctions as well as helping out answering questions on the user list. I think we've all seen that he has the persistence required :-) I will start with my +1 Conor +1 - No objections :-)! Greetings, Christoph
Re: Enhance chgrp/chown?
Stefan Bodewig wrote: On Wed, 21 May 2003, Gus Heck [EMAIL PROTECTED] wrote: Stefan Bodewig wrote: currently chmod has a fair number of additional features. Which are? dir, includes, excludes, defaultexcludes... Please don't! These attributes come from the pre-fileset time and are only kept for backwards compatibility. Please look at the special case in Chmod's execute that is needed to keep the old behavior of the dir attribute. Ah glad I asked. Another logicical addition to all 3 of them might be allowing dirsets. I think the type=dir attribute covers this, doesn't it? I guess multiple ways of doing things just isn't popular with anyone around here. Makes me wonder why we have dirsets at all if we can't use them here, and only in a narrow way for subant... I suppose type=dir is a pre-dirset feature on chmod, which I may have inadvertently propogated to my tasks because dirset was very new at the time I wrote them. (which was 4-5 months before they were commited due to the 1.5 release feature freezes). These tasks are not yet released, so maybe they should take DirSets instead? Granted that one would then need to supply a dirset and a fileset to get the both effect, but it would seem more consistant with the documentation of fileset which entirely fails to mention that directories are matched too. (unless you count the fact that /CVS is one of the default excludes). So what is the purpose of DirSet? Maybe fileset should have had a type=dir|file|both instead of having Dirsets. (of course with dirset released, it cant' be undone) What direction should I be taking with chgrp/chown here? Thinking out loud... It looks like we are not winding up with one way of doing things, but several ways that cannot be mixed between tasks. This will force the user to remember which flavor of file or directory specification a particular task finds tasty. To put it another way, I think we want to make using ant as simple as possible. To me life is simplest when any logical answer will do, and failing that, simple if there is one answer that always works. The worst case is a hashtable of case specific answers. The hashtable is what we are in danger of here. Given the constraints of back compatability, it seems that the only way to make life easy for the user is keep adding the new ways of referencing things (ie dirsets) to the old tasks in which they make sense. (much like has been done to chmod with filesets). This way at least, A dirset would always work and older ways you might or might not. If my logic is correct, and the goal is to minimize the number of ways to acomplish the same thing, we should not release chgrp and chown with the old method (type=) but rather convert them to a DirSet accepting version. (and add dirsets to chmod). This change would break builds (like mine particularly), but hey it is an alpha version... such is life. The pruning of things like chmod's dir atribute can be part of ant 2.0 where back compatability is not one of our promises... Of course if dirset is prunable, then I have it all backwards :). It has been a core task of Ant virtually since Ant exists, so there is no way to move it from core to optional unless we restructure the set of built-in tasks completely IMHO. To clarify. I don't think we should move any core task to optional at all - until we restructure our task system completely, which I'd expect to go along with antlibs, yes. There are more tasks than just chmod that are in core but don't really fit there (cvs for example). ok I understand. Have you found out anything about tandem/nonstop and chgrp chown yet? -Gus
