|
The idea with TAR support is to avoid loosing the execution flags on the executables.
Otherwise, we have to chmod the files we're interested in. The other drawback to is that most Linux distributions comes either in .tar.gz or .tar.bz2 flavors, so if we want to use such software we have to untar it then zip it. Maybe we could do two different things:
1/ just reuse the TAR stuff in Ant and not package a complete Ant lib 2/ package Ant and then "expose" many other tasks such as cvs/svn (so that instead of downloading from HTTP, we could simply checkout some binaries from a SCM repository), scp, and so on. Reusing the tar feature in Ant had been my plan. This easy actually pretty straightforward with classdepandjar. What amazed me was the amount of org.apache.tools.ant classes were determined as dependencies. With included ant classes rio.jar became 1.6 MB, without it rio.jar is 1.2 MB. Seems to be an awful lot of cruft for one capability.
At this point I am thinking of re-engineering the untar classes to make them lighter and less of an impact. To your other point, I had been leaning towards using Ivy or Maven to do part of this, also looking towards apache commons net to assist with ftp, and others. http://commons.apache.org/compress/
Tar files are now supported. The Apache Commons Compress project is used, and added as a 3rd party dependency.
Rio provides a best effort to handle the mode of the extracted files, modifying the file permissions accordingly. Care must be taken when using this feature if using Java 1.5, as the file permissions are not changed since the File.setReadable(), File.setWriteable() and File.setExecutable() were not added until Java 1.6 |
||||||||||||||||||||||||||||||||||||||||||||
What do others think? Is it an issue?