Hook for overriding the creation of a package resolver

pkg/analysis_server/lib/uri/resolver_provider.dart

Index: pkg/analysis_server/lib/uri/resolver_provider.dart
diff --git a/pkg/analysis_server/lib/uri/resolver_provider.dart b/pkg/analysis_server/lib/uri/resolver_provider.dart
new file mode 100644
index 0000000000000000000000000000000000000000..e6faad02a2a11dd1111ec5e289010600c05d289f
--- /dev/null
+++ b/pkg/analysis_server/lib/uri/resolver_provider.dart
@@ -0,0 +1,14 @@
+// Copyright (c) 2015, the Dart project authors.  Please see the AUTHORS file
+// for details. All rights reserved. Use of this source code is governed by a
+// BSD-style license that can be found in the LICENSE file.
+
+library analysis_server.uri.resolver_provider;
+
+import 'package:analyzer/file_system/file_system.dart';
+import 'package:analyzer/src/generated/source.dart';
+
+/**
+ * A function that will return a [UriResolver] that can be used to resolve some
+ * kind of URI within the given folder.

[Paul Berry, 2015/07/06 19:41:46]

Although technically there is nothing forcing the client to create a UriResolver
that resolves package URI's, the expectation is that that's what they will do
(as opposed to creating a FileUriResolver or some other such nonsense).  If they
don't create a UriResolver that resolves package URI's, they will get strange
and probably unexpected behaviors (since the analysis server uses a non-null
ResolverProvider as a signal that it should skip its default package resolution
mechanism).

I think we should explicitly document this expectation to avoid confusion, e.g.
'This function should return a UriResolver that resolves "package:" URI's.'

Also, this comment document the behavior you've implemented at line 444 of
context_manager.dart, namely that the resolver provider may return null to cause
the analysis server to fall back on its standard package resolution mechanism.

[Brian Wilkerson, 2015/07/06 20:07:18]

Done

+ */
+typedef UriResolver ResolverProvider(Folder folder);