[RFC] Split this bundle

[K-Phoen]

VichUploaderBundle currently integrates with Doctrine ORM and Doctrine ODM, and support for Propel is on its way. That's great but it causes a few problems, the most troublesome being the dependency management. For Doctrine ORM we need doctrine/orm to be installed, for the ODM we need doctrine/mongodb-odm and for Propel we need two other packages.

For now, we just suggest packages through the composer.json file, which is not very efficient (no automatic installation, no constraint checks, ...). In order to solve this problem I suggest that we imitate the SonataAdminBundle and that we split this bundle. We would end up with the following "sub-bundles":

• VichUploaderBundle: would contain the core libraries and services ;
• VichDoctrineORMUploaderBundle : would integrate VichUploaderBundle with Doctrine ORM (and would contain only the necessary adapter/event-listeners/services definitions) ;
• VichDoctrineODMUploaderBundle : would integrate VichUploaderBundle with Doctrine ODM ;
• VichPropelUploaderBundle : would integrate VichUploaderBundle with Propel.

Each bundle having its own composer.json file, dependencies could be managed much more efficiently.

What do you think?

[K-Phoen]

The "child" bundles would look like this:

• Propel: https://github.com/K-Phoen/VichPropelUploaderBundle
• Doctrine ORM: https://github.com/K-Phoen/VichDoctrineORMUploaderBundle
• Doctrine ODM: https://github.com/K-Phoen/VichDoctrineODMUploaderBundle

[Baachi]

Is this really needed? I think if the bundle is to complex, it should be our goal to make it simpler and not split this bundle into more bundles. BUT it could be good, to extract some parts (Uploader,Injector,..) to a new library so it can be reused in other frameworks (Zend, Silex, ...).

[K-Phoen]

It's not that the bundle is too complex, it's only that supporting different persistence providers would be easier/cleaner if we had several bundles.

I see the following advantages to splitting the bundle:

• each "child bundle" can define its own dependencies and versions constraints (not possible right now) ;
• the test-suite is smaller and can be executed against HHVM (except for mongodb) ;
• a few simplifications should also become possible in the way listeners are registered.

The main advantage for me is really the dependencies management.

I really want to discuss this and introduce this in the 1.0 version (if we decide to) as I think it's the perfect occasion to start on new clean bases.

[KernelFolla]

look at these projects

https://packagist.org/packages/friendsofsymfony/user-bundle https://packagist.org/packages/sonata-project/media-bundle

they need ORM ODM and propel but do not require either doctrine.

+1 for @Baachi

[ftassi]

Just came back from a little vacation, a lot is happening here :D

My first thought about this is that we don't need a split and we should avoid it. Managing 3 bundles is more complex than managing a single one. Even if having a bundle with variable dependencies have its own complexity I guess that it's easier to manage a single bundle. If our dependencies are hard to define we can spend a bit more time documenting what is needed in one case and what is needed in another (plus if I need the doctrine listeners for this bundle chances are that I already have the right deps in place). Try to think of having 3 different bundle and having users opening issue from bundle X because they don't realize that the problem is actually related to bundle Y.

I can get the value of splitting, (Symfony itself has split down in several components and it was a really good choice), but our bundle is far far less complex than that and I don't feel the splits as needed.

[K-Phoen]

You're all right, splitting might be a bit too complex for us (euphemism?).

Thanks everyone for taking the time to convince me!