Ha. Funny story. It transpired that we had a cron job on the build server "cleaning up" the local repo, deleting *files* older than five days. I believe this was put in because the repo was accumulating gigabytes of timestamped snapshots of war artifacts. In maven 3, the pom is copied into the local repo with the same modified-file-time as the original pom, while the built artifacts have modified-file-times of the actual build. Thus our cron job was just deleting the pom out of the directory, leading to an invalid state directory. In maven 2, either the pom modified-file-time was kept the same as the other artifacts, meaning everything in the directory got deleted together, or maven 2 was better at dealing with invalid state directories.
The moral of the story is: don't dick around in the repo. I bet there is a plugin which performs a cleanup on the local repo...would I be right? Anyway, I believe this still highlighted a couple of undesirable behaviours in maven 3: 1) not detecting the illegal state of the local repo, and attempting to fix it by re-resolving from the remote repo 2) not resolving the pom, but then only emitting a warning, and carrying on with the build giving spurious errors If you want to reproduce this scenario: * have A:jar:1.0-SNAPSHOT, depend on B:jar:1.0-SNAPSHOT (with actual compile time dependencies) * mvn install on both * delete just B-1.0-SNAPSHOT.pom from the local repo * mvn clean install on A * note the message [WARNING] The POM for B:1.0-SNAPSHOT is missing, no dependency information available * note the build continue, then fail at the compile phase thanks all. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
