Re: Rewrite of JAR plugin ready for merge
Sergey Chernov <[email protected]>
| Newsgroups | gmane.comp.jakarta.turbine.maven.devel |
|---|---|
| Message-ID | <CAJ-bKnnjinEwO+aqbAMtYDnWE9Gnb5ANAA2hF=nzpgRuJH6ksw@mail.gmail.com> |
I've rechecked, the target problem is fixed indeed. But now I see another issue. I've built the JAR and it's not binary equal to the original one. The Spring Boot application fails to start, while everything looks ok on the first sight. I used Claude to binary compare old and new archives and it concluded interesting: ``` Every class/resource entry matches by name, uncompressed size, and CRC-32. What differs: - Directory entries: server3 jars contain them (com/, com/acme/, …); server2 jars omit them (770 jars). ``` As a result, the spring boot application fails to discover some componentScan related components, which rely on JAR traversal. I can do more tests, but I believe this is quite close to being correct finding, which IMO is severe. I've rechecked with the master build of maven-jar-plugin, the problem is not there - so it's new. On Mon, Aug 17, 2026 at 11:14 AM Martin Desruisseaux via dev < [email protected]> wrote: > Le 17/08/2026 à 11:02, Sergey Chernov a écrit : > > > Forgot to mention: the failing module does not have the src/main > directory > > Thanks, it seems that the consequence is that the `target` directory > does not exist neither. The plugin could create that directory itself, > but it raises the question of how many directory levels we allow to > create (I'm a little bit nervous about unlimited depth). Discussion on > the GitHub issue. > > Martin > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >