Ah ha! It *was* the Maven cache. Thank you for getting me to take another look.
I had been looking at the files for the transient library, xml-apis. That all checked out. Just now I looked one higher, at the library that was bringing in xml-apis (com.megginson.sax:xml-writer:0.2). *That* didn't match. So I ran `mvn dependency:purge-local-repository` on it, which pulled in files that match my office machine. Now the app builds match (both now include xml-apis, so long as I don't specifically exclude it). As to what caused the cache difference to begin with, from the cache dates I believe that my home machine got its files from an old Archiva server. It crashed last October, and I replaced it with Nexus 3 running on other hardware. Whatever the cause, it's straight now. Thank you for prodding me. After two days away, I was able to come back with a fresh outlook. On Tue, Apr 18, 2023 at 11:33 AM Eric Bresie <[email protected]> wrote: > Any chance there are some conflicting profile or differences in > settings.xml on the different machines? > > Maybe maven caches is different and needs cleanup? > > Eric Bresie > [email protected] (mailto:[email protected]) > > > On April 16, 2023 at 7:36:36 AM CDT, Thad Humphries < > [email protected] (mailto:[email protected])> wrote: > > There are no profiles in the pom.xml that brings in the jar in question, > > xml-apis ( > > > https://repo1.maven.org/maven2/com/megginson/sax/xml-writer/0.2/xml-writer-0.2.pom > ). > > Since the webapp works without it, I'll exclude it from the build. > > > > On Sat, Apr 15, 2023 at 7:30 PM Tomo Suzuki <[email protected] > (mailto:[email protected])> > > wrote: > > > > > > The pom.xml has 2 profiles > > > > > > I meant the pom file that delcares the missing dependency. Your > > > (transitive) dependency's pom.xml. > > > > > > On Sat, Apr 15, 2023 at 13:29 Thad Humphries <[email protected] > (mailto:[email protected])> > > > wrote: > > > > > > > Thanks. I might be missing something but I can't see it. Responses > > > inline. > > > > > > > > On Sat, Apr 15, 2023 at 12:00 PM Tomo Suzuki > <[email protected] (mailto:[email protected]) > > > > > > > > wrote: > > > > > > > > > My guess > > > > > > > > > > - Maven profiles activated based on environment > > > > > > > > > > > > > The pom.xml has 2 profiles, both triggered by -P, not (that I know > of) by > > > > the environment. In any case, environments are (at least from the > debug) > > > > the same except for "java.awt.headless: true" in the debug from the > > > office > > > > Mac that I telnet into. That's the Mini with the extra JAR, but my > > > MacBook > > > > has it, too, and it's here with me. > > > > > > > > Of the two declared profiles, one profile selects GWT devmode, while > the > > > > other packages the *war. In all the cases that I am describing, I'm > > > > using the packaging profile. Each time the command is > > > > > > > > $ mvn clean exec:exec -Dexec.executable="xslt" package -P package > > > > > > > > (The exec:exec builds the webapp's online manual using DocBook. It's > > > later > > > > copied into the *war. Same DocBook version, same version of > xsltproc.) > > > > > > > > Running `mvn help:effective-settings` shows the same settings on each > > > > machine except for hostnames. Is there another command I should try? > > > > > > > > > > > > > - Download URL was unavailable > > > > > > > > > > > > > I don't think so. I've packaged this dozens of times over the past 3 > days > > > > with the same results each time. The Git and Nexus servers are > inside the > > > > office, but I've had no connection issues with them. I have a VPN to > > > > everything there. > > > > > > > > > > > > > or > > > > > - Disk was full when downloading > > > > > > > > > > > > > Both Mac Minis have 1.12TB Fusion drives with over 50% free. > > > > > > > > > > > > > > > > > > On Fri, Apr 14, 2023 at 15:34 Thad Humphries < > [email protected] (mailto:[email protected]) > > > > > > > > > wrote: > > > > > > > > > > > I have *war that I've built on 3 different Macs (maven-war-plugin > > > > 3.3.2). > > > > > > The code is pulled from my local git repo, and the supporting > jars > > > are > > > > > from > > > > > > a local Nexus repository. All Macs use the same setup--Amazon > > > Corretto > > > > > Java > > > > > > 11 and Maven 3.9.1. The ~/.m2/settings.xml are identical. Two of > the > > > > Macs > > > > > > produce the same *war (a Mini with 10.15.7 and a MacBook with > > > 12.6.5). > > > > > The > > > > > > third Mac--also a Mini with 10.15.7--is missing one JAR file in > > > > > > WEB-INF/lib. How can this be? > > > > > > > > > > > > The missing JAR is in each local repository. I do not see this > JAR > > > > when I > > > > > > run `mvn dependency:tree`, though I see a different (newer) > version > > > as > > > > > > "provided." The missing JAR doesn't seem to matter when the > webapp > > > runs > > > > > (no > > > > > > problems found so far). Any idea as to why, and what I can (or > > > should?) > > > > > do > > > > > > for a consistent build? > > > > > > > > > > > > -- > > > > > > "Hell hath no limits, nor is circumscrib'd In one self-place; but > > > where > > > > > we > > > > > > are is hell, And where hell is, there must we ever be" > --Christopher > > > > > > Marlowe, *Doctor Faustus* (v. 111-13) > > > > > > > > > > > -- > > > > > Regards, > > > > > Tomo > > > > > > > > > > > > > > > > > -- > > > > "Hell hath no limits, nor is circumscrib'd In one self-place; but > where > > > we > > > > are is hell, And where hell is, there must we ever be" --Christopher > > > > Marlowe, *Doctor Faustus* (v. 111-13) > > > > > > > -- > > > Regards, > > > Tomo > > > > > > > > > -- > > "Hell hath no limits, nor is circumscrib'd In one self-place; but where > we > > are is hell, And where hell is, there must we ever be" --Christopher > > Marlowe, *Doctor Faustus* (v. 111-13) > -- "Hell hath no limits, nor is circumscrib'd In one self-place; but where we are is hell, And where hell is, there must we ever be" --Christopher Marlowe, *Doctor Faustus* (v. 111-13)
