Update docs for autoloader removal

README.md

@@ -14,4 +14,4 @@ architecture for PHP applcations.
 
 
 - File issues at https://github.com/zendframework/zend-modulemanager/issues
-- Documentation is at http://framework.zend.com/manual/current/en/index.html#zend-modulemanager
+- Documentation is at https://docs.zendframework.com/zend-modulemanager/

docs/book/intro.md

@@ -15,10 +15,6 @@ CSS, and JavaScript. The possibilities are endless.
 
 The module system is made up of the following:
 
-- [The Module Autoloader](https://docs.zendframework.com/zend-loader/module-autoloader/) -
-  `Zend\Loader\ModuleAutoloader` is a specialized autoloader that is responsible
-  for the locating and loading of modules' `Module` classes from a variety of
-  sources.
 - [The Module Manager](module-manager.md) - `Zend\ModuleManager\ModuleManager`
   takes an array of module names and fires a sequence of events for each one,
   allowing the behavior of the module system to be defined entirely by the
@@ -34,47 +30,31 @@ The module system is made up of the following:
 > [PHP namespace](http://php.net/namespaces), and must follow all of the same
 > rules for naming.
 
-The recommended structure for an MVC-oriented ZF2 module is as follows:
+The recommended structure for a zend-mvc oriented module is as follows:
 
 ```text
 module_root/
-    Module.php
-    autoload_classmap.php
-    autoload_function.php
-    autoload_register.php
     config/
         module.config.php
     public/
         images/
         css/
         js/
     src/
-        <module_namespace>/
-            <code files>
+        Module.php
+        <code files as per PSR-4>
     test/
-        phpunit.xml
-        bootstrap.php
-        <module_namespace>/
-            <test code files>
+        <test code files>
     view/
         <dir-named-after-module-namespace>/
             <dir-named-after-a-controller>/
                 <.phtml files>
+    phpunit.xml.dist
+    composer.json
 ```
 
-## The autoload\_\*.php Files
+## Autoloading
 
-The three `autoload_*.php` files are not required, but recommended. They provide the following:
-
-- `autoload_classmap.php` should return an array classmap of class name/filename
-  pairs (with the filenames resolved via the `__DIR__` magic constant).
-- `autoload_function.php` should return a PHP callback that can be passed to
-  `spl_autoload_register()`. Typically, this callback should utilize the map
-  returned by `autoload_classmap.php`.
-- `autoload_register.php` should register a PHP callback (typically that
-  returned by `autoload_function.php` with `spl_autoload_register()`.
-
-The purpose of these three files is to provide reasonable default mechanisms for
-autoloading the classes contained in the module, thus providing a trivial way to
-consume the module without requiring zend-modulemanager` (e.g., for use outside
-a ZF2 application).
+Since version 3, zend-modulemanager does not provide own autoloading mechanisms
+and instead relies on [Composer dependency manager](https://getcomposer.org/)
+to provide autoloading.

docs/book/migration/to-v3-0.md

@@ -0,0 +1,84 @@
+# Upgrading to 3.0
+
+## Module autoloading
+
+zend-modulemanager originates from before the Composer was created, where each
+framework had to provide its own autoloading implementation.
+Since then Composer became the de-facto standard in managing dependencies and
+autoloading for the php projects.  
+In light of that, zend-servicemanager removes ModuleLoader and autoload
+providers support in version 3.0 in favor of
+[Composer dependency manager](https://getcomposer.org/).
+
+### Application local modules
+
+Autoloading rules for application local modules should now be defined in
+application's composer.json
+
+Before:
+```php
+namespace Application;
+
+class Module
+{
+    public function getAutoloaderConfig()
+    {
+        return [
+            'Zend\Loader\StandardAutoloader' => [
+                'namespaces' => [
+                    __NAMESPACE__ => __DIR__ . '/src/' . __NAMESPACE__,
+                ],
+            ],
+        ];
+    }
+}
+```
+and after:
+```json
+{
+    "name": "zendframework/skeleton-application",
+    "description": "Skeleton Application for Zend Framework zend-mvc applications",
+    "type": "project",
+    ...
+    "autoload": {
+        "psr-4": {
+            "Application\\": "module/Application/src/"
+        }
+    },
+    "autoload-dev": {
+        "psr-4": {
+            "ApplicationTest\\": "module/Application/test/"
+        }
+    }
+}
+```
+
+[zf-composer-autoloading](https://github.com/zfcampus/zf-composer-autoloading)
+provides a handy tool to easily add and remove autoloading rules for local modules to
+application's composer.json
+
+After autoloading rules were updated, composer will need to update autoloader:
+
+```console
+$ composer dump-autoload
+```
+
+### Composer installed modules
+
+For composer installed modules, autoloading rules will be automatically picked
+by composer from the module's composer.json and no extra effort is needed:
+```json
+{
+    "name": "acme/my-module",
+    "description": "Module for use with zend-mvc applications.",
+    "type": "library",
+    "require": {
+        "php": "^7.1"
+    },
+    "autoload": {
+        "psr-4": {
+            "Acme\\MyModule\\": "src/"
+        }
+    }
+}
+```

docs/book/module-class.md

@@ -9,9 +9,7 @@ of `{moduleName}\Module` for each enabled module.
 
 As an example, provided the module name "MyModule",
 `Zend\ModuleManager\Listener\ModuleResolverListener` will expect the class
-`MyModule\Module` to be available. It relies on a registered autoloader
-(typically `Zend\Loader\ModuleAutoloader`) to find and include the
-`MyModule\Module` class if it isn't already available.
+`MyModule\Module` to be available.
 
 > ### Module classes
 >
@@ -26,7 +24,8 @@ something like this:
 
 ```text
 MyModule/
-    Module.php
+    src/
+        Module.php
 ```
 
 Within `Module.php`, you define your `MyModule\Module` class:
@@ -46,7 +45,7 @@ module system!
 This `Module` class serves as the single entry point for `ModuleManager`
 listeners to interact with a module. From within this class, modules can
 override or provide additional application configuration, perform initialization
-tasks such as registering autoloader(s), services and event listeners, declaring
+tasks such as registering services and event listeners, declaring
 dependencies, and much more.
 
 ## A Typical Module Class
@@ -58,29 +57,16 @@ namespace MyModule;
 
 class Module
 {
-    public function getAutoloaderConfig()
-    {
-        return [
-            'Zend\Loader\ClassMapAutoloader' => [
-                __DIR__ . '/autoload_classmap.php',
-            ],
-            'Zend\Loader\StandardAutoloader' => [
-                'namespaces' => [
-                    __NAMESPACE__ => __DIR__ . '/src/' . __NAMESPACE__,
-                ],
-            ],
-        ];
-    }
-
     public function getConfig()
     {
         return include __DIR__ . '/config/module.config.php';
     }
 }
 ```
 
-For a list of the provided module manager listeners and the interfaces and methods that `Module`
-classes may implement in order to interact with the module manager and application, see the
+For a list of the provided module manager listeners and the interfaces and
+methods that `Module` classes may implement in order to interact with the
+module manager and application, see the
 [module manager listeners](module-manager.md#module-manager-listeners) and the
 [module mananger events](module-manager.md#module-manager-events) documentation.