allow package names to be defined via other than @package tag

[manuelpichler]

No description provided.

[ghost]

The package tag doesn't seem to be working at all right now, at least not for 5.3+ code. This is a major issue for us: PHP_Depend is not producing metrics of any real value. We embrace Uncle Bobs package principles, including those related to "releasing" packages, and all our packages are Composer packages. I believe this system does more justice to Martin's intentions than treating namespaces as packages, the latter being a too literal translation of applying the principles in Java.

To clarify this concrete use case: we have many small packages that we manage using Composer and Satis, and all have dependencies on other Composer packages. Our unit of reusability is a Composer package. For the small packages we do not bother with PHP_Depend. But the larger packages with many in-house dependencies, specifically our back- and frontend applications, PHP_Depend could provide us with valuable metrics by scanning the vendor directory. But we need to be able to tell PHP_Depend what constitudes a package. We also have a convention dictating that "Second level namespaces are packages" (VendorName/SomePackage"), being able to tell PHP_Depend to treat n-level namespaces as packages would be even more valuable. Using the package tag only requires developers to be explicit about something obvious, so that would be ideal.

I am very interested in resolving this short term, so if there is a workaround or patch I can apply I would be very appreciative :)

[ghost]

Perhaps unneeded additional clarification: the metrics have very limited value because the unit of reusability we actually use (a composer package) does not match the one used by PHP_Depend. PSR-0 makes namespacing partly a matter of organizing your code base, and in most cases using sub-namespaces of a package at the very least produces a less interesting metric than inter-package dependecies vs abstraction. I'm not saying that using namespaces as a unit of reusability is not a valid approach, but I am saying it is certainly not the only approach and not ours. Another factor for us is the fact that we use Symfony2, all our bundles are Composer packages. S2 expects certain conventions with regards to namespacing / file organisation of bundles, making PHP_Depends current assumptions an obstacle.

[Vinai]

👍
Especially with PSR-4 using namespaces to reflect the folder structure, they are not a good component indicator.
Being able to use the @package class annotation and have it being used instead of namespaces if present would also resolve this issue.

[ravage84]

Would a namespace to package mapping in the PHP Depend configuration XML file work?