First thing would be to determine if those are failed downloads or creates (installed from local built). In both cases however failures should not result in that. For downloads you have checksum checks and for build artifacts they are copied from target/ (depending on the plugins used to install them of course).
Is that a groupid and Version you built on that machine or are those external artifacts? Are there any remote.properties in the artifact directory in your Repo cache dir? One possible cause could be process or OS crashes since maven does probably not fdsync new files (before rename). But you probably would know if that happens more often. -- http://bernd.eckenfels.net ________________________________ Von: Thomas Matthijs <li...@selckin.be> Gesendet: Friday, February 18, 2022 4:14:52 PM An: Maven Users List <users@maven.apache.org> Betreff: Re: zip file is empty If maven is creating these and then failing to write to them, then maybe instead it can write to a tmp file first and then move/rename it into place to solve the problem more nicely Regards On Fri, 18 Feb 2022 at 16:07, Andy Feldman <an...@wealthfront.com> wrote: > > This is also common at my workplace, with the resolution always being to > delete the empty file and try again. We haven't nailed down a > reproducible way to cause it, but it does seem to happen more often when > network conditions are flaky. I agree that deleting the file would be a > user-friendly thing for Maven to do automatically, assuming only one Maven > process is operating on the repository at once (which I think Maven already > assumes). > > On Fri, Feb 18, 2022 at 7:03 AM Mantas Gridinas <mgridi...@gmail.com> wrote: > > > Even empty jars that were produced by maven would contain > > META-INF/maven.{groupid}.{artifactid}/pom.* files, wouldn't they? Looking > > at ZipFile.java such error is thrown when the file is truly empty, and > > doesnt contain the zip metadata (ZipFile.java:1409 as per adopt openjdk > > sources). > > > > On Fri, Feb 18, 2022, 14:57 Jacques Etienne Beaudet <jebeau...@gmail.com> > > wrote: > > > > > Maven repository is not safe when running multiple concurrent builds (not > > > the -T1C option). You need to use an external synchronization technique > > if > > > you need this. > > > > > https://maven.apache.org/resolver/maven-resolver-named-locks-redisson/index.html > > > > > > Not sure of the implications of assuming an empty zip file means a failed > > > download, it seems reasonable to me but I'll let others chip in. > > > On Feb 18, 2022, 7:43 AM -0500, Nils Breunese <n...@breun.nl>, wrote: > > > > Hi, > > > > > > > > I’ve been encountering Maven warnings like these for years from time to > > > time: > > > > > > > > ---- > > > > WARN: zip file is empty: > > > > > /Users/username/.m2/repository/com/example/example-artifact/1.2.3/example-artifact-1.2.3.jar > > > > java.util.zip.ZipException: zip file is empty > > > > ---- > > > > > > > > I know that when I encounter this I can just delete the file and run > > > Maven again and then it’ll generally download ok, but recently I’ve been > > > getting questions from a lot of colleagues with this issue. I was > > > wondering: would it make sense for Maven to assume that an empty JAR file > > > was not downloaded correctly and try re-downloading it automatically? > > > > > > > > Nils. > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
