DO NOT REPLY [Bug 41596] - ant 1.7 bzip2 task creates corrupted output file for some inputs

[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://issues.apache.org/bugzilla/show_bug.cgi?id=41596


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|ant 1.7 tar and bzip2 tasks |ant 1.7 bzip2 task creates
   |corrupted output file when  |corrupted output file for
   |size exceeds certain limit  |some inputs




--- Additional Comments From [EMAIL PROTECTED]  2007-04-26 23:02 ---
I have updated the summary to better describe the problem.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 42271] New: - Scp Task Block When Send Directories

[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://issues.apache.org/bugzilla/show_bug.cgi?id=42271

   Summary: Scp Task Block When Send Directories
   Product: Ant
   Version: 1.7.0
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Optional Tasks
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


Sample:

  


This case can work with "Ant 1.7.0 + jsch-0.1.29.jar",
but can't work with "Ant 1.7.0 + (jsch-0.1.30 ~ 0.1.32)".

This task would be blocked after transmition finished with jsch library 0.1.30
or later.

Raymond Wu. Tapiei

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

[EMAIL PROTECTED]: Project test-ant-no-xerces (in module ant) failed

[Gump Integration Build]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project test-ant-no-xerces has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 4 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- test-ant-no-xerces :  Java based build tool


Full details are available at:
http://vmgump.apache.org/gump/public/ant/test-ant-no-xerces/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason build failed



The following work was performed:
http://vmgump.apache.org/gump/public/ant/test-ant-no-xerces/gump_work/build_ant_test-ant-no-xerces.html
Work Name: build_ant_test-ant-no-xerces (Type: Build)
Work ended in a state of : Failed
Elapsed: 15 mins 32 secs
Command Line: java -Djava.awt.headless=true org.apache.tools.ant.Main 
-Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only 
-Dtest.haltonfailure=false -Dant.home=/usr/local/gump/public/workspace/ant/dist 
run-tests 
[Working Directory: /usr/local/gump/public/workspace/ant]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/build/testcases:/usr/local/gump/public/workspace/ant/src/tests/junit:/usr/local/gump/public/workspace/ant/src/etc/testcases:/usr/local/gump/public/workspace/ant/build/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-javamail.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-apache-bcel.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-apache-regexp.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-commons-net.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-jsch.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-apache-log4j.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-antlr.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-commons-logging.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-jdepend.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-apache-bsf.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-apache-oro.jar:/usr/local/gump/public/workspace/ant/build/lib/ant.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-jai.jar:/usr/local/gump/packages/antlr-2.7.6/antlr.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-26042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-26042007.jar:/usr/local/gump/public/workspace/jakarta-commons/net/dist/commons-net-26042007.jar:/usr/local/gump/packages/jaf-1.1ea/activation.jar:/usr/local/gump/packages/bcel-5.2/bcel-5.2.jar:/usr/local/gump/public/workspace/jakarta-bsf/build/lib/bsf.jar:/usr/local/gump/public/workspace/logging-log4j/dist/lib/log4j-26042007.jar:/usr/local/gump/public/workspace/jakarta-oro/jakarta-oro-26042007.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-26042007.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/packages/javamail-1.4/mail.jar:/usr/local/gump/packages/javamail-1.4/lib/mailapi.jar:/usr/local/gump/packages/jdepend-2.6/lib/jdepend.jar:/usr/local/gump/packages/jsch/jsch-0.1.28.jar:/usr/local/gump/public/workspace/xml-stylebook/bin/stylebook-1.0-b3_xalan-2.jar:/usr/local/gump/public/workspace/ant-antlibs/antunit/build/ant-antunit-26042007.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/jakarta-tomcat-4.0/dist/common/lib/jasper-compiler.jar:/usr/local/gump/public/workspace/jakarta-tomcat-4.0/dist/common/lib/jasper-runtime.jar:/usr/local/gump/public/workspace/xml-commons/java/build/which.jar:/usr/local/gump/public/workspace/rhino/build/rhino_26042007/js.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/usr/local/gump/public/workspace/jakarta-commons/codec/dist/commons-codec-26042007.jar
-
[au:antunit] Target: testfirst2 took 0.003 sec
[au:

DO NOT REPLY [Bug 42264] - env properties not returning values

[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://issues.apache.org/bugzilla/show_bug.cgi?id=42264


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2007-04-26 10:42 ---
That works, thanks.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

[EMAIL PROTECTED]: Project test-ant (in module ant) failed

[Gump Integration Build]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project test-ant has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 4 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- test-ant :  Java based build tool


Full details are available at:
http://vmgump.apache.org/gump/public/ant/test-ant/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason build failed



The following work was performed:
http://vmgump.apache.org/gump/public/ant/test-ant/gump_work/build_ant_test-ant.html
Work Name: build_ant_test-ant (Type: Build)
Work ended in a state of : Failed
Elapsed: 12 mins 30 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dtest.haltonfailure=false 
-Dant.home=/usr/local/gump/public/workspace/ant/dist run-tests 
[Working Directory: /usr/local/gump/public/workspace/ant]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant/build/testcases:/usr/local/gump/public/workspace/ant/src/tests/junit:/usr/local/gump/public/workspace/ant/src/etc/testcases:/usr/local/gump/public/workspace/ant/build/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-javamail.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-apache-bcel.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-apache-regexp.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-commons-net.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-jsch.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-apache-log4j.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-antlr.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-commons-logging.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-jdepend.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-apache-bsf.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-apache-oro.jar:/usr/local/gump/public/workspace/ant/build/lib/ant.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-jai.jar:/usr/local/gump/packages/antlr-2.7.6/antlr.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-26042007.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-26042007.jar:/usr/local/gump/public/workspace/jakarta-commons/net/dist/commons-net-26042007.jar:/usr/local/gump/packages/jaf-1.1ea/activation.jar:/usr/local/gump/packages/bcel-5.2/bcel-5.2.jar:/usr/local/gump/public/workspace/jakarta-bsf/build/lib/bsf.jar:/usr/local/gump/public/workspace/logging-log4j/dist/lib/log4j-26042007.jar:/usr/local/gump/public/workspace/jakarta-oro/jakarta-oro-26042007.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-26042007.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/packages/javamail-1.4/mail.jar:/usr/local/gump/packages/javamail-1.4/lib/mailapi.jar:/usr/local/gump/packages/jdepend-2.6/lib/jdepend.jar:/usr/local/gump/packages/jsch/jsch-0.1.28.jar:/usr/local/gump/public/workspace/xml-stylebook/bin/stylebook-1.0-b3_xalan-2.jar:/usr/local/gump/public/workspace/ant-antlibs/antunit/build/ant-antunit-26042007.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/usr/local/gump/public/workspace/jakarta-tomcat-4.0/dist/common/lib/jasper-compiler.jar:/usr/local/gump/public/workspace/jakarta-tomcat-4.0/dist/common/lib/jasper-runtime.jar:/usr/local/gump/public/workspace/xml-commons/java/build/which.jar:/usr/local/gump/public/workspace/rhino/build/rhino_26042007/js.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/usr/local/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/usr/local/gump/packages/b

Re: DO NOT REPLY [Bug 42219] - Inefficient code in Union, DirectoryScanner makes large copy tasks very slow

[Alexey Solofnenko]

I would use inheritance instead of facades.

- Alexey.

On 4/26/07, Steve Loughran <[EMAIL PROTECTED]> wrote:


Alexey N. Solofnenko wrote:
> Classpath ordering is a usual practice that is used, for example, for
> patching.

yes, and it doesnt work with signed JARs. And, because  doesnt
impose an order, you can't guarantee the order of use.


  The same classpath order could be used in debugger too. In our
> case it could be hidden inside launcher. But there are other ways to
> achieve the same - for example, factories that can return Java6 specific
> FileResource, but it is cumbersome:
> (FileResource)project.createObject("org.apacheFileResource"). The
> later has its advantages too - project could configure the class to
> support permissions or not.

Facades, all you need are facades. More indirection.


>
> This follows to settings. I think we could put the settings in the
> project class (as get/set methods or somehow else) - support or not
> permissions, old/new behaviour is not a property of the environment, but
> it is a property of a specific build script.

hmmm.

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





--
Alexey N. Solofnenko
Home: http://trelony.cjb.net/
Pleasant Hill, CA (GMT-8 usually)

Re: DO NOT REPLY [Bug 42219] - Inefficient code in Union, DirectoryScanner makes large copy tasks very slow

[Steve Loughran]

Alexey N. Solofnenko wrote:
Classpath ordering is a usual practice that is used, for example, for 
patching.


yes, and it doesnt work with signed JARs. And, because  doesnt 
impose an order, you can't guarantee the order of use.



 The same classpath order could be used in debugger too. In our
case it could be hidden inside launcher. But there are other ways to 
achieve the same - for example, factories that can return Java6 specific 
FileResource, but it is cumbersome: 
(FileResource)project.createObject("org.apacheFileResource"). The 
later has its advantages too - project could configure the class to 
support permissions or not.


Facades, all you need are facades. More indirection.




This follows to settings. I think we could put the settings in the 
project class (as get/set methods or somehow else) - support or not 
permissions, old/new behaviour is not a property of the environment, but 
it is a property of a specific build script.


hmmm.

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

Re: DO NOT REPLY [Bug 42219] - Inefficient code in Union, DirectoryScanner makes large copy tasks very slow

[Alexey N. Solofnenko]

Classpath ordering is a usual practice that is used, for example, for 
patching. The same classpath order could be used in debugger too. In our 
case it could be hidden inside launcher. But there are other ways to 
achieve the same - for example, factories that can return Java6 specific 
FileResource, but it is cumbersome: 
(FileResource)project.createObject("org.apacheFileResource"). The 
later has its advantages too - project could configure the class to 
support permissions or not.


This follows to settings. I think we could put the settings in the 
project class (as get/set methods or somehow else) - support or not 
permissions, old/new behaviour is not a property of the environment, but 
it is a property of a specific build script.


- Alexey.

Steve Loughran wrote:

Alexey N. Solofnenko wrote:

Relying on order of stuff in classloaders is just wrong.
-gets complicated when you bring signing into the bix
-gets complex when the IDE sets up the build order
-makes debugging a PITA.


I think we should not limit supported features supported by modern 
Java while keeping backward compatibility with older versions. One 
way is to use reflection. Another is to provide an alternative 
implementation of some classes (FileResource) to be used with modern 
Java. The later is straightforward, but the most recent Java is 
required to build it.


That's effectively what we do at build time...you need to build under 
1.5 to get everything compiled, though we omit the stuff to let people 
still build on java 1.3+.


For the proxy diagnostics, I abuse the toString() method, so we just 
cast the proxy diags to a method and do it from there. For the other 
stuff, well, there's nothing to stop FileUtils looking for a subclass 
of itself if it is there




If something could be done better with modern Java, why not to use it 
when possible?


Only one reason: when it makes backwards compatibility odd, or screws 
up x-platformness. For example, for all the failings with file perms 
on java, requiring people to spec permissions when tarring a folder 
guarantees that the permissions in the tar get set in all platforms


At the same time, sometimes I do want copy to preserve stuff, untar to 
propagate permissions, at least on unix. I may even want to use file 
permissions as a selector, selecting all files that are executable for 
some further action. As long as people understand the operations are 
not portable, well, they have the right to use them.


Perhaps a limited set of operations could have permissions enabled, 
with some enum like
permissions="always"   - copy all perms, fail if we are a windows box 
or if the build doesnt allow it (wrong JVM, wrong class file)

permissions="never" -the default
permissions="optional"  -copy perms if the JVM is right and the OS 
supports perms.


we could also add another Permissions interface to resources, so you 
can read/write perms of files. This would work inside zip/tar files 
today, and on filesystem files on Java6+unix.


I worry about what cygwin does here...how does it manage permissions? 
Because people are going to be disappointed if they expect ant to 
handle it.

-Steve



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


--

Alexey N. Solofnenko 
Pleasant Hill, CA (GMT-8 usually)


smime.p7s
Description: S/MIME Cryptographic Signature

Re: JIRA/gmail threading

[Steve Loughran]

Jeff Turner wrote:

On Tue, Apr 24, 2007 at 11:56:53AM -0500, Dominique Devienne wrote:

On 4/24/07, Alexey Solofnenko <[EMAIL PROTECTED]> wrote:
GMail itself does not honour threading info. For each bug, I get two 
message

threads - one with "NEW" and another with continuation. The thread is also
broken in GMail, if the title is changed.  There is no such problem in
Thunderbird.

True enough, GMail does get confused sometimes, and put the NEW email
separately from the rest of the thread, but it works often enough to
be useful. Does Thunderbird do proper threading with JIRA emails? In
any case, I prefer online access from anywhere to these mails, so
Thunderbird is not really on option for me.

Hopefully someone who knows JIRA well can tell me it does do threading
correctly, to remove my objection (or I should say plays nice with
GMail). --DD


JIRA appends an In-Reply-To:  headers to replies, just as RFC
2822 says it should. This results in threading in Thunderbird and
(AFAIK) most other mail clients, including Outlook.

GMail appears to simply rely on the Subject. This seems plain broken to
me, even for regular usage. Eg. in this mail I've changed the subject to
reflect the change in focus, but it's still the same thread (as
evidenced by the In-Reply-To), and mail clients should reflect that.


Maybe they thought they knew better, to stop 'thread hijacking' where 
you reply to a message with a completely different subject and message 
body. Maybe being a search engine vendor, everything is a search 
problem, just as with MS, everything is something you should get at by 
double clicking on icons in a GUI.




If anyone knows of magic headers to get GMail to thread mails with
different subjects, please let me know and we'll add it to JIRA.
Otherwise I guess there will have to be a "Use uninformative subjects"
flag to appease gmail.



That would suit this team's needs very well.

-steve



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

[Vote] move defect tracking from bugzilla to Jira

[Steve Loughran]

Here's the results of the vote:


Matt +1
Martijn -0.
Bruce Atherton +1
DD: -0 or -0.5
Stefan: 0 ( I guess)
Jan Materne: -1
Alexey -0

Enough negativety to block it, the key issue being threading under 
gmail. I hadnt noticed that because I dont route jira mail to those 
accounts, but I clearly understand how it can be an issue, especially on 
a busy project.


so, bugzilla it is :) When Jira adds gmail support, or gmail embraces 
message IDs, then we can look at the issue again.


-steve

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

DO NOT REPLY [Bug 41596] - ant 1.7 tar and bzip2 tasks corrupted output file when size exceeds certain limit

[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://issues.apache.org/bugzilla/show_bug.cgi?id=41596





--- Additional Comments From [EMAIL PROTECTED]  2007-04-26 08:52 ---
(In reply to comment #0)
> Description:
> 
> Ant tar task with bzip2 compression option or ant bzip2 task generates
> corrupted output for filesize of roughly 170+MB (before compression).
> 
> This problem occurs with ant version 1.7 installed in 12/06.
> Tested on linux with both jdk 1.5 and jdk 1.6
> 
> Work around: replace  or 
>  with 2 steps:  and 
> 
> For example,
> 
>  Replace this:
>  destfile="${out.file}.dmp.tar.bz2">
>   
> 
>   
> 
>  Or this:
>  compression="bzip2">
>   
> 
>   
> 
> 
> 
>  With:
> 
> 
>   
> 
>   
> 
> 
>  executable="bzip2">
> 
> 

(In reply to comment #3)
> I can't attach the testcase, since its compressed size (1.4M) exceeds the
> bugzilla limit for uploads. Does anyone have a server where I can upload and
> link it?


I believe it's the content specific.  However I couldn't upload our data because
it's confidential.  Your testcase is crucial in this case.
Hopefully ant developers will contact you to get your testcase.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: DO NOT REPLY [Bug 42219] - Inefficient code in Union, DirectoryScanner makes large copy tasks very slow

[Steve Loughran]

Alexey N. Solofnenko wrote:

Relying on order of stuff in classloaders is just wrong.
-gets complicated when you bring signing into the bix
-gets complex when the IDE sets up the build order
-makes debugging a PITA.


I think we should not limit supported features supported by modern Java 
while keeping backward compatibility with older versions. One way is to 
use reflection. Another is to provide an alternative implementation of 
some classes (FileResource) to be used with modern Java. The later is 
straightforward, but the most recent Java is required to build it.


That's effectively what we do at build time...you need to build under 
1.5 to get everything compiled, though we omit the stuff to let people 
still build on java 1.3+.


For the proxy diagnostics, I abuse the toString() method, so we just 
cast the proxy diags to a method and do it from there. For the other 
stuff, well, there's nothing to stop FileUtils looking for a subclass of 
itself if it is there




If something could be done better with modern Java, why not to use it 
when possible?


Only one reason: when it makes backwards compatibility odd, or screws up 
x-platformness. For example, for all the failings with file perms on 
java, requiring people to spec permissions when tarring a folder 
guarantees that the permissions in the tar get set in all platforms


At the same time, sometimes I do want copy to preserve stuff, untar to 
propagate permissions, at least on unix. I may even want to use file 
permissions as a selector, selecting all files that are executable for 
some further action. As long as people understand the operations are not 
portable, well, they have the right to use them.


Perhaps a limited set of operations could have permissions enabled, with 
some enum like
permissions="always"   - copy all perms, fail if we are a windows box or 
if the build doesnt allow it (wrong JVM, wrong class file)

permissions="never"   -the default
permissions="optional"  -copy perms if the JVM is right and the OS 
supports perms.


we could also add another Permissions interface to resources, so you can 
read/write perms of files. This would work inside zip/tar files today, 
and on filesystem files on Java6+unix.


I worry about what cygwin does here...how does it manage permissions? 
Because people are going to be disappointed if they expect ant to handle it.

-Steve



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

DO NOT REPLY [Bug 42264] - env properties not returning values

[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://issues.apache.org/bugzilla/show_bug.cgi?id=42264


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |NEEDINFO




--- Additional Comments From [EMAIL PROTECTED]  2007-04-26 08:01 ---
Have you used  first?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

[EMAIL PROTECTED]: Project svn-antlib-test (in module ant-antlibs) failed

[Gump Integration Build]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project svn-antlib-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 162 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- svn-antlib-test :  Task and Type Libraries for Apache Ant


Full details are available at:
http://vmgump.apache.org/gump/public/ant-antlibs/svn-antlib-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on ant-testutil exists, no need to add for property 
ant-testutil.jar.
 -INFO- Failed with reason build failed



The following work was performed:
http://vmgump.apache.org/gump/public/ant-antlibs/svn-antlib-test/gump_work/build_ant-antlibs_svn-antlib-test.html
Work Name: build_ant-antlibs_svn-antlib-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 18 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only 
-Dant-testutil.jar=/usr/local/gump/public/workspace/ant/build/lib/ant-testutil.jar
 test 
[Working Directory: /usr/local/gump/public/workspace/ant-antlibs/svn]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/ant-antlibs/svn/build/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant/build/lib/ant-testutil.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/ant-antlibs/svn/build/ant-svn-26042007.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar
-
[junit] at junit.framework.TestSuite.run(TestSuite.java:227)
[junit] at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:76)
[junit] at 
junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:32)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:421)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:912)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743)
[junit] 
[junit] Testcase: testDiffWithImplicitTrunk took 18.104 sec
[junit] FAILED
[junit] null
[junit] junit.framework.AssertionFailedError: null
[junit] at junit.framework.Assert.fail(Assert.java:47)
[junit] at junit.framework.Assert.assertTrue(Assert.java:20)
[junit] at junit.framework.Assert.assertTrue(Assert.java:27)
[junit] at 
org.apache.ant.svn.SvnTagDiffTest.assertModified(SvnTagDiffTest.java:110)
[junit] at 
org.apache.ant.svn.SvnTagDiffTest.assertDiffWithTrunk(SvnTagDiffTest.java:63)
[junit] at 
org.apache.ant.svn.SvnTagDiffTest.testDiffWithImplicitTrunk(SvnTagDiffTest.java:57)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:585)
[junit] at junit.framework.TestCase.runTest(TestCase.java:168)
[junit] at junit.framework.TestCase.runBare(TestCase.java:134)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:110)
[junit] at junit.framework.TestResult.runProtected(TestResult.java:128)
[junit] at junit.framework.TestResult.run(TestResult.java:113)
[junit] at junit.framework.TestCase.run(TestCase.java:124)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:232)
[junit] at junit.framework.TestSuite.run(TestSuite.java:227)
[junit] at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:76)
[junit] at 
junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:32)
[junit] at 
org.apach

DO NOT REPLY [Bug 42264] New: - env properties not returning values

[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://issues.apache.org/bugzilla/show_bug.cgi?id=42264

   Summary: env properties not returning values
   Product: Ant
   Version: 1.6.5
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Core
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


Values such as ${env.TMPDIR} are not returning values in tasks, they show as
undefined (${env.TMPDIR} instead of /tmp). I have several environment variables
defined in my shell, but none of them can be accessed using the ${env.VAR} 
notation.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 42263] New: - built-in property ${ant.version} not set in a call with subant

[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://issues.apache.org/bugzilla/show_bug.cgi?id=42263

   Summary: built-in property ${ant.version} not set in a call with
subant
   Product: Ant
   Version: 1.7.0
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Core tasks
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


when calling subant without inheritall="true" ant.version is not set.

example

top level build file:

   
   
   


and in the build file specified by the path "subpath":

   
   




The output of "ant test" is:

test project
Apache Ant version 1.7.0 compiled on December 13 2006
test project subcomponent
${ant.version}

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41596] - ant 1.7 tar and bzip2 tasks corrupted output file when size exceeds certain limit

[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://issues.apache.org/bugzilla/show_bug.cgi?id=41596





--- Additional Comments From [EMAIL PROTECTED]  2007-04-26 06:57 ---
I can't attach the testcase, since its compressed size (1.4M) exceeds the
bugzilla limit for uploads. Does anyone have a server where I can upload and
link it?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41596] - ant 1.7 tar and bzip2 tasks corrupted output file when size exceeds certain limit

[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://issues.apache.org/bugzilla/show_bug.cgi?id=41596


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 41596] - ant 1.7 tar and bzip2 tasks corrupted output file when size exceeds certain limit

[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://issues.apache.org/bugzilla/show_bug.cgi?id=41596


[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|Linux   |All




--- Additional Comments From [EMAIL PROTECTED]  2007-04-26 06:38 ---
I've run into the same problem with the bzip2 task. The src file was originally
837MB, but through repeatedly splitting the file I could create a 22MB test file
which when bzipped with the ant task creates a corrupt bz2 file (verified with
bzip2 -t). I'll attach this file as a testcase. If I cut the file to 21MB, ant
creates a working bz2 file.

I could reproduce this error on both Windows XP and Linux, so I changed the OS
field to "All".

The error happens with both Java 1.5.0_10 and Java 1.6.0. I also tested the
following ant versions:

Corrupted bz2 file:
Apache Ant version 1.7.1alpha compiled on April 25 2007 (nightly build)
Apache Ant version 1.7.0 compiled on December 13 2006

Working:
Apache Ant version 1.6.5 compiled on June 2 2005

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 42259] - Class loading speed can simply be improved in AntClassLoader.java

[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://issues.apache.org/bugzilla/show_bug.cgi?id=42259





--- Additional Comments From [EMAIL PROTECTED]  2007-04-26 01:57 ---
Created an attachment (id=20049)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20049&action=view)
patch for a proposal to fix this issue


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

RE: class loading speed can be improved in AntClassLoader.java

[Brus, Tom]

I created a bugzilla for this:
http://issues.apache.org/bugzilla/show_bug.cgi?id=42259

> -Original Message-
> From: Brus, Tom [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 26, 2007 09:55
> To: Ant Developers List
> Subject: RE: class loading speed can be improved in
AntClassLoader.java
> 
> Sounds sensible and more traceable ;)
> I will do that later today.
> 
> -Tom
> 
> > -Original Message-
> > From: Jeffrey E Care [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, April 26, 2007 00:44
> > To: Ant Developers List
> > Subject: RE: class loading speed can be improved in
> AntClassLoader.java
> >
> > It may be better to open a feature request in bugzilla and attach
the
> > patch there.
> >
> >
>

> __
> > __
> >
> > Jeffrey E. (Jeff) Care
> > [EMAIL PROTECTED]
> > IBM WebSphere Application Server
> > Systems Management Tools Architecture & Development
> >
> >
> >
> >
> >
> >
> >
> > "Brus, Tom" <[EMAIL PROTECTED]>
> > 04/25/2007 01:29 PM
> > Please respond to
> > "Ant Developers List" 
> >
> >
> > To
> > "Ant Developers List" 
> > cc
> >
> > Subject
> > RE: class loading speed can be improved in AntClassLoader.java
> >
> >
> >
> >
> >
> >
> > > From: Peter Reilly [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, April 25, 2007 15:24
> > >
> > > This sounds useful,
> > > can you provide a patch please?
> >
> > With pleasure (also attached in case there are line wrapping
> problems):
> >
> > = snip snip ===
> > diff -Naur old/org/apache/tools/ant/AntClassLoader.java
> > new/org/apache/tools/ant/AntClassLoader.java
> > --- old/org/apache/tools/ant/AntClassLoader.java2006-12-13
> > 06:16:00.0 +0100
> > +++ new/org/apache/tools/ant/AntClassLoader.java2007-04-25
> > 19:17:46.546875000 +0200
> > @@ -799,19 +799,16 @@
> >   */
> >  private InputStream getResourceStream(File file, String
> > resourceName) {
> >  try {
> > -if (!file.exists()) {
> > -return null;
> > -}
> > -
> > -if (file.isDirectory()) {
> > +// is it a file in the zipfile cache
> > +ZipFile zipFile = (ZipFile) zipFiles.get(file);
> > +if (zipFile==null && file.isDirectory()) {
> > +// not in the cache, but it is a dir
> >  File resource = new File(file, resourceName);
> > -
> >  if (resource.exists()) {
> >  return new FileInputStream(resource);
> >  }
> > -} else {
> > -// is the zip file in the cache
> > -ZipFile zipFile = (ZipFile) zipFiles.get(file);
> > +} else if (zipFile!=null || file.exists()) {
> > +// found in the cache or not yet in the cache but
> > existing
> >  if (zipFile == null) {
> >  zipFile = new ZipFile(file);
> >  zipFiles.put(file, zipFile);
> > @@ -994,13 +991,11 @@
> >   */
> >  protected URL getResourceURL(File file, String resourceName) {
> >  try {
> > -if (!file.exists()) {
> > -return null;
> > -}
> > -
> > -if (file.isDirectory()) {
> > +// is it a file in the zipfile cache
> > +ZipFile zipFile = (ZipFile) zipFiles.get(file);
> > +if (zipFile==null && file.isDirectory()) {
> > +// not in the cache, but it is a dir
> >  File resource = new File(file, resourceName);
> > -
> >  if (resource.exists()) {
> >  try {
> >  return FILE_UTILS.getFileURL(resource);
> > @@ -1008,13 +1003,12 @@
> >  return null;
> >  }
> >  }
> > -} else {
> > -ZipFile zipFile = (ZipFile) zipFiles.get(file);
> > +} else if (zipFile!=null || file.exists()) {
> > +// found in the cache or not yet in the cache but
> > existing
> >  if (zipFile == null) {
> >  zipFile = new ZipFile(file);
> >  zipFiles.put(file, zipFile);
> >  }
> > -
> >  ZipEntry entry = zipFile.getEntry(resourceName);
> >  if (entry != null) {
> >  try {
> > = snip snip ===
> > > Hi,
> > >
> > > We have a lot of classes that are loaded by the AntClassLoader.
From
> > > performance measurements I noticed that a lot of time was spend in
> > > File.exists() during class loading. I checked the code and noticed
> > that
> > > in:
> > >
> > >  InputStream getResourceStream  (File file, String
> resourceName);
> > >
> > > and in
> > >
> > >  URL getResourceURL (File file, String
> resourceName);
> > >
> > > The following check is done first:
> > >
> > >  if (!file.ex

DO NOT REPLY [Bug 42259] New: - Class loading speed can simply be improved in AntClassLoader.java

[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://issues.apache.org/bugzilla/show_bug.cgi?id=42259

   Summary: Class loading speed can simply be improved in
AntClassLoader.java
   Product: Ant
   Version: 1.7.0
  Platform: Other
OS/Version: other
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Core
AssignedTo: dev@ant.apache.org
ReportedBy: [EMAIL PROTECTED]


As send earlier on the mailing list:

We have a lot of classes that are loaded by the AntClassLoader. From performance
measurements I noticed that a lot of time was spend in
File.exists() during class loading. I checked the code and noticed that
in:

 InputStream getResourceStream  (File file, String resourceName);

and in

 URL getResourceURL (File file, String resourceName);

The following check is done first:

 if (!file.exists()) {
 return null;
 }

This seems smart, because if the file does not exist the answer is clear. Unless
of course 'exists()' is slow; which it turns out to be (on Windows at least). A
considerable improvement can be accomplished by first checking the 'zipFiles'
Hashtable: if "zipFiles.get(file)" returns non-null we can be sure that the file
exists and that it is not a directory. Remember that most calls will be for a
jar file that has already been opened. So those expensive (compared to
Hashtable.get()) tests on File can be skipped most of the time.

One of our test runs was reduced by 1/3 in runtime by a quick patch I made (it
loads thousands of classes...).

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [Vote] move defect tracking from bugzilla to Jira

[Jeff Turner]

On Tue, Apr 24, 2007 at 08:45:58PM +0200, Stefan Bodewig wrote:
> On Tue, 24 Apr 2007, Steve Loughran <[EMAIL PROTECTED]> wrote:
> 
> > The fact that people are running automation experiments on bugzilla
> > makes me think that now is a good time to move to Jira.
> 
> Other ASF projects have already dealt with JIRA spam, I don't see us
> getting away from this problem by switching.

FWIW, CAPTCHAs on account signup were implemented in 3.8 to deal with
spam. Apache just hasn't upgraded to it yet (and hasn't been spammed in a
while either).


--Jeff

> > Accordinly, I would like to call a vote about moving to JIRA
> > 
> > [] Yes, move to JIRA
> > [] No, stay with Bugzilla
> 
> I'm on the fence here, I can live with, but am not too happy with
> either.
> 
> Stefan

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

RE: class loading speed can be improved in AntClassLoader.java

[Brus, Tom]

Sounds sensible and more traceable ;)
I will do that later today.

-Tom

> -Original Message-
> From: Jeffrey E Care [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 26, 2007 00:44
> To: Ant Developers List
> Subject: RE: class loading speed can be improved in
AntClassLoader.java
> 
> It may be better to open a feature request in bugzilla and attach the
> patch there.
> 
>

__
> __
> 
> Jeffrey E. (Jeff) Care
> [EMAIL PROTECTED]
> IBM WebSphere Application Server
> Systems Management Tools Architecture & Development
> 
> 
> 
> 
> 
> 
> 
> "Brus, Tom" <[EMAIL PROTECTED]>
> 04/25/2007 01:29 PM
> Please respond to
> "Ant Developers List" 
> 
> 
> To
> "Ant Developers List" 
> cc
> 
> Subject
> RE: class loading speed can be improved in AntClassLoader.java
> 
> 
> 
> 
> 
> 
> > From: Peter Reilly [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, April 25, 2007 15:24
> >
> > This sounds useful,
> > can you provide a patch please?
> 
> With pleasure (also attached in case there are line wrapping
problems):
> 
> = snip snip ===
> diff -Naur old/org/apache/tools/ant/AntClassLoader.java
> new/org/apache/tools/ant/AntClassLoader.java
> --- old/org/apache/tools/ant/AntClassLoader.java2006-12-13
> 06:16:00.0 +0100
> +++ new/org/apache/tools/ant/AntClassLoader.java2007-04-25
> 19:17:46.546875000 +0200
> @@ -799,19 +799,16 @@
>   */
>  private InputStream getResourceStream(File file, String
> resourceName) {
>  try {
> -if (!file.exists()) {
> -return null;
> -}
> -
> -if (file.isDirectory()) {
> +// is it a file in the zipfile cache
> +ZipFile zipFile = (ZipFile) zipFiles.get(file);
> +if (zipFile==null && file.isDirectory()) {
> +// not in the cache, but it is a dir
>  File resource = new File(file, resourceName);
> -
>  if (resource.exists()) {
>  return new FileInputStream(resource);
>  }
> -} else {
> -// is the zip file in the cache
> -ZipFile zipFile = (ZipFile) zipFiles.get(file);
> +} else if (zipFile!=null || file.exists()) {
> +// found in the cache or not yet in the cache but
> existing
>  if (zipFile == null) {
>  zipFile = new ZipFile(file);
>  zipFiles.put(file, zipFile);
> @@ -994,13 +991,11 @@
>   */
>  protected URL getResourceURL(File file, String resourceName) {
>  try {
> -if (!file.exists()) {
> -return null;
> -}
> -
> -if (file.isDirectory()) {
> +// is it a file in the zipfile cache
> +ZipFile zipFile = (ZipFile) zipFiles.get(file);
> +if (zipFile==null && file.isDirectory()) {
> +// not in the cache, but it is a dir
>  File resource = new File(file, resourceName);
> -
>  if (resource.exists()) {
>  try {
>  return FILE_UTILS.getFileURL(resource);
> @@ -1008,13 +1003,12 @@
>  return null;
>  }
>  }
> -} else {
> -ZipFile zipFile = (ZipFile) zipFiles.get(file);
> +} else if (zipFile!=null || file.exists()) {
> +// found in the cache or not yet in the cache but
> existing
>  if (zipFile == null) {
>  zipFile = new ZipFile(file);
>  zipFiles.put(file, zipFile);
>  }
> -
>  ZipEntry entry = zipFile.getEntry(resourceName);
>  if (entry != null) {
>  try {
> = snip snip ===
> > Hi,
> >
> > We have a lot of classes that are loaded by the AntClassLoader. From
> > performance measurements I noticed that a lot of time was spend in
> > File.exists() during class loading. I checked the code and noticed
> that
> > in:
> >
> >  InputStream getResourceStream  (File file, String
resourceName);
> >
> > and in
> >
> >  URL getResourceURL (File file, String
resourceName);
> >
> > The following check is done first:
> >
> >  if (!file.exists()) {
> >  return null;
> >  }
> >
> > This seems smart, because if the file does not exist the answer is
> > clear. Unless of course 'exists()' is slow; which it turns out to be
> (on
> > Windows at least). A considerable improvement can be accomplished by
> > first checking the 'zipFiles' Hashtable: if "zipFiles.get(file)"
> returns
> > non-null we can be sure that the file exists and that it is not a
> > directory. Remember that most calls will be for a jar file that has
> > already been opened. So those expensive (compared to
Hashtable.get())
> > tests on