Update vendor libraries and pin them to specific versions in composer.json

As long as we can still pin to specific commits (since right now we need some post-beta1 but pre-beta2 Symfony component updates), I'm OK with this in general for the time being.

easyrdf should use the tag 0.8.0-beta.1. This patch only touches easyrdf related fixes.

According to Fabien, Symfony 2.2-beta2 is due out in a day or two (try saying that 5 times fast), so we should probably sit tight for a bit and then pin that.

I narrowed down the test fails to this API change in symfony-cmf, which will be handled in #1894934: Update CMF Routing component.

It looks like a release of easyrdf came out a couple days ago. Is there anything that's holding us back from targeting 0.8.0-beta.1?
Ah, scor got it already :-) .

[EDIT] Once the updates go through, I'd like to #1805316: Move composer.json to the project root.

updating patch after #1894934: Update CMF Routing component was committed. we should still wait for the next beta release of symfony before committing this.

http://symfony.com/blog/symfony-2-2-0-beta-2-released

beta2 is out, let's do our thing.

symfony beta2 seems to wreck the installer (both the UI and drush cli) with the error You have requested a synthetic service ("request"). The DIC does not know how to construct this service.

trying out with beta1 to see if at least we can get our first green in this issue...

git apply complains about a missing full index. rerolling with --binary --full-index

#20: 1894002_pin_dependencies_beta1_20.patch queued for re-testing.

I haven't been able to review all the changes all the way up to BETA2 yet, but I found another API change in synfony (94f6116) which required to update our codebase (included in this patch).

The installer is still broken with the error "You have requested a synthetic service ("request"). The DIC does not know how to construct this service.", but commenting out the line that generates this message in createService() allows the installer to work. I'm curious to see how many tests are passing/failing with this hack, and hopefully that will give more insight on why this error is occurring during the install process.

Crell recommends to upgrade one at a time. I was able to do that until I hit dependency-injection. Here is a patch with everything pinned to beta2 except dependency-injection. let's see if everything works so far.

Turns out the problems occurring when upgrading to beta2 come from the fact that we register the "request" service as a synthetic service, and symfony doesn't know how to handle this: You have requested a synthetic service ("request"). The DIC does not know how to construct this service.

The installer and the JSON-LD and REST tests pass if we register "request" as a normal non-synthetic service. I'm not sure what the implications are, but let's see first how many tests are failing with this change.

Edit: possible explanation for this: that there was an API change a while back but we were not affected by it, and this API was only recently enforced with 4119ca. This is the only change I could find between our old version of symfony and beta2 involving isSynthetic(). Not being an expert on symfony, I could very well have missed something.

#27: 1894002_pin_dependencies_27.patch queued for re-testing.

+++ b/core/lib/Drupal/Core/CoreBundle.php
@@ -117,8 +117,7 @@ public function build(ContainerBuilder $container) {
-    $container->register('request', 'Symfony\Component\HttpFoundation\Request')
-      ->setSynthetic(TRUE);
+    $container->register('request', 'Symfony\Component\HttpFoundation\Request');

The 'request' service is logically a synthetic service, so this is masking a real bug: #1907750: Symfony update exposes fatal error during installation due to 'access_manager' service depending on 'request'. I don't mind us doing this as a temporary measure if the rest of this patch becomes ready for commit prior to solving that other issue, but we do need to solve that other issue.

#27: 1894002_pin_dependencies_27.patch queued for re-testing.

For easier review, here's all the manual changes that are in #27. The rest is fetched by Composer. This looks fine to me other than what I wrote in #31.

However, when I try running a composer update, I get this error:

  [RuntimeException]                                                                              
  Failed to clone http://github.com/njh/easyrdf.git via git, https and http protocols, aborting.  
                                                                                                  
  - git://github.com/njh/easyrdf.git                                                              
    fatal: No such remote 'composer'                                                              
                                                                                                  
  - https://github.com/njh/easyrdf.git                                                            
    fatal: No such remote 'composer'                                                              
                                                                                                  
  - http://github.com/njh/easyrdf.git                                                             
    fatal: No such remote 'composer'  

So, I can't verify that #27 represents the expected versions of everything. Any ideas on what's wrong with easyrdf, composer, or my computer?

@effulgentsia I often get this kind of error on random symfony components when running composer update, but now I always run rm -rf core/vendor before running composer update to avoid this.

Edit: this is the script I use:

cd core
rm -rf vendor
git co vendor/.gitignore
git co vendor/README.txt
composer update

Oh, right. I forgot about the need to do that. Thanks. #27 is good to go then.

I've posted a fix for the other issue as well. I agree we shouldn't leave this hack in here for too long, but I'm OK with this issue going in first since it's already RTBC.

Tagging, since this is a dependency for the revised WSCCI and SCOTCH sub-request stuff.

I got whitespace errors when applying the patch:

warning: squelched 3 whitespace errors
warning: 8 lines add whitespace errors.

Fine with the other issue being a follow-up, especially given it's major bug and already has patch at CNR. Committed/pushed this to 8.x.

Good that we're moving to specific versions in composer.json that makes a lot more sense.

People here may be interested in #1977570: Update third-party vendors and fix composer.json which is suggesting to remove version pinning via composer.json.