sonatype/nexus — pull request #69 by cstamas (2011-11-16 12:43:02+00:00)
Title: Mime support fixes

Improving MIME support in Nexus Core.

* deprecated the MimeUtil component, it was just too "bozo"
* introduced MimeSupport component, all the core uses of MimeUtil redirected to this one
* introduced MimeRulesSource, making possible to set downstream MIME types per-repository (ie. *.pom should be XML in Maven repository, but might be some binary in some other repository type)
* added validation support for BZIP2 files
* improved content and file type validation logging
* cleaned up littered MIME related configurations and classes

How it works
============

In general, we had two issues:

* how Nexus reports MIME type downstream
* how Nexus validates MIME type (from upstream, in case of proxy repositories)

Originally, MIME type was just "relayed", meaning, if some broken remote repository reported POMs as "foo/bar", we sent that downstream too. Many issues were reported and related to this (see NEXUS-3972 for example).

In Nexus 1.4 we added "proper MIME support" (NEXUS-2323), but it was relatively poor: it allowed us to *globally* set the downstream MIME types (ie. unifying what Nexus claims about POM and JAR MIME types), but this solution still prevented us to have per-repository MIME type tweaks if needed (and conflicting mime types will be present soon, with introduction of Atom support for example).

MimeRulesSource is here to make a repository able to express *how it wants to represent MIME types for known repository type specific content downstream*. It does not take part in validation. Using it, a repository is now able to "fine tune" the reported MIME types overriding globally configured values (ie. some repo might for some reason report "*.xml" files as application/atom+xml instead of application/xml as today would be reported).

As for "upstream" validation, support has been broadened (adding BZIP2 to Velo's work), but also original MavenFileTypeValidator refactored into more reusable components (as of today, we only support file type validation for Maven repository, maybe some other repo type want to use this feature too?). Now we have reusable MIME magic type detection based validator, but also support for "XML like files" detection (that was also part of MavenFileTypeValidator to express expectancies against POM and Maven Repository Metadata files for example).

And finally, there is a "tweak" settings to enable/disable XML "lax validation" as we agreed. By default, it's on, and it will never report XML file as INVALID (it will stay put saying "neutral", or VALID if XML detected as proper XML file), unless turned OFF. Aside of "tweak" setting (ie. some user might want to *enforce* real XML validation, considering XML files without XML preamble INVALID), there is a possibility to enable/disable XML "lax validation" per-validation request.

Locally, the build did pass (master was still failing, since some IT had XML resources that were actually "fake" XML files, and since validation was turned ON by default). This change makes the build pass, since XML "lax validation" is enabled by default, and those "fake" XMLs in ITs are not considered "fake" anymore by file type validation (this is not affecting the actual assertions of ITs).