codehaus-plexus
AbstractArchiver.getFiles returns platform-specific separators (for ZIP files)
The ZIP file spec says that only forward slashes should be used in entry names (https://stackoverflow.com/a/44387973) but in fact adding a directory on Windows with ZipArchiver.addFileSet(...) will lead to backslashes in the entry names returned by AbstractArchiver.getFiles().
This happens with plexus archiver 4.2.1.
For the actual ZIP generation the normalization is done by https://github.com/codehaus-plexus/plexus-archiver/blob/b9ea3bf0e4c25c0a5cf1bcbc76e691067003dc36/src/main/java/org/codehaus/plexus/archiver/zip/AbstractZipArchiver.java#L370. This is not called for getFiles() though.
Ok, the issue was that the check was performed on AbstractArchiver.getFiles() where the file name normalization has not happened yet. I wonder whether that is expected behaviour though. IMHO AbstractArchiver.getFiles() should already return the normalized names as keys.
Hi,
Sorry but I'm not quite sure if there is a bug in Plexus Archiver or you made it work? If you believe there is a bug would you please share a code snipped that reproduces the issue? I ran one of the tests on Windows and it looks like the resulting ZIP archive is with / as file path separator.
As for AbstractArchiver.getFiles() - it is common for all acrhivers so it also makes sense not to normalized the names and let the concrete implementation decide if such normalization is needed. Although I not quite sure if there is any benefit from storing the Windows separator in the archived file name even if the archive format supports it.
@plamentotev Indeed the generated ZIP file is correct (i.e. only contains forward slashes). It is just AbstractArchiver.getFiles() which behaves unexpectedly. I would expect the entry names as they appear in the Zip. If in case of all other archivers there is no normalization necessary you would probably need to overwrite that method only for ZipArchiver. In any case it would be very helpful if the javadoc for getFiles would be extended with regards to the file name format which could be expected here.
Yes, good point. Actually getFiles does not have any documentation at all. I might give it a try when I have more time. Contributions are welcome as well :)