Bug: Extra JARs and Artifacts were not subjected to filtering

[cstamas]

Bug: the extraJars and extraArtifacts were added to shaded JAR as is, without subjecting them to filtering.

[cstamas]

Related:

• Back to Java 8 tcurdt/jdependency#388
• Services are not handled tcurdt/jdependency#385

[elharo]

switching to Java 8 feels like a separate issue. Is there some reason it's in this PR?

[cstamas]

As ITs are busted without this change, at least I could not make ITs work locally (on Java 24, 21, etc).

[olamy]

LGTM

[elharo]

If all ITs are busted then that should be fixed first in a separate PR.

[olamy]

If all ITs are busted then that should be fixed first in a separate PR.

not sure to understand the reasoning? what would be the added value of adding extra work/waste of time with a separate PR??

It has been discovered the reason of the failure with Java 25 so it's fixed now.

[Bukama]

TBH I would like to see my "update Parent 47" draft (#781), I opend two weeks ago, to get done to work and merged, because it a) does not hide those big changes behind a "bugfix" b) sets up ITs to use parent version for lesser maintanence effort in the future (idea/request by @slawekjaranowski ). I just could not get it "green" 100% alone.

[Bukama]

Replace plugin versions in ITs with parent ones (see #781)

[Bukama]

Remove version. Was needed to fix Java 25 build in between, but compatible version is now part of parent

[olamy]

TBH I would like to see my "update Parent 47" draft (#781), I opend two weeks ago, to get done to work and merged, because it a) does not hide those big changes behind a "bugfix" b) sets up ITs to use parent version for lesser maintanence effort in the future (idea/request by @slawekjaranowski ). I just could not get it "green" 100% alone.

no worries. if you prefer this way. I was just thinking of expedite this and have it done and dusted.
Having a separate PR or not doesn't have any effect on users so up2u (it's just internal test which users doesn't know anything about)

[Bukama]

TBH I would like to see my "update Parent 47" draft (#781), I opend two weeks ago, to get done to work and merged, because it a) does not hide those big changes behind a "bugfix" b) sets up ITs to use parent version for lesser maintanence effort in the future (idea/request by @slawekjaranowski ). I just could not get it "green" 100% alone.

no worries. if you prefer this way. I was just thinking of expedite this and have it done and dusted. Having a separate PR or not doesn't have any effect on users so up2u (it's just internal test which users doesn't know anything about)

Sure. Splitting it, would it make change history more clearer for us - the maintainers. For users of the plugin the whole parent thing doesn't matter at all. They just consume a compiled and rleased artifact.

[elharo]

Standard best practice. PRs should be small and focused on one thing.

https://google.github.io/eng-practices/review/developer/small-cls.html
https://testing.googleblog.com/2024/07/in-praise-of-small-pull-requests.html

In the specific case of Maven, it helps a lot with code archaeology in the future. It has not escaped my notice that on another PR in surefire right now we are unable to understand why changes were made in a PR that did several things and only documented one of them, and consequently progress is blocked.

[cstamas]

I am about to merge this PR as:

• the actual bugfix was approved by @olamy
• the change requests by @Bukama and @elharo were about things not anymore present in this PR

I consider this PR "good to go"/