DO NOT REPLY [Bug 19358] - Add timezone to FTP

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=19358

Add timezone to FTP





--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 23:59 ---
I agree with the concept of using the Java Std. timezones, but, we may want to 
do both. The reason - clocks are not always set to the correct time, and it may 
at times be very useful to be able to specify with greater precision than by 
timezone. So, why not accept both? Or, support two attributes, one for 
timezone, and one to deal with incorrectly set clocks.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: override

[Nicola Ken Barozzi]

Jose Alberto Fernandez wrote, On 08/08/2003 20.02:
...
From the XSLT bible by Michael Kay (2nd edition page 232):
"Like inheritance un object-oriented languajes,  is designed
to allow the creation of a library or reusable components, only in this case, 
the components are modules of stylesheets. And the mechanism works in a very 
similar way to inheritance".

My understanding is that we wanted  to allow us to define
modules of .
Yes. And as I see, Costin agrees to this. I'm not sure I understand what 
you are aiming your comments at :-?

You should read the full text of that page, I think a lot of what they want to
acomplish in XSLT matches what I think, we need to acomplish in ANT,
not sure is the way is done is the best for ANT, and they definetly go
deeper than just stylesheet overriding (precedence) they override all
kinds of things. Many do not apply to us, but others may.
Unfortunately I don't have that book... please help me. I think that 
with my last mail proposal, the solution addresses all concerns 
expressed here, except yours. I still don't understand though what you 
want to do exactly, because it seems to me that you are talking about 
"how" to do it rather than "what" you need.

Please write some usecases as I have done, so that we all can look at 
them and see if/how they can be written with the current proposal, and 
eventually update it.

...
to me the important thing is the goal
of writing effective reusable code.
Same here.
The project you cited, Centipede, effectively is able to do it with the 
current import (which I initially wrote BTW).

My opinion is that the current proposal does all that Centipede needs 
and does now, and even more.

Why do you think that this is not the case?
Remember, real code examples are important. Conor convinced me with 
code. I convinced and discussed with Costin with code.

Code, code code!
 - verba volant, scripta manent -
:-)
--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: override

[Jose Alberto Fernandez]

> From: Costin Manolache [mailto:[EMAIL PROTECTED]
> 
> Nicola Ken Barozzi wrote:
> 
> >> Yes, most build files have a target named "build" - but I 
> don't know why
> >> would you think about inheritance and OO instead of just 
> qualified names.
> >> 
> >> I don't know _any_ programming language where import is used for
> >> inheritance.
> > 
> > Well, I pointed out xslt, what about that? ;-)
> 
> I know. Well, the behavior for properties in ant is inspired 
> from XSLT as
> well. 
> But I don't think the import in XSLT is intended as an OO 
> construct. Many
> people don't think XSLT is a very good as a programming 
> language ( even
> if you can do a lot of logic in XSLT ). 
> 

>From the XSLT bible by Michael Kay (2nd edition page 232):
"Like inheritance un object-oriented languajes,  is designed
to allow the creation of a library or reusable components, only in this case, 
the components are modules of stylesheets. And the mechanism works in a very 
similar way to inheritance".

My understanding is that we wanted  to allow us to define
modules of .

You should read the full text of that page, I think a lot of what they want to
acomplish in XSLT matches what I think, we need to acomplish in ANT,
not sure is the way is done is the best for ANT, and they definetly go
deeper than just stylesheet overriding (precedence) they override all
kinds of things. Many do not apply to us, but others may.

> 
> > As has been pointed out in these threads, Ant is a 
> different beast, and
> > should be treated differenty.
> 
> +1
> 

Maybe that is true, but to me the important thing is the goal
of writing effective reusable code.

> 
> >> And if people need an OO feature for ant - that's fine, 
> they can add
> >> special tasks ( , , etc ).
> > 
> > Hey, that's what we are talking about! IOW, what should Ant 
> give me to
> > get the features I want?
> > 
> >  ok, already decided
> >  ok, already decided
> >  ?
> 
> If include is already decided, then skip import. 
> 
> Add "extends" or something like that. 
> 

Changing the name does not deal with the ussues.
Names are the least of our problems.

> I'm not concerned with override-target - only with import and 
> the resolution
> of name conflicts. 
> 
> If people want to replace targets - great, but it's not my 
> use case :-) A
> clean import is what I need.
> 
> 
 you mean :-)
> 


Jose Alberto

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21044] - ftp mkdir fails

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=21044

ftp mkdir fails

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED
   Target Milestone|--- |1.6



--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 17:48 ---
You welcome !

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: override

[Jose Alberto Fernandez]

> From: Costin Manolache [mailto:[EMAIL PROTECTED]
> 
> Jose Alberto Fernandez wrote:
> 
> > One of the problems I have with the "rewriting" approach is 
> that target
> > names get rewritten y the caller which means that two independent
> > importers may decide to use the same prefix and hence you 
> get a clash.
> > Namespaces or java-style fully-qualified-names are a 
> property intrinsic
> > of the imported file, that is the reason that makes it safe.
> 
> That's why I think it's better to not try to be too flexible 
> in allowing
> arbitrary rewriting, but do it in a canonical way:
>  - after a build.xml is read, all un-qualified names get 
> prefixed with the 
> project name and a delimiter ( need some tricks for ant-call, but it's
> possible )

Antcall is a call to the entire buildfile, since it will reload the build
file from the top. Hence I do not think we should rewrite here. 
In any case, how do you deal with properties in the target attribute:



In my opinion, if you are writing buildfiles for reuse you should
make sure either not to use  or instead use:

...
> > 
> > if you use something like a task to specify the extend then 
> you may write
> > multiple inheritance and all these ambiguities appear.
> > Could we live with single inheritance and  
> instead of ?
> 
> My point is that  is different than "extneds". 
> 
> 
> > The escenario is that you have your tipical:
> > 
> > a
> >target compile depends=precompile
> >target precompile (do-nothing)
> > 
> > b
> >target precopile (very complex precompile lib)
> > 
> > build:
> >import (a,b)
> > 
> > With cross-talk that is all you need to connect the two
> > and get the required effect. Without cross-talk you would 
> need to add
> > more targets to build:
> 
> With qnames there is no crosstalk.
> 
> a
>target a::compile depends a::precompile
>target a::precompile
> 
> b
>   target b::precompile
> 
> build:
>   import a, b
>   You can call a::compile ( which will call a::precompile ), etc.
> 
>  
> >target precompile depends=b.precompile
> > 
> > or
> > 
> >override-target compile depends=b.precompile, super.compile
> 
> Too complicated IMO. 
> 
> All import should do is load some build files and deal with the 
> name conflicts in a clear way, without becoming a very hacky solution
> that nobody understand - and to be honest I have a lot of trouble 
> understanding most of the overriding - even in the simple examples 
> on the thread, I can't imagine what will happen when people 
> start using this
> with dozens of targets.
> 
> 

This is exactly my point. If the feature is not properly defined
and all cases taken into consideration, people will get into trouble
when writing large build files. We already have people using things
like centepide that has inheritance and would like to have it directly
in ANT. Are there any interesting uses of inheritance there that we can
see. After all this feature is so that we address the need of real users
and not just a feature for feature sake.

As I said before, I do not presume to have all answers,

Jose Alberto


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22253] - couldn't build resource into c# assembly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=22253

couldn't build resource into c# assembly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |1.6



--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 17:18 ---
in CVS_HEAD you can add  elements in a compile

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: and Mono (was Re: cvs commit: ant/src/etc/testcases/taskdefs/optional dotnet.xml)

[Steve Loughran]

Stefan Bodewig wrote:
On Thu, 07 Aug 2003, Steve Loughran <[EMAIL PROTECTED]> wrote:

Does it work?

Yes
testCSC-Mono:
  [csc] compiling 2 files
  [csc] WROTE SYMFILE: 2 sources, 2 methods, 3 types, 4 line numbers, 0 
locals, 2 namespaces, 247 bytes of string data
  [csc] OffsetTable [639 - 52:515 - 2:591:48 - 2:567:24 - 3]
  [csc] Compilation succeeded
 [exec] hello, I look like Java, but I'm really .NET
   [delete] Deleting: 
/home/bodewig/ASF/jakarta/jakarta-ant/src/etc/testcases/taskdefs/optional/dotnet/build/ExampleCsc.exe
testCSC-MS:
testCSC:
BUILD SUCCESSFUL
Total time: 7 seconds
after changing the  to invoke "mono", that is.
Ahh. I have wine on my box, which does auto-run PE executables. It must 
have been trying to run the exe

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22227] - available task should support references IMO

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=7

available task should support references IMO

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 15:39 ---
There is already a  Condition.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22227] - available task should support references IMO

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=7

available task should support references IMO





--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 15:24 ---
Created an attachment (id=7698)
patch to the manual page

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22227] - available task should support references IMO

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=7

available task should support references IMO





--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 15:24 ---
Created an attachment (id=7697)
patch to the test case build file

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22227] - available task should support references IMO

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=7

available task should support references IMO





--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 15:24 ---
Created an attachment (id=7696)
patch to the  test case

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22227] - available task should support references IMO

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=7

available task should support references IMO





--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 15:23 ---
Created an attachment (id=7695)
patch to the  task

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: override

[Nicola Ken Barozzi]

Trying to summarize.
Costin Manolache wrote, On 08/08/2003 16.21:
Nicola Ken Barozzi wrote:
...
As has been pointed out in these threads, Ant is a different beast, and
should be treated differenty.
+1

We are talking about OO concepts and inheritance - in  context.
Well, we are not. We are referencing those concepts, but it's not the
same thing.
Still - replacing/overriding targets in import is very confusing, even on
ant-dev.
>
My point is that we should eliminate ambiguities - but not by adding more
flexibility and complexity into the import task.
ACK
If we have so much trouble understanding how  would be used
for inheritance, what about all the users who may be java programmers
( where import has a very intuitive meaning, and so does extends ).
If it's just a naming issue, let's call it XYZ, I honestly don't care.
Just to be clear: current import is *not* . It is not meant
to encapsulate another buildfile, and the basedir resolving and the
non-namespacing of properties is very clear about this.
What is  ?
I have to reread the mails to get to that point? No way ;-P
I'll just explain brieflt OTOMH, Conor can be more precise. In essence 
it's about having ant buildfiles instanciated in parallel, and have make 
it possible for them to share dependencies.

So a target in project A can depend on a target in project B, and the 
two builds are completely isolated in their own 
basedir-properties-targetnames.

IIRC there is some docs in Conor's Ant2 proposal.
Ok, so you haven't read all the thread ;-)
Maybe it's better if you take a bit of time to reread the thread, as we
are repeating stuff here.
I'm working on that :-) If I repeat some opinions - that's good.
:-)
If you import 2 files, each having a "compile" target, then you should
use qualified names. Like in java import.
Ok, this is clear, you are saying we should not have an automatic
"winner" in case of multiple colliding import names.
Yes. Having a "winner" is what creates confusion, ambiguity and the 
need to rewrite or define import as an OO construct.

Just use a  target, or some / or .
In fact, as I have explained, Conor proposed , and I
like it. But this is only about a a single import, the real issue
discussed here is the multiple one.
I like it as well, but I don't agree that it is about a single import, it
can be very well used inside a single file, with no import at all.
If we agree on qnames ( and implicitely no "winner" or conflicts in import),
then override-target and all that becomes even more powerfull - you'll have 
access to _all_ targets, including the loosers.
That's the idea behind the current import stuff, so it fits perfectly.
Second question: how do we deal with the fact that targets that are not
even used have crosstalk between themselves?
I don't think you can have crosstalk if you follow the rule that
everything is qualified if it has the same name.
Two points here:
 - Crosstalk can happen in form of properties
 - Of course you won't have crosstalk if you use qualified names, this
   is what Conor says
Again, I agree with Conoer :-) That may mean he is right ?
I haven't tought about qualified names for properties, but it makes sense
too.
Noted.
Let's see:

No problem here, any collision is an error
I don't quite see a need for include ( given my view on import :-), but
if other people need it - fine with me.
Well, some +1ed it, so since it's a subset of the import functionality, 
I'd say "why not" too.

Basically it should be simply a 1-1 replacement with entity includes.

I am overriding the previous defined target, and can refer only to the
immediately previous one as original.targetname. Overriding can be done
multiple times, nesting the calls.

Like include, but gives me the possibility of referring to the imported
tasks with a fully qualified name in any case. If there is only one
version of a target, it's also available with the original name.
 [The "namespace" name has to be
specified as a prefix by the one that imports the file, else the project
name is used. Projects that are imported must have a name.]
If a project imports clashing target names, and thus namespacing is
needed, I can still use  or  to define a target
with the original name.
+1


I'm starting to like override-target :-)
:-)
BTW, we have renamed cents to antlibs, Centipede is just a task, and we 
are splitting functionality in various tasks, as you have suggested.
It's looking good :-)

Thanks for taking time to discuss this guys, I appreciate :-)
Sorry for repeating what has been discussed, I was very concerned about
mixing import with OO and complex name resolution rules ( like in XSLT
import :-)
You have maybe repeated some (small) parts of the discussion, but you 
have been very good at making your point, which in fact was exactly the 
last point of contention. :-)

What remains is Jose Alberto's POV, that probably can be summarized in 
this part he wrote:
"
The probelm with this is that it does not allow you to write code
fragments. Like several block

DO NOT REPLY [Bug 21044] - ftp mkdir fails

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=21044

ftp mkdir fails





--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 15:17 ---
Ant 1.6alpha binaries (nightly build 8/8), with commons-net-1.0.0.jar, works 
for me, too, from Win2K and RH Linux 8.
Thank you!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

*REMINDER* last call for july newsletter

[Tetsuya Kitahata]

This is a last call for additions for the july newsletter.
(The Apache Newsletter -- Issue 1 -- http://www.apache.org/newsletter/)
There's still time to add articles about the Apache Ant to the wiki page.

http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheNewsletterDrafts/Issue1

The editorial deadline will be 00:00 (PDT), 9th August.
# 07:00 GMT, 9th August

If you have a hesitation in writing the article using Apachewiki,
please directly write it and let me know. I'll upload it and pick
it up as an article in the next newsletter.

Anticipating nice blurb :-)

(I think the upcoming Ant 1.5.4 Release Plan would be news-worthy.)

Sincerely,

-- Tetsuya Kitahata ([EMAIL PROTECTED])



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22253] New: - couldn't build resource into c# assembly

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=22253

couldn't build resource into c# assembly

   Summary: couldn't build resource into c# assembly
   Product: Ant
   Version: unspecified
  Platform: PC
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


win32res attribute is restricted to Windows resource.

Is there an option that we can use to build resources into .Net assembly?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21883] - Using -listener or -logger option causes basedir to become wrong

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=21883

Using -listener or -logger option causes basedir to become wrong

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 14:43 ---
No it is not a bug. The buildStarted event is sent when the build is started.
This occurs prior to most configuration of the project instance and certainly
before the parsing of the build file, and therefore the setting of basedir.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22240] - 'excludes' attribute of war task fails to exclude files included by a nested fileset.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=22240

'excludes' attribute of war task fails to exclude files included by a nested 
fileset.





--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 14:39 ---
Darn. I see. Those pesky .nbattrs are always all over the place, so I assumed 
them to be in all directories I selected. As it turns out, the only one having 
one of them is the directory selected by the nested fileset.

It still seems weird to me that excludes doesn't work this way, but then again, 
regular filesets don't have nested filesets.

So I guess this is either an invalid bug or an RFE?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 18055] - javac task includes java rt.jar in classpath when using jvc compiler

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=18055

javac task includes java rt.jar in classpath when using jvc compiler

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED
   Target Milestone|1.5.3   |1.6



--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 14:36 ---
I have taken out the extdirs for jvc when includejavaruntime is false.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/compilers Jvc.java

[conor]

conor   2003/08/08 07:33:03

  Modified:src/main/org/apache/tools/ant/taskdefs/compilers Jvc.java
  Log:
  Don't include ext dir for microsoft jvc when java runtime is excluded.
  
  PR:   18055
  
  Revision  ChangesPath
  1.17  +5 -3  
ant/src/main/org/apache/tools/ant/taskdefs/compilers/Jvc.java
  
  Index: Jvc.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/compilers/Jvc.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -w -u -r1.16 -r1.17
  --- Jvc.java  19 Jul 2003 08:11:01 -  1.16
  +++ Jvc.java  8 Aug 2003 14:33:03 -   1.17
  @@ -89,9 +89,11 @@
   classpath.append(bootclasspath);
   }
   
  +if (includeJavaRuntime) {
   // jvc doesn't support an extension dir (-extdir)
   // so we'll emulate it for compatibility and convenience.
   classpath.addExtdirs(extdirs);
  +}
   
   classpath.append(getCompileClasspath());
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22240] - 'excludes' attribute of war task fails to exclude files included by a nested fileset.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=22240

'excludes' attribute of war task fails to exclude files included by a nested 
fileset.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 14:34 ---
As Peter has said, the excludes in the  task applies to the implicit
fileset used by  but this fileset is not used in your case so the excludes
has no effect. You will need to add excludes for all the filesets.

In Ant 1.6, you can set the defaule excludes to exclude these files from every
fileset in the build.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22240] - 'excludes' attribute of war task fails to exclude files included by a nested fileset.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=22240

'excludes' attribute of war task fails to exclude files included by a nested 
fileset.





--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 14:24 ---
Except that the excludes does not work for those...
see











jar tf w.war



gives the output:
Buildfile: /home/preilly/proj/learning/war/build.xml
Deleting directory /home/preilly/proj/learning/war/src
Deleting: /home/preilly/proj/learning/war/w.war
Created dir: /home/preilly/proj/learning/war/src
Creating /home/preilly/proj/learning/war/src/x.xml
Building war: /home/preilly/proj/learning/war/w.war
META-INF/
META-INF/MANIFEST.MF
WEB-INF/
WEB-INF/classes/
WEB-INF/classes/x.xml
WEB-INF/web.xml

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: override

[Costin Manolache]

Nicola Ken Barozzi wrote:

>> Yes, most build files have a target named "build" - but I don't know why
>> would you think about inheritance and OO instead of just qualified names.
>> 
>> I don't know _any_ programming language where import is used for
>> inheritance.
> 
> Well, I pointed out xslt, what about that? ;-)

I know. Well, the behavior for properties in ant is inspired from XSLT as
well. 
But I don't think the import in XSLT is intended as an OO construct. Many
people don't think XSLT is a very good as a programming language ( even
if you can do a lot of logic in XSLT ). 


> As has been pointed out in these threads, Ant is a different beast, and
> should be treated differenty.

+1


>> I preffer to use import to just import
>> entire files, instead of some attributes and sophisticated rules to
>> determine what target is visible and what target is overriden.
> 
> Then call it , it's already proposed.

Well, C uses #include, java uses import. I don't know if a lot of people 
will care if it's called one way or another. 


>> And if people need an OO feature for ant - that's fine, they can add
>> special tasks ( , , etc ).
> 
> Hey, that's what we are talking about! IOW, what should Ant give me to
> get the features I want?
> 
>  ok, already decided
>  ok, already decided
>  ?

If include is already decided, then skip import. 

Add "extends" or something like that. 


>> We are talking about OO concepts and inheritance - in  context.
> 
> Well, we are not. We are referencing those concepts, but it's not the
> same thing.

Still - replacing/overriding targets in import is very confusing, even on
ant-dev.

My point is that we should eliminate ambiguities - but not by adding more
flexibility and complexity into the import task.


>> If we have so much trouble understanding how  would be used
>> for inheritance, what about all the users who may be java programmers
>> ( where import has a very intuitive meaning, and so does extends ).
> 
> If it's just a naming issue, let's call it XYZ, I honestly don't care.
> 
> Just to be clear: current import is *not* . It is not meant
> to encapsulate another buildfile, and the basedir resolving and the
> non-namespacing of properties is very clear about this.

What is  ?


>> Well, we seem to be talking about which target will be visible - with
>> private/public and all this.
>> Very far from java import - where all you can talk about is qualified
>> names if you have 2 classes with the same name.
> 
> Because Java does not have multiple inheritance, and even more does not
> have automatic multiple inheritance. I agree that this is a different
> concept.

If java doesn't have mutiple inheritance, why would ant need multiple
inheritance. Why would ant need inheritance at all is a different question
;-)

The real problem is that importing multiple files may result in the same
target name beeing defined multiple times. There is a very simple solution
to that - qnames. 


> Ok, so you haven't read all the thread ;-)
> Maybe it's better if you take a bit of time to reread the thread, as we
> are repeating stuff here.

I'm working on that :-) If I repeat some opinions - that's good.


>> If you import 2 files, each having a "compile" target, then you should
>> use qualified names. Like in java import.
> 
> Ok, this is clear, you are saying we should not have an automatic
> "winner" in case of multiple colliding import names.

Yes. Having a "winner" is what creates confusion, ambiguity and the 
need to rewrite or define import as an OO construct.



>>>So
>>>  target compile
>>>  target newcompile (call:prestuff, compile, poststuff)
>>>  target test depends=compile
>> 
>> That's a nice use-case - but why do you think this is a use case for
>> "import" ?
> 
> Because I called it this way, that's all ;-)

What you want is:
  target compile
  target pre
  target post
  
  override name="compile" targets="pre,compile,post".

This can be done inside a single file, no need to use imports at all.



>> Just use a  target, or some / or .
> 
> In fact, as I have explained, Conor proposed , and I
> like it. But this is only about a a single import, the real issue
> discussed here is the multiple one.

I like it as well, but I don't agree that it is about a single import, it
can be very well used inside a single file, with no import at all.

If we agree on qnames ( and implicitely no "winner" or conflicts in import),
then override-target and all that becomes even more powerfull - you'll have 
access to _all_ targets, including the loosers.




>> So I consider a good thing that import doesn't allow you to "decorate",
>> but instead you should use a specialized task for this use case.
> 
> You mean that a user must do:
> 
>   
> 
>   instead of
> 
>(implicit override)?
> 
> I'm fine with it, no problem here, again it has been proposed and
> accepted, but not the issue here.

No, that's not what I'm saying :-)

I'm not concerned with override-target - only with import and the re

RE: override

[Costin Manolache]

Jose Alberto Fernandez wrote:

>> I don't know _any_ programming language where import is used for
>> inheritance.

> Believe it or not, XSLT is a programming language. :-)
> And it uses the term import for inheritance.

I know XSLT is a programming language, I don't remember it beeing an "OO" 
language. And I certainly don't think ant should become a programming
language like XSLT. 


>> Well, KISS is my concern as well, for  ( which at
>> least in my mind
>> is _very_ different from "extend" ). I preffer to use import
>> to just import
>> entire files, instead of some attributes and sophisticated rules to
>> determine what target is visible and what target is overriden.
>> 
> 
> What does it mean "importing" an entire file? I have heard on other
> languages of "including" an entire file: C, C++, etc.

Yes, C uses the keyword "#include", Java uses "import".

I think import is more intuitive for java programmers, and I'm not sure 
I get the subtle difference between  and  or why we 
need both ( unless we want to get some complexity from XSLT ).



>> And if people need an OO feature for ant - that's fine, they
>> can add special
>> tasks ( , , etc ).
>> 
> 
> It is not that easy, you most probably need to change the
> execution engine, to do it right. Which means changing some of the
> internal DS of Ant. So it is not just a little task, here and there.

That's another argument to keep import simple ( and not turn it into
 an OO concept ). 


> We have never been talking about java imports. I do not know why
> you are assumming we were.

Because  is making the targets of one file visible in another one.
You can consider python and other languages  (except C/C++ ) where similar
constructs are used.


>> Maybe import shouldn't solve all use cases - just have a
>> different task
>> that solves overriding/replacing some targets.
>>  
> 
> Still, what do you do when including the same target name more than once?

Use qualified names. 

 a:
   compile
   all  depends compile
 b: 
   compile
   all depends compile
 c:
   import a,b
   compile 
   all depends a::all, b::all, compile

Import a will load a and qualify the names. The equivalent view is:

 a:
   a::compile
   a::all depends a::compile
 b:
  b::compile
  b::all depends b::compile

 c:
  import a,b
  c::compile
  c::all depends a::all, b::all, c::compile

There is no conflict between the 3 compile targets, and each can be 
used in an unambiguous and clean way. More important - you have access to
all targets in all files, and no need to worry about what is overriden by
what or order of imports or deep imports. Doesn't matter how a file is
imported, you can use all its targets.


>> If you import 2 files, each having a "compile" target, then you should
>> use qualified names. Like in java import.
>> 
>> 
> 
> In Java the qualified name is intrinsic to the imported file;
> but in the current proporsals the name is given by the importing build,
> this makes names not to be unique.

I consider that an error.

If the name is not unique - then report an error.

We already have a name in the , and I'm not sure why
we want to define another name given to a project in import, and to add to
the confusion - allow a project to be reffered by different names, and
worse, to have the same name used for different projects in import
statements. 

Just add the requirement that in order to use import, the project name must
be unique, and report an error if 2 files with the same project name are
used.




>> None, if 2 targets with the same name are found, you must
>> use qualified names for both ( when calling from outside -
> 
> Agreed. But you should be able to redefine the target (override)
> and say what do you want it to mean.

Ok - you should be able to say:
 
or even
 
( what Nicola seem to want ).

But not as part of import - this is a different story, different task.
It is easy to manipulate the namespace of the project - after the loading
is done - and do any kind of changes ( again, python comes to my mind )



>> > Second question: how do we deal with the fact that targets
>> that are not
>> > even used have crosstalk between themselves?
>> 
>> I don't think you can have crosstalk if you follow the rule
>> that everything
>> is qualified if it has the same name.
>> 
> 
> The probelm with tis is that it does not allow you to write code
> fragments. Like several blocks of initializations that can be
> reused but do not define a full build process.

Why not ? It just requires you to use them with a qualified name or make
their names unique.

What it prevents is confusion if you have 2 fragments using the same name.



>> > And most of all: how to solve the last two points while keeping it
>> > possible for me to retain the use-cases?
>> 
>> By adding specialized tasks for your use case ?
>> 
> That is what we were trying to do.

I'm confused, I tought we are discussing import :-)

Costin


-
To un

DO NOT REPLY [Bug 22220] - CVS task does not interoperate with cvsnt client

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=0

CVS task does not interoperate with cvsnt client





--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 13:53 ---
Since ant's  task is merely a thin veneer on the cvs executable it is hard
to see how this is a problem in Ant, especially since terminating the cvs.exe
process causes Ant to resume. Ant is clearly waiting for the command to 
complete.

Can you look at the command line Ant is generating (use the -debug flag) and
then try this manually a few times. There are obviously many components which
may be affecting this - the server, the network setup, the ssh client, cvs.exe
and Ant.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22240] - 'excludes' attribute of war task fails to exclude files included by a nested fileset.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=22240

'excludes' attribute of war task fails to exclude files included by a nested 
fileset.





--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 13:45 ---
However, the nested elements lib, classes, webinf and metainf all specify 
filesets. The excludes work for those. It would be more consistent to have it 
work for nested filesets as well.
It seems like the natural thing - the fileset selects some files and offers 
them 
to the war task, which then rejects some of them.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [vms] case sensitivity and s

[Wannheden, Knut]

> 
> > Example: I have a file FOO.TXT on the file system and select it with
> > .  It will get selected because
> > 
> > new File("foo.txt").getCanonicalPath()
> > 
> > returns "foo.txt" instead of "FOO.TXT".
> 
> This is bad, in particular as it won't get selected for
> includes="fo?.txt", so we have an inconsistency in the case-sensitive
> case, no matter what we use as a default value for OpenVMS.
> 

I didn't even think about that.  But with case sensitivity disabled the file
will be selected by "fo?.txt".

The only way to access the case of a file from Java on OpenVMS is currently
to use File#listFiles().

> The only solution I see is to change line 718 in DirectoryScanner to
> read 
> 
> if (!path.equals(currentelement)
> || Os.isFamily("openvms")) {
> 

Looks reasonable.  BTW, would it be reasonable to add constants like ON_VMS
to Os?  In this case the Os.isFamily("openvms") would be run quite a few
times...  Or the Os class could of course also cache results.

> or force OpenVMS to take the first branch in line 690, that should
> take care of this issue.
> 

Don't quite understand what that would do :-)

--
knut

Re: [vms] case sensitivity and s

[Antoine Levy-Lambert]

Stefan, Knut :
the solution is then to bypass the optimization of directoryscanner (looking
only at include patterns) in the case of open vms.
It is still possible to call scandir(basedir, "", true) from scan instead of
having a look first at the include patterns.
This will guaranteed work.
Cheers,
Antoine
- Original Message -
From: "Wannheden, Knut" <[EMAIL PROTECTED]>
To: "'Ant Developers List'" <[EMAIL PROTECTED]>
Sent: Friday, August 08, 2003 12:45 PM
Subject: RE: [vms] case sensitivity and s


> Antoine,
>
> > is it then impossible in a Java program to be sure what the exact case
> > spelling of a file in OpenVMS is ?
>
> More or less.  If you do a File#listFiles() you will get entries with the
> correct case, but only for this last segment of the path.  All other
> segments will reflect the same case as the path of the File object you
> invoked the method on, which of course doesn't necessarily reflect the
> correct case.
>
> And this is probably a little bit different from how Java works on OSX
with
> HFS+ or Win32 with NTFS.
>
> But it's not an easy problem.  On OpenVMS you also have to deal with
things
> like rooted logicals and directories and files with the same name...
>
> --
> knut
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [vms] case sensitivity and s

[Wannheden, Knut]

Antoine,

> is it then impossible in a Java program to be sure what the exact case
> spelling of a file in OpenVMS is ?

More or less.  If you do a File#listFiles() you will get entries with the
correct case, but only for this last segment of the path.  All other
segments will reflect the same case as the path of the File object you
invoked the method on, which of course doesn't necessarily reflect the
correct case.

And this is probably a little bit different from how Java works on OSX with
HFS+ or Win32 with NTFS.

But it's not an easy problem.  On OpenVMS you also have to deal with things
like rooted logicals and directories and files with the same name...

--
knut

DO NOT REPLY [Bug 22223] - bogus condition results

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=3

bogus condition results





--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 11:25 ---
Ooops. I should take a little bit more breaks ;-)

Thanks a lot for your hints,
jens.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vms] case sensitivity and s

[Stefan Bodewig]

On Fri, 8 Aug 2003, Knut Wannheden <[EMAIL PROTECTED]> wrote:

> Example: I have a file FOO.TXT on the file system and select it with
> .  It will get selected because
> 
>   new File("foo.txt").getCanonicalPath()
> 
> returns "foo.txt" instead of "FOO.TXT".

This is bad, in particular as it won't get selected for
includes="fo?.txt", so we have an inconsistency in the case-sensitive
case, no matter what we use as a default value for OpenVMS.

The only solution I see is to change line 718 in DirectoryScanner to
read 

if (!path.equals(currentelement)
|| Os.isFamily("openvms")) {

or force OpenVMS to take the first branch in line 690, that should
take care of this issue.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vms] case sensitivity and s

[Antoine Levy-Lambert]

Knut,
is it then impossible in a Java program to be sure what the exact case
spelling of a file in OpenVMS is ?
Antoine
- Original Message -
From: "Wannheden, Knut" <[EMAIL PROTECTED]>
To: "'Ant Developers List'" <[EMAIL PROTECTED]>
Sent: Friday, August 08, 2003 12:20 PM
Subject: RE: [vms] case sensitivity and s


> Stefan,
>
> >
> > > With the new ODS-5 file system this is a little bit different; I'd
> > > call it "partially case sensitive".
> >
> > Your description sounds much like Windows NTFS or MacOS X with HFS+.
> >
>
> I wasn't aware of this.
>
> > > So one solution would be to leave this problem with the buildfile
> > > editor,
> >
> > We do so for Mac and Windows users, why should we treat OpenVMS
> > differently here.
> >
>
> There is just the problem with File#getCanonicalPath() on OpenVMS.  It
> doesn't return a unique path unfortunately, it seems to return the same as
> File#getAbsolutePath() does.  And this is problematic, because case
> sensitive patterns don't really work then.
>
> Example:  I have a file FOO.TXT on the file system and select it with
> .  It will get selected because
>
> new File("foo.txt").getCanonicalPath()
>
> returns "foo.txt" instead of "FOO.TXT".  This is obviously a limitation of
> the JVM, but I don't think it will be fixed anytime soon (after talking to
> the developers).
>
> So I suppose the best thing to do is to mention this limitation in the Ant
> manual.
>
> --
> knut
>



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22244] New: - Javadoc Task.. Don't use the JAVADOC exceutable from running VM

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=22244

Javadoc Task.. Don't use the JAVADOC exceutable from running VM

   Summary: Javadoc Task.. Don't use the JAVADOC exceutable from
running VM
   Product: Ant
   Version: 1.5.3
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


We are in a complex situation @ our company.

We have our own VM based on 1.1.8 running on a embedded device.
A lot of classes contain a  class import statement eg. 
import X;
import ReadOnly; 

We have written a doclet that creates a proxy representation sourcefile 
(SomeClassProxy.java) from an input sourcefile (SomeClass.java).

This al works nicely when using javadoc <= 1.3
But as of 1.4 you can not import a class from the default package.

So performing a javadoc with our doclet will fail.
So what .. you think, switch to 1.3 and problems will dissapear. That's true, 
but the problem is that we have set 1.4.2 as our VM so that we can use HotCode 
replace in our favorite IDE (eclipse). And we call the  task from 
within an ant build.script, from within this IDE, running on 1.4.2, so we are 
forced to always run this task from the commandline.

So far, the problem.. Now the question..
Is there a way to use javadoc 1.3 command iso of the javadoc command from the 
currently running VM.? 
Or, since javadoc task is forked. Can I tell ANT to use an older VM?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [vms] case sensitivity and s

[Wannheden, Knut]

Stefan,

> 
> > With the new ODS-5 file system this is a little bit different; I'd
> > call it "partially case sensitive".
> 
> Your description sounds much like Windows NTFS or MacOS X with HFS+.
> 

I wasn't aware of this.

> > So one solution would be to leave this problem with the buildfile
> > editor,
> 
> We do so for Mac and Windows users, why should we treat OpenVMS
> differently here.
> 

There is just the problem with File#getCanonicalPath() on OpenVMS.  It
doesn't return a unique path unfortunately, it seems to return the same as
File#getAbsolutePath() does.  And this is problematic, because case
sensitive patterns don't really work then.

Example:  I have a file FOO.TXT on the file system and select it with
.  It will get selected because

new File("foo.txt").getCanonicalPath()

returns "foo.txt" instead of "FOO.TXT".  This is obviously a limitation of
the JVM, but I don't think it will be fixed anytime soon (after talking to
the developers).

So I suppose the best thing to do is to mention this limitation in the Ant
manual.

--
knut

DO NOT REPLY [Bug 22243] New: - Changes in JavaCC task

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=22243

Changes in JavaCC task

   Summary: Changes in JavaCC task
   Product: Ant
   Version: 1.5.3
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,

In order to be able use the JavaCC 3.0. I have modified code of JavaCC task. I 
have attached modified code below. 

/*
 * The Apache Software License, Version 1.1
 *
 * Copyright (c) 2000-2003 The Apache Software Foundation.  All rights
 * reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in
 *the documentation and/or other materials provided with the
 *distribution.
 *
 * 3. The end-user documentation included with the redistribution, if
 *any, must include the following acknowlegement:
 *   "This product includes software developed by the
 *Apache Software Foundation (http://www.apache.org/)."
 *Alternately, this acknowlegement may appear in the software itself,
 *if and wherever such third-party acknowlegements normally appear.
 *
 * 4. The names "Ant" and "Apache Software
 *Foundation" must not be used to endorse or promote products derived
 *from this software without prior written permission. For written
 *permission, please contact [EMAIL PROTECTED]
 *
 * 5. Products derived from this software may not be called "Apache"
 *nor may "Apache" appear in their names without prior written
 *permission of the Apache Group.
 *
 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
 * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
 * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
 * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 * 
 *
 * This software consists of voluntary contributions made by many
 * individuals on behalf of the Apache Software Foundation.  For more
 * information on the Apache Software Foundation, please see
 * .
 */

package org.apache.tools.ant.taskdefs.optional.javacc;

import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.Project;
import org.apache.tools.ant.Task;
import org.apache.tools.ant.taskdefs.Execute;

import org.apache.tools.ant.types.Commandline;
import org.apache.tools.ant.types.CommandlineJava;
import org.apache.tools.ant.types.Path;
import org.apache.tools.ant.util.JavaEnvUtils;

import java.io.File;

import java.util.Hashtable;
import java.util.Enumeration;

/**
 * JavaCC compiler compiler task.
 *
 * @author [EMAIL PROTECTED]
 * @author Michael Saunders mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]
 * @author Dariusz Tyszka mailto:[EMAIL PROTECTED]">[EMAIL 
PROTECTED]
 */
public class JavaCC extends Task {

// keys to optional attributes
private static final String LOOKAHEAD  = "LOOKAHEAD";
private static final String CHOICE_AMBIGUITY_CHECK 
= "CHOICE_AMBIGUITY_CHECK";
private static final String OTHER_AMBIGUITY_CHECK  
= "OTHER_AMBIGUITY_CHECK";

private static final String STATIC = "STATIC";
private static final String DEBUG_PARSER   = "DEBUG_PARSER";
private static final String DEBUG_LOOKAHEAD= "DEBUG_LOOKAHEAD";
private static final String DEBUG_TOKEN_MANAGER= "DEBUG_TOKEN_MANAGER";
private static final String OPTIMIZE_TOKEN_MANAGER 
= "OPTIMIZE_TOKEN_MANAGER";
private static final String ERROR_REPORTING= "ERROR_REPORTING";
private static final String JAVA_UNICODE_ESCAPE= "JAVA_UNICODE_ESCAPE";
private static final String UNICODE_INPUT  = "UNICODE_INPUT";
private static final String IGN

DO NOT REPLY [Bug 22240] - 'excludes' attribute of war task fails to exclude files included by a nested fileset.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=22240

'excludes' attribute of war task fails to exclude files included by a nested 
fileset.





--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 08:42 ---
War extends Jar and is an implicit fileset and thus inherits the "excludes"
attribute.

This attribute does not apply to nested filesets.
The attribute needs to be explicity set on the nested filesets.

The documenation of war may need to be updated to say this.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22240] New: - 'excludes' attribute of war task fails to exclude files included by a nested fileset.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=22240

'excludes' attribute of war task fails to exclude files included by a nested 
fileset.

   Summary: 'excludes' attribute of war task fails to exclude files
included by a nested fileset.
   Product: Ant
   Version: 1.5.1
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The following buildscript should exclude all files called '.nbattrs' (netBeans 
attributes, pesky little things), but doesn't.


















What follows is the verbose output for this target:

war:
  [war] Building war: C:\work\java\struts\blank\dist\my.war
  [war] adding directory META-INF/
  [war] adding entry META-INF/MANIFEST.MF
  [war] adding directory WEB-INF/
  [war] adding entry WEB-INF/struts-config.xml
  [war] adding entry WEB-INF/struts-bean.tld
  [war] adding entry WEB-INF/struts-form.tld
  [war] adding entry WEB-INF/struts-html.tld
  [war] adding entry WEB-INF/struts-logic.tld
  [war] adding entry WEB-INF/struts-template.tld
  [war] adding entry WEB-INF/struts.tld
  [war] adding directory WEB-INF/classes/
  [war] adding directory WEB-INF/classes/com/
  [war] adding directory WEB-INF/classes/com/dcs/
  [war] adding entry WEB-INF/classes/com/dcs/SubmitAction.class
  [war] adding entry WEB-INF/classes/com/dcs/SubmitForm.class
  [war] adding entry WEB-INF/classes/ApplicationResources.properties
  [war] adding directory WEB-INF/lib/
  [war] adding entry WEB-INF/lib/struts.jar
=>[war] adding entry .nbattrs
  [war] adding entry index.jsp
  [war] adding entry submit.jsp
  [war] adding entry WEB-INF/web.xml
 [echo] WAR file built.
 [echo] ==

...as you can see, a .nbattrs is added, most likely the one selected by the 
nested fileset. This was actually run with build 1.6alpha_2003-7-24, so I guess 
it's a bug for all builds.

I tried variations of the pattern, like **/.nbattrs or **/*.nbattrs, but the 
only thing that keeps it from being added, is adding excludes=".nbattrs" to the 
nested fileset.

I think this is not the way the war task is supposed to behave, but maybe this 
is just what nested filesets do, period - I will test to provide more data.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vms] case sensitivity and s

[Stefan Bodewig]

On Thu, 7 Aug 2003, Knut Wannheden <[EMAIL PROTECTED]> wrote:

> With the new ODS-5 file system this is a little bit different; I'd
> call it "partially case sensitive".

Your description sounds much like Windows NTFS or MacOS X with HFS+.

> So one solution would be to leave this problem with the buildfile
> editor,

We do so for Mac and Windows users, why should we treat OpenVMS
differently here.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Ant 1.5.4 Release Plan

[Stefan Bodewig]

On Thu, 7 Aug 2003, Magesh Umasankar <[EMAIL PROTECTED]> wrote:

> Do you plan just to replace the affected files in the 1.5.3-1
> binaries and name it 1.5.4, or build everything from scratch?

It may be a little hard to do the selective replace - some manual
pages have changed and so has the website.  My guess is that building
from scratch is easier.

> I assume it is going to be the latter.  If that is the case,
> I think, irrespective of how small the actual code changes are, 
> when the entire distribution is built, there is a chance that 
> build/packaging related regressions may get introduced,

Good point, thanks.  I'll diff the expanded trees of 1.5.3-1 and 1.5.4
and post the results so everybody can have a look.

> and hence my +0 for proceeding with a release without a beta.

In a sense 1.5.3-1 is the beta of 1.5.4 the way I proposed it.  If we
build 1.5.4beta and do another distribution for 1.5.4 final, we'd face
the same packaging issues IMHO.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: and Mono (was Re: cvs commit: ant/src/etc/testcases/taskdefs/optional dotnet.xml)

[Stefan Bodewig]

On Thu, 07 Aug 2003, Steve Loughran <[EMAIL PROTECTED]> wrote:

> Does it work?

Yes

testCSC-Mono:
  [csc] compiling 2 files
  [csc] WROTE SYMFILE: 2 sources, 2 methods, 3 types, 4 line numbers, 0 
locals, 2 namespaces, 247 bytes of string data
  [csc] OffsetTable [639 - 52:515 - 2:591:48 - 2:567:24 - 3]
  [csc] Compilation succeeded

 [exec] hello, I look like Java, but I'm really .NET

   [delete] Deleting: 
/home/bodewig/ASF/jakarta/jakarta-ant/src/etc/testcases/taskdefs/optional/dotnet/build/ExampleCsc.exe

testCSC-MS:

testCSC:

BUILD SUCCESSFUL
Total time: 7 seconds

after changing the  to invoke "mono", that is.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/etc/testcases/taskdefs/optional dotnet.xml

[bodewig]

bodewig 2003/08/08 00:59:51

  Modified:src/etc/testcases/taskdefs/optional dotnet.xml
  Log:
  .NET "executables" are not executable on Linux
  
  Revision  ChangesPath
  1.6   +3 -1  ant/src/etc/testcases/taskdefs/optional/dotnet.xml
  
  Index: dotnet.xml
  ===
  RCS file: /home/cvs/ant/src/etc/testcases/taskdefs/optional/dotnet.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- dotnet.xml8 Aug 2003 00:15:47 -   1.5
  +++ dotnet.xml8 Aug 2003 07:59:51 -   1.6
  @@ -116,7 +116,9 @@
   
   
   No app ${testCSC.exe} created
  -
  +
  +  
  + 
   
 
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: override

[Costin Manolache]

Jose Alberto Fernandez wrote:

> One of the problems I have with the "rewriting" approach is that target
> names get rewritten y the caller which means that two independent
> importers may decide to use the same prefix and hence you get a clash.
> Namespaces or java-style fully-qualified-names are a property intrinsic
> of the imported file, that is the reason that makes it safe.

That's why I think it's better to not try to be too flexible in allowing
arbitrary rewriting, but do it in a canonical way:
 - after a build.xml is read, all un-qualified names get prefixed with the 
project name and a delimiter ( need some tricks for ant-call, but it's
possible )
 - you can call a target by the local name as long as it is unique,
otherwise you need qualified names.

No overloading, no conflicts, no abiguity.


> Single inheritance (a la Java) requires having syntax that allows for
> extending only once, something like:
> 
>   ...
> 
> if you use something like a task to specify the extend then you may write
> multiple inheritance and all these ambiguities appear.
> Could we live with single inheritance and  instead of ?

My point is that  is different than "extneds". 


> The escenario is that you have your tipical:
> 
> a
>target compile depends=precompile
>target precompile (do-nothing)
> 
> b
>target precopile (very complex precompile lib)
> 
> build:
>import (a,b)
> 
> With cross-talk that is all you need to connect the two
> and get the required effect. Without cross-talk you would need to add
> more targets to build:

With qnames there is no crosstalk.

a
   target a::compile depends a::precompile
   target a::precompile

b
  target b::precompile

build:
  import a, b
  You can call a::compile ( which will call a::precompile ), etc.

 
>target precompile depends=b.precompile
> 
> or
> 
>override-target compile depends=b.precompile, super.compile

Too complicated IMO. 

All import should do is load some build files and deal with the 
name conflicts in a clear way, without becoming a very hacky solution
that nobody understand - and to be honest I have a lot of trouble 
understanding most of the overriding - even in the simple examples 
on the thread, I can't imagine what will happen when people start using this
with dozens of targets.



Costin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 8510] - shutdown hook does not fire in forked java task under JDK1.4

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=8510

shutdown hook does not fire in forked java task under JDK1.4

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 03:41 ---
*** Bug 22026 has been marked as a duplicate of this bug. ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22026] - Runtime.getRuntime().addShutdownHook( ... ) with fork="true

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=22026

Runtime.getRuntime().addShutdownHook( ... ) with fork="true

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 03:41 ---
OK, I assume this is the same as 8510, so I am marking as a duplicate.

*** This bug has been marked as a duplicate of 8510 ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21315] - Jar Update Gives Error when JAR is loaded on classpath

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=21315

Jar Update Gives Error when JAR is loaded on classpath

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 02:37 ---
So, presumably jar is in use by VM and on Windows that means jar cannot be 
deleted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22179] - Wrong Class Version

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=22179

Wrong Class Version





--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 02:34 ---
Can you show us the error and also the output of ant -version

Thanks

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 12289] - tar does not chmod on diretories

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=12289

tar does not chmod on diretories

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 02:25 ---
*** Bug 22234 has been marked as a duplicate of this bug. ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22234] - ANT tar does not preserve directory permissions

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=22234

ANT tar does not preserve directory permissions

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 02:25 ---


*** This bug has been marked as a duplicate of 12289 ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 18150] - FTP-Task depends on NetComponents instead of Commons-Net

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=18150

FTP-Task depends on NetComponents instead of Commons-Net

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 02:23 ---
*** Bug 22235 has been marked as a duplicate of this bug. ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22235] - Ant doesn't use apache distribution of net tasks - ftp, telnet

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=22235

Ant doesn't use apache distribution of net tasks - ftp, telnet

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-08-08 02:23 ---


*** This bug has been marked as a duplicate of 18150 ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22235] New: - Ant doesn't use apache distribution of net tasks - ftp, telnet

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=22235

Ant doesn't use apache distribution of net tasks - ftp, telnet

   Summary: Ant doesn't use apache distribution of net tasks - ftp,
telnet
   Product: Ant
   Version: 1.5.3
  Platform: Other
   URL: http://www.savarese.org/oro/downloads/index.html
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The 1.5.3 Ant uses the "old' oro versions of the net tasks:

com.oroinc.net.ftp.FTPClient

If you go to the Oro site (http://www.savarese.org/oro/downloads/index.html),
it points out that these libraries are now part of Apache:

org.apache.commons.net.ftp.FTPClient

Ant should be switched to use the Apache packages.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22234] New: - ANT tar does not preserve directory permissions

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=22234

ANT tar does not preserve directory permissions

   Summary: ANT tar does not preserve directory permissions
   Product: Ant
   Version: 1.5.3
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I'm running SunOS 5.7 and Ant 1.5.3-1 and the file permissions match the 
permissions in the mode but the directory permissions do not.  Running 
as 'root' or changes to the umask have no effect.  Directories are always 755 
in the tar file.  The following output shows the problem:

(bmolla)bart:/home/bmolla/anttest>ls -ltrR
.:
total 6
drwxrwxrwx   2 bmolla   dev  512 Aug  7 19:31 dir2
drwxrwxrwx   2 bmolla   dev  512 Aug  7 19:31 dir1
-rw-rw-rw-   1 bmolla   dev  257 Aug  7 19:37 build.xml

./dir2:
total 0

./dir1:
total 2
-rw-rw-rw-   1 bmolla   dev6 Aug  7 19:38 test.txt
(bmolla)bart:/home/bmolla/anttest>ant
Buildfile: build.xml

tar:
  [tar] Building tar: /home/bmolla/anttest/tartest.tar

BUILD SUCCESSFUL
Total time: 3 seconds
(bmolla)bart:/home/bmolla/anttest>tar -tvf tartest.tar 
drwxr-xr-x   0/00 Aug  7 19:31 2003 dir1/
-r--r--r--   0/06 Aug  7 19:38 2003 test.txt
(bmolla)bart:/home/bmolla/anttest>cat build.xml 

  

  
  

  

(bmolla)bart:/home/bmolla/anttest>umask
0

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/etc/testcases/taskdefs/assertions - New directory

[stevel]

stevel  2003/08/07 17:34:27

  ant/src/etc/testcases/taskdefs/assertions - New directory

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: and Mono (was Re: cvs commit: ant/src/etc/testcases/taskdefs/optional dotnet.xml)

[Steve Loughran]

Stefan Bodewig wrote:
On Wed, 06 Aug 2003, Steve Loughran <[EMAIL PROTECTED]> wrote:

yup. We either want no refs, or we want the mono refs.

With /nostdlib+ and Mono refs it doesn't work (Mono tries to open the
refs in read/write mode, no idea why).  So in the case of Mono I'd
vote for no refs.

I was thinking of something different,

As you understand the .NET area and I don't, at least not yet, please
go ahead and use me and my Linux setup as the Mono guinea pig.

1. drop all predefined references the moment you name an executable
on the command line.

Won't that cause a backwards compatibility problem?
Added a new reference that controls stdlib include/exclude. I've left 
the old one still in there, but am reasonably sure that we could cut the 
old behaviour out on default references and nothing would break (as 
excluding the stdlib is so drastic, I doubt anyone does it)

Does it work? No, not yet. And /home/slo becomes drive F:
testCSC-Mono:
  [csc] compiling 2 files
 [exec] fixme:win32:PE_CreateModule Unknown directory 14 ignored
 [exec] err:module:import_dll Module (file) mscoree.dll (which is 
needed by
F:\Java\Apache\ant\src\etc\testcases\taskdefs\optional\dotnet\build\ExampleCsc.e
xe) not found

Drive F. Hmmm. Maybe the CLR has assumptions about drive letters built 
in from the beginning -so its easier to flow with the design defect than 
it is is to correct it.

-steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/etc/testcases/taskdefs/optional dotnet.xml

[stevel]

stevel  2003/08/07 17:15:47

  Modified:src/etc/testcases/taskdefs/optional dotnet.xml
  Log:
  compiles but doesnt run. Path issues?
  
  Revision  ChangesPath
  1.5   +1 -0  ant/src/etc/testcases/taskdefs/optional/dotnet.xml
  
  Index: dotnet.xml
  ===
  RCS file: /home/cvs/ant/src/etc/testcases/taskdefs/optional/dotnet.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- dotnet.xml5 Aug 2003 15:08:17 -   1.4
  +++ dotnet.xml8 Aug 2003 00:15:47 -   1.5
  @@ -110,6 +110,7 @@
 targetType="exe" 
 executable="mcs"
 includedefaultreferences="false"
  +  standardlib="true"
 >
 
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/dotnet DotnetCompile.java

[stevel]

stevel  2003/08/07 17:11:05

  Modified:src/main/org/apache/tools/ant/taskdefs/optional/dotnet
DotnetCompile.java
  Log:
  Lets try this as a fix: A new option to turn standardlib on
  or off that overrides the defaultreferences switch
  
  Revision  ChangesPath
  1.13  +31 -1 
ant/src/main/org/apache/tools/ant/taskdefs/optional/dotnet/DotnetCompile.java
  
  Index: DotnetCompile.java
  ===
  RCS file: 
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/dotnet/DotnetCompile.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- DotnetCompile.java6 Aug 2003 09:53:23 -   1.12
  +++ DotnetCompile.java8 Aug 2003 00:11:05 -   1.13
  @@ -160,6 +160,8 @@
   
   protected String executable;
   
  +protected Boolean standardLib;
  +
   /**
*  Fix .NET reference inclusion. .NET is really dumb in how it handles
*  inclusion. You have to list every 'assembly' -read DLL that is 
imported.
  @@ -392,7 +394,11 @@
[EMAIL PROTECTED]The Parameter to CSC
*/
   protected String getIncludeDefaultReferencesParameter() {
  -return "/nostdlib" + (includeDefaultReferences ? "-" : "+");
  +if(standardLib==null) {
  +return "/nostdlib" + (includeDefaultReferences ? "-" : "+");
  +} else {
  +return null;
  +}
   }
   
   
  @@ -817,6 +823,29 @@
   }
   
   /**
  + * turn standard lib support on or off.
  + * Setting this in either direction overrides anything set in 
defaultreferences.
  + * @param standardLib
  + */
  +public void setStandardLib(Boolean standardLib) {
  +this.standardLib = standardLib;
  +}
  +
  +
  +/**
  + *  get the include default references flag or null for no argument 
needed
  + *
  + [EMAIL PROTECTED]The Parameter to CSC
  + */
  +protected String getStandardLibParameter() {
  +if (standardLib != null) {
  +return "/nostdlib" + (standardLib.booleanValue() ? "-" : "+");
  +} else {
  +return null;
  +}
  +}
  +
  +/**
*  test for a string containing something useful
*
[EMAIL PROTECTED]  s  string in
  @@ -909,6 +938,7 @@
   command.addArgument(getAdditionalModulesParameter());
   command.addArgument(getDebugParameter());
   command.addArgument(getDefaultReferenceParameter());
  +command.addArgument(getStandardLibParameter());
   command.addArgument(getDefinitionsParameter());
   command.addArgument(getExtraOptionsParameter());
   command.addArgument(getMainClassParameter());
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]