[Building Sakai] Checksum errors with maven 2.2.1

[Matthew Jones]

More inline!

On Wed, Mar 14, 2012 at 10:27 AM, David Horwitz <david.horwitz at uct.ac.za>wrote:
>
>  On 03/14/2012 04:14 PM, Matthew Jones wrote:
>
> FYI: These checksum errors have been around since 2009
>
>  https://jira.sakaiproject.org/browse/SAK-17441
>
>
>
> The errors I'm seeing are on current snapshots and weren't giving errors
> till recently
>

Can you give me more examples of specific checksum errors? Matthew Buckett
gave me a couple last week, but sonatype has already removed his examples
so I can't verify anymore. It only generally seems to only keep the most
recent snapshot and periodically cleans up old ones. I can try to wipe out
all the snapshots there, redeploy and see if that helps.

 Some of these were actual regressions with Maven deploying artifacts,
> specifically 2.2.0 where files were uploaded twice and they produced
> incorrect checksums on the server
> http://jira.codehaus.org/browse/MNG-4235
>
>  They had interesting workarounds for it that we never used. I think it's
> possible that some of the new artifacts deployed to sonatype were using
> this old version of maven. I know I had an option checked under the deploy
> (which was the default) which said "Assign unique versions to snapshots",
> but then in the description it says "To the best of my knowledge, this is
> almost never a useful option especially for CI servers like Jenkins.". So
> I have been going through and trying to clean that up as well, but it's
> lower priority to getting the next release out. This might have also
> confused maven 2?
>
>  The unique version won't match as far as I know, certainly not in maven
> 2. It looks quite different to a standard maven version.
>

I'm not sure then, it's hard to debug this as I haven't seen it. It would
require someone to manually verify if the client or the server has the
wrong checksum.

All of the new snapshots (for trunk) are getting deployed via webdav to
nexus at
https://oss.sonatype.org/content/repositories/snapshots/org/sakaiproject/
All of the old snapshots were getting deployed via scpexe to
http://source.sakaiproject.org/maven2-snapshots/org/sakaiproject/

Soon all of 2.9 and 2.10 will be on sonatype. The b03 kernel is the only
*released* artifact. All of those checksums are viable here:
https://search.maven.org/#browse%7C-1103303294

I don't think that the server is *wrong* anymore because there is an option
in nexus to verify and repair incorrect checksums. I can't tell what could
be going on though. I agree that it should be able to figure out the
correct version(s) though from the maven-metadata.xml files.

 Noah added a checksum ignore to the master a few months ago.
> It's*possible* that this 'ignore' policy is an option only available in
> Maven 3, which is why it's working better in Maven 3? I'm not sure
> otherwise unless the client has some regression?
>
>  Please can we not go the ingnore checksum route if at all possible? I
> makes maven proxing near impossible and builds for those of use behind
> proxies near impossible too (as a proxy error message can get saved. We
> will get lots of hard to verify errors about invalid artifacts.  This is
> asside from making build times much longer.
>
> We should aim to be stricter about checksums not more lax.
>

I agree, but this would require someone to either do some work into
figuring out where/what the problem is and how we can fix it. And for the
short term this is not going to be entirely me. ;) And it didn't (from the
ticket) appear to be anyone else in the past or recently. For our released
artifacts for sure it should be completely strict, and that checksum ignore
shouldn't be in there. I'm not even sure why it's verifying/downloading
snapshot artifacts during a full build anyway for the sakai tools.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20120314/ccfe4d61/attachment.html