* Rewritten `install()` method now takes a repository instead of a list of packages (per @nadermen)
* Added Composite Repository
* Added tests for Composite Repository
* Removed "local repository" concept from Platform Repository
* Removed some `use` statements for Platform Repository where it was not actually being used
Changed some some instances of the $package variable name to be
able to be consistent in all branches of the "add to request"
section of code.
Updated an instance of "break" to "continue 2" as it was resulting
in the same package getting both update() and install() called
on request. Seems like this is probably not needed, should be
just one or the other? (could be way wrong on this)
Gave "locked" branch of the update/locked/install code some
logic to handle internally installed packages.
Rename GetTriggerEvent on TriggerEvent
Remove get/set Application in TriggerEvent
Remove get/set Dispatcher in TriggerEvent
Add get/set Composer in TriggerEvent
Add get/set IO in TriggerEvent
Restaure ConsoleIO and IOInterface
Update Faq
The behaviour of the lockfile was a little confusing to me.
I assumed if I added a new dependency I should run
'composer install' again. It was not immediately obvious
from the output of the install command what was going on
and I was confused why my new package had not been installed.
I understand that a better fix would be to compare
composer.json to the lockfile, but until that has been
implemented this will maybe help some newbies out.
Beau Simensen
Jordi Boggiano
François Pluchino
digitalkaoz
Nils Adermann
jsor
Ant Cunningham
Igor Wiedler
everzet