Add more options to exclude classes from the default JAXBContext

[gnieser]

Following this discussion, I would like to thank @Sgitario for his kind assistance and his invitation to try to contribute.

Here is a pull request with:

• A quarkus.jaxb.exclude-packages to exclude classes from given packages from the default JAXBContext
• A quarkus.jaxb.exclude-pattern to exclude classes whose names matches the pattern from the default JAXBContext

To reply to @Sgitario 's comment from the discussion:

Though, I would merge the exclude-classes and exclude-packages into exclude-classes (and use the startWith matching).

I'm thinking of cases such as classes named User and UserAccount, a startWith matching may not work as intended, if only the User class is to be excluded for some reason.

Moreover, I would not add pattern matching at least it's essential since we used not to try adding too many superficial configuration options.

The motivation behind pattern matching is to provide adequate tooling for developer using xjc with third-party XSD. The sheer number of classes can grow up pretty quickly and one have little control over them.

I agree having both exclude-packages and pattern matching is somehow redundant. Pattern matching can easily exclude packages.

Of course, I will proceed with what ever option you prefer. :)

[Sgitario]

Thanks for your pull request!
From my side, I have the same comments as in #31882 (reply in thread).

[gnieser]

What would you think of dropping pattern matching (exclude-pattern) and changing exclude-classes behavior to the following?

• if item ends with .* then assume it is a package and perform startsWith matching
• otherwise assume it is a class and perform equals matching

It would avoid collision when exclusion of a User class would incidentally also exclude a UserAccount class.

[Sgitario]

What would you think of dropping pattern matching (exclude-pattern) and changing exclude-classes behavior to the following?

• if item ends with .* then assume it is a package and perform startsWith matching
• otherwise assume it is a class and perform equals matching

It would avoid collision when exclusion of a User class would incidentally also exclude a UserAccount class.

Good idea!

[gnieser]

I've committed these changes.

I should also rebase and squash my two commits and force-push into single one, shouldn't I?

[Sgitario]

Yes, please

[gnieser]

Done, thanks for your patience.

[quarkus-bot]

✔️ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

[Sgitario]

lgtm!