Remove Entity/Document/CouchDocument auto-detection about doctrinebundle

[henrikbjorn]

Still waiting on that blog post :) Until another best pratice is determained this is still the best solution imo.

[lsmith77]

i would be happy if we can improve the current situation. in order to handle clashes better, we might also want to support black listing and now just white listing when the user has to manually decide which Bundles use what manager. but we also need to ensure things stay easy to config even for Bundles that provide models for different managers that the user wants to use in the same app

[dbu]

note that we since then have a compiler pass helper for bundles that want to support multiple doctrine variants. auto-detection maybe is just too much. http://symfony.com/doc/current/cookbook/doctrine/mapping_model_classes.html

FOSUserBundle does it like this to be compatible with older versions of DoctrineBundle
https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/DependencyInjection/Compiler/RegisterMappingsPass.php

[stof]

making auto_mapping pointing to the bundle itself can be an issue because it would mean that Doctrine will need to run annotations on the whole bundle when you ask for entity classes.
and if you have a bundle supporting both the MongoDB ODM and the ORM, and they are both enabled in the project, you will still want to map the bundle for only one of them generally (the one configured to be used by the bundle). The autodetection would cause some issues in such case.

The second part is indeed covered by the new compiler passes

[ostrolucky]

As far as I see logic of this is in symfony doctrine bridge, so if this is important, this issue should be raised there. And as far as we see, this didn't gaing much traction and issue itself is confusing - title talks about different things than description and description proposes two different things. If comments address right thing, we agree with @stof and @dbu opinion that making automapping scan whole bundle dir by default might be too much. Feel free to reopen issue with more concrete proposal.