Repository navigation
Filtering changed behaviour from 3.3.1 #471
Description
Affected version
3.4.0 and 3.5.0
Bug description
The following code works for us in 3.3.1 when use filter on a single file in our setup. When upgrading to 3.4.0 and 3.5.0 the following code has stopped working and no filtering is taking place in our file db/changelog/db.changelog-client-secret.xml
<resources>
<resource>
<filtering>true</filtering>
<directory>src/main/resources</directory>
<includes>
<include>db/changelog/db.changelog-client-secret.xml</include>
</includes>
</resource>
<resource>
<filtering>false</filtering>
<directory>src/main/resources</directory>
<includes>
<include>**</include>
</includes>
</resource>
</resources>
The file that is being filtered looks like this:
<property name="secret" value="${env.DEV_SECRET}" context="dev" />
<property name="secret" value="${env.PROD_SECRET}" context="prod" />
With 3.3.1 the values are replaced with the correct env variables and in the newer versions it is being unchanged.
This could also be incorrect configuration that we have that has happened to have been working in previous versions and might be a variation of this bug: #453 and submitting it as a new bug in case it is a user failure where we should have configured it differently.
Activity
rzo1 commentedon May 5, 2026
@mawiesne and I are experiencing a similar issue when performing property replacements in configuration files using the Maven Resource Plugin (3.5.0). It works with 3.3.1
rzo1 commentedon May 5, 2026
Here is an IT as reproducer: rzo1@396eda0
rzo1 commentedon May 5, 2026
I did a bisect and it points to 493aa46 which is bumping the maven-filtering dependency. The regression is therefore not in maven-resources-plugin itself but in the upstream org.apache.maven.shared:maven-filtering library, between its 3.3.1 and 3.3.2 releases.
Maybe you can have a look @slawekjaranowski ?
rzo1 commentedon May 5, 2026
Added some details in apache/maven-filtering#333 and bisected the commit, which introduced the change in behaviour. Guess it needs to be fixed in
maven-filtering(the repro IT could still be picked here, so it can be seen earlier).Add regression test for filtering with overlapping <resource> entries
Zialus commentedon Jun 30, 2026
I'm still running into this issue with version 3.5.0
cstamas commentedon Jun 30, 2026
IIUC:
rzo1 commentedon Jun 30, 2026
Yes @cstamas 😀
cstamas commentedon Jun 30, 2026
https://lists.apache.org/thread/dvnox6n2c6v5y1j4c5mqsxbl4qvd8d18
cstamas commentedon Jul 3, 2026
https://github.com/apache/maven-filtering/releases/tag/maven-filtering-3.5.1
Zialus commentedon Jul 26, 2026
Any chance we can get the dependency version bump?
cstamas commentedon Jul 26, 2026
It is done on 3.x branch, so you are asking about release?
As until then, you can just "redefine" maven resource plugin dependency, but explicitly adding dependency on maven-filtering 3.5.1 to it?
gnodet commentedon Sep 23, 2026
This was fixed by bumping
maven-filteringto 3.5.1 in commit 1f8a00e.The root cause was a regression introduced in
maven-filtering3.3.2 that broke the "first<resource>entry wins" semantics for overlapping resource declarations. It was fixed inmaven-filtering3.5.1 (see apache/maven-filtering#333 and apache/maven-filtering#334).The fix will be included in the upcoming
maven-resources-plugin3.5.1 release. In the meantime, you can work around it by adding an explicit dependency onmaven-filtering3.5.1 in the plugin's<dependencies>block.fix: restore first resource entry wins for overlapping declarations (…
fix: restore first resource entry wins for overlapping declarations (…