Re: central-publishing-maven-plugin breaks with Maven 3.10.0-rc-1 under Windows

--Apple-Mail=_4AB9974F-06D9-402A-ABD7-372699A2F64E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Andreas, all,

Thanks for the detailed report -- i looked into it, and the root cause =
is in
Maven Resolver rather than in the central-publishing plugin.

Since Resolver 2.0 (bundled by Maven 3.10.x and Maven 4.x) the default =
named-lock
factory is "file-lock", whereas Maven 3.9.x effectively used in-memory =
locks.
file-lock writes a ".locks" directory inside the local repository. On =
Windows those
0-byte lock files are not cleaned up and remain, so when the local repo =
is used as a
staging tree they get bundled and Central rejects the bundle (a ".locks" =
entry has no
".pom"). Maven 3.9.x produced no lock files at all -- which is why =
3.9.16 works for you.

Filed as: https://github.com/apache/maven-resolver/issues/2017

Workaround, restoring the 3.9.x behaviour (no lock files):

    -Daether.syncContext.named.factory=3Drwlock-local

Or, Windows-specific (force cleanup of the lock files):

    -Daether.named.file-lock.deleteLockFiles=3Dtrue

One caveat: the Windows leftover-files behaviour is actually documented =
as a deliberate
tweak (because of the JDK bug JDK-8252883 =
<https://bugs.openjdk.org/browse/JDK-8252883>), and a resolver =
maintainer has already pointed
to that on the issue. So this may well be a conscious decision -- the =
open question is
more whether file-lock should be the default for the common =
single-process case, and
whether the lock files should sit inside the local repository at all. =
Let's see what the
maintainers say.

Best regards,
Gerd


> On 28. Jul 2026, at 20:59, Andreas Kuhtz <[email protected]> =
wrote:
>=20
> Thanks for the suggestion.
> Adding .locks to .gitignore does not help. The error is the same.
>=20
> Am Di., 28. Juli 2026 um 13:49 Uhr schrieb Greg Chabala <
> [email protected]>:
>=20
>> Sounds like a bug, Windows may be less tested than other platforms.
>>=20
>> Would it work if you added .locks to your .gitignore file? Sometimes =
that's
>> enough to hide a file from a plugin.
>>=20
>>=20
>> On Tue, Jul 28, 2026, 12:16 AM Andreas Kuhtz =
<[email protected]>
>> wrote:
>>=20
>>> Hello,
>>>=20
>>> I noticed that central-publishing-maven-plugin breaks with Maven
>>> 3.10.0-rc-1 under Windows because of .locks generated in the
>>> target/central-* directories.
>>>=20
>>>=20
>>>=20
>> =
--------------------------------------------------------------------------=
---------------
>>> [INFO] --- central-publishing:0.11.0:publish
>> (injected-central-publishing)
>>> @ vldocking ---
>>> [INFO] Using Central baseUrl: https://central.sonatype.com
>>> [INFO] Using credentials from server id central in settings.xml
>>> [INFO] Staging 11 files
>>>=20
>>>=20
>>> [ERROR]
>>>=20
>>> Deployment fb7a5fc0-976f-447d-8833-9ad63218fd46 failed
>>> common:
>>> - Bundle has content that does NOT have a .pom file:
>>> org/bidib/jbidib/com/vldocking/vldocking, .locks
>>>=20
>>>=20
>> =
--------------------------------------------------------------------------=
---------------
>>>=20
>>> I don't know if this is a known issue, but I have not found anything =
when
>>> searching.
>>> Going back to 3.9.16 solved the issue for me.
>>>=20
>>> Thank you,
>>> Andreas
>>>=20
>>=20

--
Gerd Aschemann (er/he) --- Ver=C3=B6ffentlichen hei=C3=9Ft Ver=C3=A4ndern =
(Carmen Thomas)
+49/173/3264070 -- [email protected] -- https://aschemann.net


--Apple-Mail=_4AB9974F-06D9-402A-ABD7-372699A2F64E--