Narrow catch clause in createArchive()

[elharo]

Fixes #559

Replaces the broad catch (Exception e) in createArchive() with catch (MavenArchiverException | ArchiverException e), which are the specific checked exceptions declared by MavenArchiver.createArchive(). The // TODO: improve error handling comment is removed since the exception type is now correctly scoped.

[elharo]

ArchiverException needs to be caught too. Just because it can propagate does not mean it should propagate

[Copilot]

Pull request overview

This PR addresses issue #559 by narrowing exception handling in AbstractJarMojo#createArchive() so that it no longer catches a generic Exception while assembling the JAR, improving error specificity and avoiding unintended swallowing of unrelated runtime failures.

Changes:

• Replace catch (Exception e) with a narrower multi-catch for MavenArchiverException and ArchiverException.
• Remove the // TODO: improve error handling comment now that the catch block is scoped to archiver-related exceptions.
• Add the required ArchiverException import.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[slachiewicz]

To be addressed

[ascheman]

@elharo — reviewing as requested.

The narrowing itself looks correct: catch (MavenArchiverException | ArchiverException e) still compiles against throws MojoException, so no checked exception leaks, and I agree archiver failures should be wrapped rather than propagated raw.

My main point is sequencing rather than the diff: I'd suggest we merge #508 first and then re-evaluate #561. #508 rewrites createArchive() to write archive content via the JDK jar ToolProvider (keeping MavenArchiver only for the manifest), which removes both the catch block this PR narrows and the addDirectory(...) call on the following line. So once #508 lands, #561 is likely superseded entirely — re-evaluating afterwards avoids a guaranteed conflict and some throwaway work.

If #561 does proceed independently of #508, two small follow-ups:

• The PR description no longer matches the code (also the open "To be addressed" thread): it says the catch is narrowed to only MavenArchiverException and that ArchiverException is a RuntimeException that propagates — but the code multi-catches both, and plexus ArchiverException is a checked exception (extends Exception). Worth aligning the description with the code.
• Scout rule: the adjacent addDirectory(File, String[], String[]) is @Deprecated in plexus-archiver 4.12.0 (all four File-based overloads — "Will go away in next major version"). The non-deprecated form is:

  archiver.getArchiver().addFileSet(
      DefaultFileSet.fileSet(contentDirectory.toFile())
          .includeExclude(getIncludes(), getExcludes()));

Both are moot if we take the #508-first route.