On 02/08/2011, at 10:37 AM, Dan Armbrust wrote: >> >> Is there anything in the logs at the time of the upload, or the next >> time it tries to index? I vaguely recall an issue with a similar >> version number... >> >> -Wendy >> > > I don't have access to the server in question, unfortunately. > > I also don't have a copy running locally at the moment to test. I > hoped it would be an easy enough thing to test for a developer :) > > I'm at a loss trying to understand how archiva deals with version > numbers overall. > > It seems to have arbitrary, undocumented behavior within the validator > (at least on the gui upload). I don't see any reason at all why > archiva should have a say over the makeup and composition of a version > number. At most, it would seem that the version number would need to > be valid as a part of a file name across all OS platforms. But beyond > that, why should it care?
In a Maven repository, we need to parse the path sometimes to be able to determine what the version and classifier are. That has been known to trip up on non-standard versions in the past and we've built up some test cases. It should be a simple bug to fix. In trunk, we're moving to relying on that less - particularly in cases where it is not important (such as here where everything is a Maven 2 repository and there is a POM that describes the version for it). There's still some work to do there. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter
