ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 19523] - zip/unzip should have the capability to use a mapper
Date Sun, 04 May 2003 22:05:54 GMT
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=19523>.
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=19523

zip/unzip should have the capability to use a mapper





------- Additional Comments From kovesp@sympatico.ca  2003-05-04 22:05 -------
After some work I think I now have a useable implementation of both features.
First, my selector request as stated earlier makes little sense. I shall now 
restate it, and describe my solution for both mappers and selectors. 

The real problems in the current implementation are:

1. ZipFileSet is ignoring selectors when using the src attribute (i.e. when 
the resources are being obtained from an existing archive). Not surprising, 
given that ZipScanner is ignoring selectors.

2. Assuming the above is fixed, there is still a conceptual problem for 
ZipGroupFileSet. The specified selectors would select among the archives 
specified and not the _contents_ of the archives.

Accordingly, here is my proposed solution:

1. ZipFileSet allows a nested <mapper> element. Any resource in the set has 
its name translated by the mapper before it is added to the target archive.

2. ZipGroupFileSet allows two new nested elements; clearly these are applied 
to the entries from the archives specified by the parent element.

a. <contentselector> which is a selector.
b. <contentmapper> which is a mapper.

Remarks:

1. This should probably be added at the AbstractFileSet level, I just didn't   
want to rock the boat too much.

2.a. A single selector is allowed. One can of course use nested selectors to 
get the most general effect. It would slos be possible to allow all current 
selectors with content prefixed to their name, but I thought that things like 
contentand and contentnone a bit strange.

I have implemented this on the 1.5.3 codebase as a custom Zip task. To 
implement it as a part of the standard build the following classes need to be 
modified
   Zip
   ZipFileSet
   ZipScanner
A new class
   ZipGroupFileSet
is introduced. 
The modification is quite small: 170 new lines and 8 modified lines.

I shall post the ant extension version today or tomorrow, the version 
integrated into the 1.6 code base about a day later.

I wish someone from dev would respond as to the chances of this getting into  
the 1.6 release.

Mime
View raw message