So to summarise, here are the options I see: A: replace bad 1.0 jar with good 1.0 jar B: rename bad 1.0 jar, do NOT provide any commons-cli-1.0.jar C: leave bad 1.0 jar as-isHere's my opinion: A: -0 B: +1 C: -0A: +1 B: -1 C: -0Absolutely should be A (using the intact version from the binary distribution - I assume this exists?), but still produce 1.0.1 as the recommended latest release which will be less confusing.
That's also what I thought in the first place. But I think Simon is right. Since we have no direct notifier (which would be a cool thing to add to maven. kind like a "message of the day" as part of every repo you download from) we might cause quite a few hours of wasted energy. Noone would expect such thing. All he sees is that it compiles on that machine and doesn't compile on the other one. A changed jar does not sound like an obvious thing to take into account when searching for the problem.
While admittedly it is harder to troubleshoot the incompatiblity scenario, in this specific case are there any known incompatibilities?
A clirr/jdiff support would be could to do. Will try to do that once I am back online.
I inadvertently discovered this some time back as I checked out the 1.0 tag to debug problems I was having with it, and when stepping through the code found the lines didn't match up. I assumed at the time someone had mucked up the release process of the original, not that it had been overwritten.Unfortunately, I still had the same problems with the version built from the tag source, and went back to 1.0-beta-2 which works better for me but is also an unknown point in time snapshot. I can detail this more in a separate email if there is actually a CLI-1 maintainer, but I assumed I would need to try out 2.0.
Actually there has even been some discussions a while ago about a release of 2.0. Maybe it's worth pushing that a little. 1.0 does feel a bit rusty in some areas.
The real solution here needs to be better repository management to avoid ever violating the integrity of a release. At Maven we are working on tools for this. But since this can happen anyway (both inadvertantly and maliciously), we are also considering "compare my repository to a canonical source" integrity checks too. This could involve checking the local sha1 against the local artifact and then checking that sha1 against the remote sha1 during a build, or doing a pass over the entire repository to do the same thing.
Sounds like a good plan. cheers -- Torsten
PGP.sig
Description: This is a digitally signed message part
