Thijs/wiki.techinc.nl
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
wiki.techinc.nl/composer.json

73 lines
1.8 KiB
JSON
Raw Normal View History

Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
{
"name": "mediawiki/core",
"description": "Free software wiki application developed by the Wikimedia Foundation and others",
"keywords": ["mediawiki", "wiki"],
"homepage": "https://www.mediawiki.org/",
"authors": [
{
"name": "MediaWiki Community",
"homepage": "https://www.mediawiki.org/wiki/Special:Version/Credits"
}
],
composer.json: Correct license identifier According to <https://spdx.org/licenses/>, "GPL-2.0" means "GNU General Public License v2.0 only", not "GNU General Public License v2.0 or later", which has the identifier "GPL-2.0+". Also made the same change in the documentation for $wgExtensionCredits. Change-Id: If25c15d03a71d7c50c9c85a04c2a589a3d978ad0
2015-01-31 23:49:49 +00:00
"license": "GPL-2.0+",
Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
"support": {
composer.json: Update issues link to point to bugs.mediawiki.org Change-Id: I67f4403f1797a38bc3f5d7b190d7f84f6fdf457c
2014-12-11 20:54:59 +00:00
"issues": "https://bugs.mediawiki.org/",
Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
"irc": "irc://irc.freenode.net/mediawiki",
"wiki": "https://www.mediawiki.org/"
},
"require": {
Introduce Composer merge plugin Require Composer merge plugin to allow easier local Composer dependency management without composer.json edit conflicts. The configuration provided will merge Composer configuration directives found in a `composer.local.json` config file into those specified by MediaWiki's composer.json file at Composer runtime. Bug: T67188 Change-Id: I66a19d0154191e536aab37a5e183e4505bf3e9be
2014-12-30 23:42:32 +00:00
"cssjanus/cssjanus": "1.1.1",
Require ext-iconv and suggest ext-intl in composer.json Since iconv is required, per running install.php, and intl is recommended. Bug: T90439 Change-Id: I70f6ce9d8d71f8abd3800bbe00aa0f754ce297a2
2015-02-23 15:03:24 +00:00
"ext-iconv": "*",
Load lessphp via composer Adds leafo/lessphp 0.5.0 as a dependency, and removes the current copy of lessphp. Depends on 7b2af65827 in mediawiki/vendor. Bug: T1337 Change-Id: Ib5ab4c872d5236258df97d49f4ba72a20758a2e9
2014-11-24 18:48:16 +00:00
"leafo/lessphp": "0.5.0",
Add StatsD metric logging This patch adds a metric data service object to the IContextSource interface, with full support for StatsD meters, gauges, counters and timing metrics, via the liuggio/statsd-php-client, which this patch also introduces. Usage example: $stats = $context->getStats(); $stats->increment( 'resourceloader.cache.hits' ); $stats->timing( 'resourceloader.cache.rtt', $rtt ); The metrics are flushed to a StatsD server, which may be specified via the 'StatsdServer' configuration key. If no such configuration key exists, the metrics are discarded. The StatsD client supplants MediaWiki's StatCounter class. wfIncrStats() will continue to work, but it will delegate to the StatsD data object. Change-Id: Ie10db1c154d225971398e189737de7c560bf0f90
2015-02-20 08:23:18 +00:00
"liuggio/statsd-php-client": "1.0.12",
Update OOjs UI to v0.11.3 Release notes: https://git.wikimedia.org/blob/oojs%2Fui.git/v0.11.3/History.md Change-Id: I3b1ffc8fd346bb6cc8f1029f64e4855afa1db168
2015-05-12 12:26:13 +00:00
"oojs/oojs-ui": "0.11.3",
Require PHP >= 5.3.3 Bug: T839 Change-Id: Iac827ef8505ff0653a40e45d759b0f79619351ee
2014-10-24 01:21:50 +00:00
"php": ">=5.3.3",
Use CSSJanus via composer Requires I7de49f443 in mediawiki/vendor Change-Id: I94837938f0e0f3daa4d1f53c390457f843000605
2014-10-30 18:21:34 +00:00
"psr/log": "1.0.0",
Add dependency upon oojs/ui's PHP port Depends upon Ibca93b05 in mediawiki/vendor. Change-Id: Ibca93b05623377dc645a28ddd337027e53983552
2014-11-22 01:54:37 +00:00
"wikimedia/cdb": "1.0.1",
Start using the Assert helper class for checking parameters. This introduces https://github.com/wmde/Assert as a dependency, as discussed in the RFC T91071. This change uses assertions to check some parameters in some places, to showcase the main intended use case for assertions in MediaWiki. Bug: T91071 Change-Id: I93ac39b7c146f10532e37b51d973b59b9c424b2f
2015-04-22 16:46:29 +00:00
"wikimedia/assert": "0.2.2",
Bump composer-merge-plugin to v1.1.0 Bug: T97560 Change-Id: Idc3ae196f7fc9483f5c474b32d92e30be8325d62
2015-05-28 00:39:06 +00:00
"wikimedia/composer-merge-plugin": "1.1.0",
Use wikimedia/utfnormal library, add backwards-compatability layer This drops support for the custom utf8 normal PHP extension in favor of the intl extension. Bug: T90825 Change-Id: Ifbaeb2ef684217cf6187ccc4fb4d303f89608300
2015-03-07 09:27:42 +00:00
"wikimedia/utfnormal": "1.0.2",
Bumping lightncandy version from 0.18 to 0.21 See also change in vendor repo: I0ba740a88b636a9c1 Change-Id: Idbcc356595db2ceb267690570ef23cd08294426e
2015-05-15 22:15:02 +00:00
"zordius/lightncandy": "0.21"
Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
},
"require-dev": {
Add composer lint, phpcs, and test commands lint uses jakub-onderka/php-parallel-lint to check the syntax of the provided PHP files or directories. phpcs uses the MediaWiki codesniffer standard to check the provided files or directories. test runs both lint and phpcs together. phpunit is not included at this time because our phpunit tests require a database to be set up and are very very slow. Example usage: composer lint . # Lint all files composer phpcs includes/FooBar.php # Check code style of one file composer test extensions/FooBar # Lint and check an extension Change-Id: I3c7ac7a02668776de6400ac268f37e7e6b35a3c6
2015-01-06 18:47:25 +00:00
"jakub-onderka/php-parallel-lint": "~0.8",
Implement extension registration from an extension.json file Introduces wfLoadExtension()/wfLoadSkin() which should be used in LocalSettings.php rather than require-ing a PHP entry point. Extensions and skins would add "extension.json" or "skin.json" files in their root, which contains all the information typically present in PHP entry point files (classes to autoload, special pages, API modules, etc.) A full schema can be found at docs/extension.schema.json, and a script to validate these to the schema is provided. An additional script is provided to convert typical PHP entry point files into their JSON equivalents. The basic flow of loading an extension goes like: * Get the ExtensionRegistry singleton instance * ExtensionRegistry takes a filename, reads the file or tries to get the parsed JSON from APC if possible. * The JSON is run through a Processor instance, which registers things with the appropriate global settings. * The output of the processor is cached in APC if possible. * The extension/skin is marked as loaded in the ExtensionRegistry and a callback function is executed if one was specified. For ideal performance, a batch loading method is also provided: * The absolute path name to the JSON file is queued in the ExtensionRegistry instance. * When loadFromQueue() is called, it constructs a hash unique to the members of the current queue, and sees if the queue has been cached in APC. If not, it processes each file individually, and combines the result of each Processor into one giant array, which is cached in APC. * The giant array then sets various global settings, defines constants, and calls callbacks. To invalidate the cached processed info, by default the mtime of each JSON file is checked. However that can be slow if you have a large number of extensions, so you can set $wgExtensionInfoMTime to the mtime of one file, and `touch` it whenever you update your extensions. Change-Id: I7074b65d07c5c7d4e3f1fb0755d74a0b07ed4596
2014-10-15 00:31:15 +00:00
"justinrainbow/json-schema": "~1.3",
Add composer lint, phpcs, and test commands lint uses jakub-onderka/php-parallel-lint to check the syntax of the provided PHP files or directories. phpcs uses the MediaWiki codesniffer standard to check the provided files or directories. test runs both lint and phpcs together. phpunit is not included at this time because our phpunit tests require a database to be set up and are very very slow. Example usage: composer lint . # Lint all files composer phpcs includes/FooBar.php # Check code style of one file composer test extensions/FooBar # Lint and check an extension Change-Id: I3c7ac7a02668776de6400ac268f37e7e6b35a3c6
2015-01-06 18:47:25 +00:00
"phpunit/phpunit": "~4.5",
"mediawiki/mediawiki-codesniffer": "0.1.0"
Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
},
"suggest": {
"ext-fileinfo": "*",
Require ext-iconv and suggest ext-intl in composer.json Since iconv is required, per running install.php, and intl is recommended. Bug: T90439 Change-Id: I70f6ce9d8d71f8abd3800bbe00aa0f754ce297a2
2015-02-23 15:03:24 +00:00
"ext-intl": "*",
Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
"ext-mbstring": "*",
"ext-wikidiff2": "*",
Add Composer managed libraries This is the initial step towards implementing the Structured logging RFC [0]. The Psr\Log library is declared as a requirement in the composer.json file and Monolog is suggested as a package that can enhance MediaWiki. To use this in a local checkout: * Install composer [1] * `composer update` * `composer require monolog/monolog 1.9.*` * `composer dump-autoload --optimize` * `git update-index --assume-unchanged composer.json` Additional work will be needed to provide both the Psr\Log and Monolog libraries available for deployment to the Wikimedia Foundation servers. The Psr\Log library will also need to be packaged in the release tarballs. [0]: https://www.mediawiki.org/wiki/Requests_for_comment/Structured_logging [1]: https://getcomposer.org/doc/00-intro.md#installation-nix See also: I1431b24 (Monolithic implementation) Change-Id: Ie667944416187cfd2ae6016c9e2fa28f4204bcd7
2014-03-21 04:10:46 +00:00
"ext-apc": "*",
"monolog/monolog": "*"
Restore Composer hook providing MediaWiki version Restores the Composer hook integration first implemented in I8df66a92971146ab79cd4fcbd181e559115ca240 to composer.json. Change-Id: I708f619d2de8a760eaaeaf6be54d8ae0db1b18d6
2014-09-23 19:31:30 +00:00
},
"autoload": {
"psr-0": {
"ComposerHookHandler": "includes/composer"
}
},
"scripts": {
Add composer lint, phpcs, and test commands lint uses jakub-onderka/php-parallel-lint to check the syntax of the provided PHP files or directories. phpcs uses the MediaWiki codesniffer standard to check the provided files or directories. test runs both lint and phpcs together. phpunit is not included at this time because our phpunit tests require a database to be set up and are very very slow. Example usage: composer lint . # Lint all files composer phpcs includes/FooBar.php # Check code style of one file composer test extensions/FooBar # Lint and check an extension Change-Id: I3c7ac7a02668776de6400ac268f37e7e6b35a3c6
2015-01-06 18:47:25 +00:00
"lint": "parallel-lint --exclude vendor",
Don't run phpcs on node_modules folder This is an artifact created by npm in certain modules. These modules may contain PHP e.g. grunt-phpdocumentor Change-Id: Ie46bceb5acbe6141d1e0dc4d3397d04f41d01485
2015-05-28 17:08:42 +00:00
"phpcs": "phpcs $PHPCS_ARGS -s --standard=vendor/mediawiki/mediawiki-codesniffer/MediaWiki --ignore=vendor,node_modules --encoding=utf-8 --extensions=php,php5,inc,sample",
Add composer lint, phpcs, and test commands lint uses jakub-onderka/php-parallel-lint to check the syntax of the provided PHP files or directories. phpcs uses the MediaWiki codesniffer standard to check the provided files or directories. test runs both lint and phpcs together. phpunit is not included at this time because our phpunit tests require a database to be set up and are very very slow. Example usage: composer lint . # Lint all files composer phpcs includes/FooBar.php # Check code style of one file composer test extensions/FooBar # Lint and check an extension Change-Id: I3c7ac7a02668776de6400ac268f37e7e6b35a3c6
2015-01-06 18:47:25 +00:00
"test": [
"composer lint",
"composer phpcs"
],
Restore Composer hook providing MediaWiki version Restores the Composer hook integration first implemented in I8df66a92971146ab79cd4fcbd181e559115ca240 to composer.json. Change-Id: I708f619d2de8a760eaaeaf6be54d8ae0db1b18d6
2014-09-23 19:31:30 +00:00
"pre-update-cmd": "ComposerHookHandler::onPreUpdate",
"pre-install-cmd": "ComposerHookHandler::onPreInstall"
Set optimize-autoloader: true and prepend-autoloader: false in composer.json Quoting Tim from 240fd31cfa6b in mediawiki/vendor (prepend-autoloader): Composer's autoloader is slow, taking about 63µs per class, whereas MediaWiki's is fast, taking about 7µs per class. This adds up to an overhead of about 13% of CPU time on short requests such as API calls. On those same short requests, MediaWiki's autoloader finds most of the classes. So it makes sense to run it first, before the two Composer autoloaders. So change the config so that composer passes $prepend=false to spl_autoload_register(). optimize-autoloader is also just a good idea in general. Change-Id: I383c72a85eda415da92e8a9253e83b4ed591768b
2014-12-02 17:19:18 +00:00
},
"config": {
"prepend-autoloader": false,
"optimize-autoloader": true
Introduce Composer merge plugin Require Composer merge plugin to allow easier local Composer dependency management without composer.json edit conflicts. The configuration provided will merge Composer configuration directives found in a `composer.local.json` config file into those specified by MediaWiki's composer.json file at Composer runtime. Bug: T67188 Change-Id: I66a19d0154191e536aab37a5e183e4505bf3e9be
2014-12-30 23:42:32 +00:00
},
"extra": {
"merge-plugin": {
"include": [
"composer.local.json"
]
}
Revert "Make it possible to install extensions using Composer" This reverts commit d6e69d774. MediaWiki extensions are by definition part of the MediaWiki software ecosystem, and could therefore be managed using a specialized solution; The same is not true of PHP packages at large: we're not in a position to change how the PHP community at large manages dependencies. To the extent that we have a choice, we should use interfaces like composer.json to solve for the problem of integration with the outside world. Change Ib125bea00 made the opposite choice, compromising our ability to express how MediaWiki relates to external software components in exchange for superficial gains in convenience of managing MediaWiki extensions. (I consider the gains superficial because they do not leverage the fact that extensions share MediaWiki's code -- a property that should be exploited to provide an extension management solution that is MediaWiki-aware, providing, for example, a uniform configuration management interface.) The cost of that change are manifest in bug 64597: we lost the ability to express a dependency on PHPUnit in the way that the PHPUnit upstream recommends. The problem that change Ib125bea00 set out to solve is that modifying composer.json to express dependencies on extensions means having a local diff that conflicts with the code in version control. This issue is actually discussed by the Composer documentation. In short, Composer's developers recommend that if your production environment uses a cvs to version code, you should maintain your own clone of the upstream repository and version your composer.json that way. More detailed discussion of these issues can be found at <https://getcomposer.org/doc/05-repositories.md#vcs> and <https://getcomposer.org/doc/faqs/why-can't-composer-load-repositories-recursively.md>. I also note that the Composer documentation makes many references to monolog as an exemplary Composer project, and it too maintains a composer.json in the repository root. Change-Id: I3e7c668ee32401e731120cfa9f96986fd8fde8f4
2014-05-11 10:00:35 +00:00
}
}
Reference in a new issue Copy permalink