Split off link/url generation trait

Looks valid.

1. +++ b/core/lib/Drupal/Core/Breadcrumb/BreadcrumbBuilderBase.php
   @@ -7,57 +7,16 @@
   -  protected function l($text, $route_name, array $parameters = array(), array $options = array()) {
   
   +++ b/core/lib/Drupal/Core/Controller/ControllerBase.php
   @@ -232,32 +227,6 @@ protected function formBuilder() {
   -  public function l($text, $route_name, array $parameters = array(), array $options = array()) {
   

   Looks like we got different visibility and now it is protected? are we sure, no need for tests?

2. +++ b/core/lib/Drupal/Core/Routing/LinkGeneratorTrait.php
   @@ -0,0 +1,108 @@
   +  public function url($route_name, $route_parameters = array(), $options = array()) {
   

   Only public method in this trait is url(), but name is LinkGeneratorTrait and not UrLGeneratorTrait?

Thanks again @Crell. It looks good to me. +1 to RTBC. Created #2283385: Remove BreadcrumbBuilderBase as followup to remove the base class.

Ok then :)

I'm working on maintenance mode over at #2288665: Remove _maintenance request attribute and replace it with a maintenance mode service and #2288911: Use route name instead of system path in user maintenance mode subscriber. It looks like the various MaintenanceModeSubscriber might profit from an url-generator trait. In those classes it would be very helpful to also have the ContainerBase::redirect() method in the trait. On the other hand l() is completely unnecessary there.

A quick grep through the code base excluding yml, api.php, vendor, tests, interfaces and Drupal.php containing procedural wrappers turns up the following result: LinkGenerator is mentioned in 3 files, UrlGenerator in 29 files. Only two files are common (ControllerBase.php and LinkGenerator.php).

This raises the following questions:

1. It is probably debatable whether kernel-event subscribers qualify as application-level code. Opinions?
2. Is there a chance that the the ContainerBase::redirect() method is moved into the trait also?
3. Given that URL generator seems to be used much more often than the link generator, shouldn't we provide separate traits?

Patch looks good. Just a couple questions:

+++ b/core/lib/Drupal/Core/Routing/LinkGeneratorTrait.php
@@ -55,9 +48,22 @@ protected function l($text, $route_name, array $parameters = array(), array $opt
   protected function linkGenerator() {
...
+++ b/core/lib/Drupal/Core/Routing/UrlGeneratorTrait.php
@@ -0,0 +1,69 @@
+  protected function urlGenerator() {

When we added the StringTranslationTrait, we renamed the service getter method from translationManager() to getStringTranslation(). Along the same lines, should we prefix a "get" onto these two?

+++ b/core/lib/Drupal/Core/Routing/UrlGeneratorTrait.php
@@ -0,0 +1,69 @@
+ * Services registered
+ * in the Container should not use this trait but inject the appropriate service
+ * directly for easier testing.

This relates to #10.1 and the desire to use this trait within an event subscriber in #2288911: Use route name instead of system path in user maintenance mode subscriber. I agree that so long as the event subscriber is a service, which they all are pending #2023613: Move event registration from services.yml to events.yml, it should use constructor injection rather than a fallback to \Drupal::. However, couldn't it still use the trait along with CI (and e.g., ensure that by changing the setter to private)? If so, should we refine this comment to explain that?

Patch contains some coding style issues, but we can polish coding style at any later point in time.

Can we get an issue to remove BreadcrumbBuilderBase

Committed c072353 and pushed to 8.x. Thanks!

here it is #2283385: Remove BreadcrumbBuilderBase