Fix AbstractArchiver.getFiles() to return forward slashes for ZIP-based archivers

[Copilot]

Problem

The ZIP file specification requires that entry names use forward slashes (/) as path separators. However, AbstractArchiver.getFiles() was returning entry names with platform-specific separators (e.g., backslashes \ on Windows). While the actual ZIP files were created correctly with forward slashes (normalized in AbstractZipArchiver.addResources()), the getFiles() method returned inconsistent results that didn't match the actual archive entry names.

This caused issues when users called getFiles() to inspect archive entries before creation, as they would see platform-specific paths instead of the normalized paths that would appear in the final ZIP file.

Solution

This PR overrides getFiles() in AbstractZipArchiver to normalize path separators to forward slashes, ensuring consistency between the returned map and the actual ZIP entry names.

Example

Before this fix on Windows:

ZipArchiver archiver = new ZipArchiver();
archiver.addFile(file, "dir1/dir2/file.xml");
Map<String, ArchiveEntry> files = archiver.getFiles();
// Returns: "dir1\dir2\file.xml" (platform-specific backslashes)

After this fix:

ZipArchiver archiver = new ZipArchiver();
archiver.addFile(file, "dir1/dir2/file.xml");
Map<String, ArchiveEntry> files = archiver.getFiles();
// Returns: "dir1/dir2/file.xml" (forward slashes as per ZIP spec)

Changes

1. AbstractZipArchiver.java: Added override of getFiles() that normalizes all path separators to forward slashes
2. Archiver.java, AbstractArchiver.java: Enhanced javadoc to clarify path separator behavior
3. ZipArchiverTest.java: Added test to verify the fix works correctly

Impact

• Applies to all ZIP-based archivers: ZipArchiver, JarArchiver, and subclasses
• Backward compatible - only normalizes path separators, doesn't change functionality
• All existing tests pass

Fixes #244

Original prompt

---

This section details on the original issue you should resolve

<issue_title>AbstractArchiver.getFiles returns platform-specific separators (for ZIP files)</issue_title>
<issue_description>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.</issue_description>

Comments on the Issue (you are @copilot in this section)

@kwin 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. @kwin 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. @plamentotev 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.</comment_new>
<comment_new>@kwin
@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.</comment_new>
<comment_new>@plamentotev
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 :)</comment_new>

Fixes #129

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.