owncloud/core — pull request #6618 by AdamWill (2014-01-02 22:45:53+00:00)
Title: Have 3rdparty directories act as PSR-0 compliant namespaces, add manifests

This is a large change that should introduce more consistency and clarity into the use of 3rdparty includes. This PR makes the change for the 3rdparty stuff in core/apps/*/3rdparty; I'm planning to send a corresponding change for the 3rdparty repo which contains all the 'project-wide' 3rdparty stuff.

The high-level approach here is to make each 3rdparty/ directory the top level of a PSR-0 - https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md - namespace. All PSR-0 compliant 3rdparty modules should be laid out such that they would be found by a PSR-0 compliant autoloader with the relevant 3rdparty/ directory (but *no subdirectories thereof*) in its path.

This allows us to be very consistent about loading PSR-0 compliant modules. I set it up so that for all PSR-0 compliant modules, anything that wants to load one adds the relevant 3rdparty/ directory to the include_path and then requires the PSR-0 compliant relative path. In fact as a follow-up we should be able to use OC's autoloader to do so (after completing these re-arrangements I'm planning to send a patch that makes OC's autoloader simply act as a PSR-0 compliant autoloader for non-OC modules, and drop all the ersatz namespacing stuff). It helps out downstream distributors enormously as well, because as long as upstream and downstreams package PSR-0 compliant modules in a PSR-0 compliant way, it's trivial for downstreams to unbundle 3rdparty modules by simply removing them from their OwnCloud package: thanks the PSR-0 conventions, the systemwide copies will 'magically' be found instead with no downstream patching needed.

Non PSR-0 compliant modules are left as before; I think a sensible policy for non PSR-0 compliant 3rdparty modules is 1) avoid them if possible, 2) if needed, they should go under the relevant 3rdparty/ tree with the directory hierarchy unmodified from the preferred upstream distribution format (unneeded stuff can be stripped, but the hierarchy must stay the same). That way as long as downstreams package the modules the same way, which Debian and Fedora usually do, unbundling will be similarly straightforward. I think the current non PSR-0 compliant modules are all laid out this way already, if I find any that are not I'll send follow-ups.

The MANIFEST files contain all the information I always *wish* webapps would include about what 3rdparty bits they're bundling: what they all are, where they come from, what files are part of what modules, what versions they've included, licenses, and notes on how they've been modified downstream. It's a gigantic PITA for downstream distributors when this information is not included. The work to relocate things in this PR was actually trivial and took about 20 minutes; the work on the MANIFEST file has taken me about four hours. I invented the format as I went along, if anyone's aware of a standard or convention relating to providing this kind of information I'm happy to change the format, but it's really important for downstreams that the information be available.