On Tue, Aug 2, 2011 at 1:23 PM, Dan Armbrust <daniel.armbrust.l...@gmail.com> wrote: > So, not only does archiva have a limitation that it really shouldn't > have in the first place (I whole-heartedly agree with the previous > poster - archiva should not be enforcing any rules on the makeup of a > version numbers) - it also has a bug where it doesn't validate the > input well enough to enforce its own limitations.
I'm not sure I'd want it validating and rejecting an upload because it can't store the value in the database. It would make the behavior different for "mvn deploy" vs. the upload feature -- and it can still store the artifact in the repository and serve it as a dependency. I don't think it's enforcing rules this time, you've just run into an edge case with a very long version number and an implementation detail of an arbitrary length limit in a SQL database. I much prefer multi-value databases that don't have such issues. ;) I don't know what's involved in increasing the length of that field, whether you can just do it in the database or if you have to change something in Archiva. The error handling isn't the best, you really shouldn't have to dive into the log files to figure out what's wrong. (I thought there was a repository health report, maybe it could show up there?) To get past it for now... is all that _really_ version information, or could some of it go in the artifactid? At the very least, including "-version" in the version number is redundant, and if you removed that, you'd be under the 50 character limit. -- Wendy
