+1
Additional benefits:

• installation/update can also happen with composer
• dependency managment inside plugin (https://github.com/ThaDafinser/LdapConnection)

Also what to think about:
Symfony + ZF have a really good bundle/module structure.

E.g. currently it looks a bit weired me to add a test folder in the root of the piwik plugin structure.

http://modules.zendframework.com/
https://github.com/doctrine/DoctrineModule
http://knpbundles.com/

When doing this we should also update all of our plugins to use composer.json instead of the getInformation() method in the plugin class.

Does this issue covers installing plugins from composer instead of submodules too?

Because we could use http://composer.github.io/installers/ which already exists for Piwik (https://github.com/composer/installers/blob/master/src/Composer/Installers/PiwikInstaller.php). The problem I see is that plugins require "piwik", so if piwik requires some plugins which in turn require piwik, we've got a nice loop.

Anyway maybe I'm off-topic, but I'd love to get rid of submodules and maybe this could be done at the same time.

Does this issue covers installing plugins from composer instead of submodules too?

No it's out of scope for the issue, but it's very important topic. This is related to misc-EnterpriseComposerFiles repo. Maybe we can create a new issue to discuss how this should be done in perfect world? It's not high priority but in December I think we should start working on it.

OK make sense.

However we need to keep in mind that if we rename plugin.json to composer.json, then all plugins will be incompatible with any future work to make them installable with Composer. That's because all plugins will require piwik/piwik in composer.json, so if piwik/piwik requires them, then there's a loop.

So if later we want to install plugins with composer, we will need to modify every plugin's composer.json.

I don't have a better alternative to suggest, I just want to point that out. Maybe it's not such a big deal.

We will most likely not use composer itself to install plugins in the near future as it might require an internet connection to fetch dependencies etc. Plugins should not require piwik/piwik anyway and we could simply remove it as you said.

We will most likely not use composer itself to install plugins in the near future as it might require an internet connection to fetch dependencies etc.

I don't see the difference with today. First, before packaging we have plugins embedded in the repo an plugins in git submodules: submodules could be replaced by composer. That's a win for us and doesn't change a thing in production where there might not be internet. Then once Piwik is in production we can either download plugins through the marketplace or install them manually. The last one wouldn't change, so it doesn't matter if there is no internet. And downloading plugins through the marketplace could (or not) use composer too.

In any way, composer could replace submodules without affecting production, wether there is internet or not.

What would be the advantages of using composer instead of submodules? Would it make it easier to handle refactorings across the code base including submodules? => This is may main problem with submodules but doesn't change it with composer I think. It might be even rather less work with submodules. Currently, we have to create a branch of piwik/piwik as well as each submodule for this.

Also installing a plugin is currently only unzipping a ZIP file basically... So not sure if much advantage with composer

I think we will have to discuss in different issues as it is different for core plugins that are currently managed via submodules and 3rd party plugins and 3rd party plugins on the marketplace. It brings different advantages / disadvantages etc. Otherwise we might talk about different things but mean the same and we might get confused :)

@mattab can we maybe implement this one in Piwik 3.0?

it would be a useful improvement to the platform @quba let's try it!

Another benefit: i tend to forget to change the version in plugin.json - since i'm so used to only create a tag like it work at composer/packagist

ThaDafinser/Piwik-IntranetGeoIP#25

I totally agree. Managing the version in plugin.json is a bit of a pain especially since someone has to tag it anyway. Problem is when a plugin is not published via github it will need a version in the plugin.json. What we could likely do is, if "version" in plugin.json is missing, we use the github release tag. If version is present, we use that version.

I will have a look and see if this is easy to implement next week

@ThaDafinser it is actually not trivial to remove the version from plugin.json. Problem is that our core and plugin updates are defined by a plugin version number, eg 2.1.4.php. The core knows in the option DB table which plugin version is currently installed and when the plugin version changes, it will install all missing updates and update the record in the option table. We could add the version number on the Marketplace but this wouldn't help when actually developing the plugin or when using the plugin directly from git etc. It would basically become almost impossible to test plugin updates as a developer etc. Eventually we need to change that in #5985 . The update files should be based on a timestamp or it should at least know which updates have been inserted already etc.