DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15310>. 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=15310 jar task very slow for large input lists Summary: jar task very slow for large input lists Product: Ant Version: 1.5.1 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If you explicitly list many (e.g. 600+) entries in an includes file for a jar (or related, e.g. zip) task, the task executes *extremely* slowly. If you these same entries happen to be the only file in a directory tree and you thus skip using any sort of inclusion specification, the task executes quite quickly (on part with the JDK's jar command's execution of the same). If you pass the explicit includes list to the JDK's jar command (via the @ syntax), then the execution is just as fast as when the JDK's jar command is simply given the name of the root directory. This becomes an issue when other tools provide the list of files to be included (e.g. in a client jar) and the files, though quite numerous, are a scattered, sparse subset of the directory tree in question. I am currently using the JDK's jar command through exec as the jar task performs far too slowly. The jar task should not degrade *this* much through atypical usage. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
