Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Doctrine\Common\ClassLoader is deprecated. #434

Open
freedelta opened this issue Jul 13, 2018 · 9 comments
Open

Doctrine\Common\ClassLoader is deprecated. #434

freedelta opened this issue Jul 13, 2018 · 9 comments
Milestone

Comments

@freedelta
Copy link

freedelta commented Jul 13, 2018

Preconditions

  1. This error is fired when launching tests in symfony: Doctrine\Common\ClassLoader is deprecated
  2. The error comes with Doctrine Common v2.9.0
  3. It seems that the ClassLoader in doctrine common is deprecated
    The future of Common 3.0 doctrine/common#826

Steps to reproduce

I think the error comes from the fact that you require doctrine/common in your composer.json

Expected result

Should not use doctrine/common

Actual result

In our logs: Doctrine\Common\ClassLoader is deprecated

@alexislefebvre
Copy link
Collaborator

Thanks for your report. Did you see this deprecation with the 1.x or 2.x version of this bundle?

@nataliastanko
Copy link

nataliastanko commented Jul 22, 2018

Thanks for your report. Did you see this deprecation with the 1.x or 2.x version of this bundle?

I can see it using doctrine/common 2.9.x-dev
I use liip/functional-test-bundle 2.0.0-alpha6

@alexislefebvre
Copy link
Collaborator

I removed the direct dependency in #440 and 3 of the dependencies of this bundle still require doctrine/common:

$ composer why doctrine/common
doctrine/data-fixtures  v1.3.1  requires  doctrine/common (~2.2)         
doctrine/orm            v2.6.2  requires  doctrine/common (^2.7.1)       
symfony/symfony         v4.1.1  requires  doctrine/common (~2.4@stable)  

So, we'll see the deprecation message until these 3 packages remove doctrine/common from their dependencies.


We can do the same thing as in symfony/symfony#27609 and require the necessary doctrine components and drop doctrine/common.

@alexislefebvre
Copy link
Collaborator

As noted here symfony/symfony#27609 (comment), the parameter weak_vendors can be used to ignore warnings from vendor/. I didn't tested it but it should hide Doctrine deprecations until all the packages are updated to remove this warning.

@alexislefebvre alexislefebvre added this to the 2.0 milestone Jul 23, 2018
@Tobion
Copy link

Tobion commented Nov 16, 2018

This is not caused by LiipFunctionalTestBundle and should get fixed automatically when doctrine/orm 2.6.3 is released, see doctrine/orm#7307

@Tobion Tobion closed this as completed Nov 16, 2018
@Tobion
Copy link

Tobion commented Nov 16, 2018

Reopening as the dependency on doctrine/common should be split like in symfony/symfony#27609

@Tobion Tobion reopened this Nov 16, 2018
@Jean85
Copy link
Contributor

Jean85 commented Nov 16, 2018

I've did a quick check using Composer require checker. This is the result, grepping for common:

$ composer-require-checker check composer.json | grep -i "common"
| Doctrine\Common\DataFixtures\Loader                                               |                    |
| Doctrine\Common\DataFixtures\Purger\ORMPurger                                     |                    |
| Doctrine\Common\DataFixtures\Executor\ORMExecutor                                 |                    |
| Doctrine\Common\DataFixtures\Executor\AbstractExecutor                            |                    |
| Doctrine\Common\DataFixtures\ProxyReferenceRepository                             |                    |
| Doctrine\Common\DataFixtures\Purger\PHPCRPurger                                   |                    |
| Doctrine\Common\DataFixtures\Purger\MongoDBPurger                                 |                    |
| Doctrine\Common\DataFixtures\Executor\MongoDBExecutor                             |                    |
| Doctrine\Common\Annotations\Reader                                                |                    |
| Doctrine\Common\EventManager                                                      |                    |
| Doctrine\Common\Persistence\ObjectManager                                         |                    |

It seems to me that any used symbol is due to fixture-related stuff (DataFixtures, Persistence). Only two exceptions are:

  • Annotations\Reader: this is used in the query counter:
    private function getMaxQueryAnnotation(): ?int
    {
    foreach (debug_backtrace() as $step) {
    if ('test' === substr($step['function'], 0, 4)) { //TODO: handle tests with the @test annotation
    $annotations = $this->annotationReader->getMethodAnnotations(
    new \ReflectionMethod($step['class'], $step['function'])
    );
  • Common\EventManager: this is used in the ConnectionFactory, so it gives the DoctrineBundle already for granted:
    public function createConnection(array $params, Configuration $config = null, EventManager $eventManager = null, array $mappingTypes = [])

The problematic thing is the fact that common is still required indirectly by our require-dev, so it's pretty hard to test against it at all:

$ composer why -t doctrine/common
doctrine/common v2.9.0 Common Library for Doctrine projects
├──doctrine/data-fixtures v1.3.1 (requires doctrine/common ~2.2)
│  ├──doctrine/doctrine-fixtures-bundle 3.0.2 (requires doctrine/data-fixtures ~1.0)
│  │  └──liip/functional-test-bundle 2.x-dev (requires (for development) doctrine/doctrine-fixtures-bundle ^3.0.2)
│  └──liip/functional-test-bundle 2.x-dev (requires (for development) doctrine/data-fixtures ^1.3)
├──doctrine/orm v2.6.2 (requires doctrine/common ^2.7.1)
│  └──liip/functional-test-bundle 2.x-dev (requires (for development) doctrine/orm ^2.6)
└──symfony/symfony v4.1.7 (requires doctrine/common ~2.4)
   └──liip/functional-test-bundle 2.x-dev (requires (for development) symfony/symfony ^3.4 || ^4.1)

How should we proceed?

IMHO maybe we could promote PHPUnit to a non-dev dependency (it surely is, since we extend the base test case), add a group to all tests that work around fixtures and exclude them in a single job.

@Jean85
Copy link
Contributor

Jean85 commented Nov 16, 2018

I did a small tryout of running tests without additional dev dependencies and that's really ugly.. The fixtures requires all the bundles, everything is an implicit / optional dependency... Argh!

@alexislefebvre
Copy link
Collaborator

alexislefebvre commented Nov 16, 2018

On one hand, we could add a test suite and ensure that some tests work without Doctrine. For example, for projets which use other database bundle like
Pomm https://github.com/pomm-project/pomm-bundle and want to use the helpers for requests or logging users.

On the other hand, I'm pretty sure that almost all the projects that use this bundle use Doctrine for communicating with their database and so we may assume that Doctrine is installed.

(sorry I misclicked and closed this issue)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants