Update analysis server and indexer

Update analysis server and indexer
Committed: https://code.google.com/p/dart/source/detail?r=7591

[danrubel, 2012-05-12 22:39:21]

* construct dart source using relative paths
* add SystemLibraryManager conversion from file: to dart: path
* rework resource keys used to update indexer

[scheglov, 2012-05-13 15:39:18]

lgtm

[Brian Wilkerson, 2012-05-14 14:19:58]

I don't think I have enough context to understand these changes, so I find them
to be confusing. It looks like you're translating some "file:" URI's to "dart:"
URI's, but you're calling that "relative". Every time I see "relative" I ask
"relative to what?", but I don't think you mean "relative" in that sense. What
are you really doing here and why?

It looks like you've also changed the resource id's used by the indexer (though
it's possible that the changes are preserving the id's that would otherwise have
been different based on other changes). If that's the case, then (1) is this the
only place where resource id computation needs to be changed in order to keep
everything consistent? (2) what about places that convert resource id's back to
IResources? (3) Will stored indexes still be valid, or do we need to increment
the index version number so that they will be discarded?

https://chromiumcodereview.appspot.com/10391092/diff/6001/compiler/java/com/g...
File compiler/java/com/google/dart/compiler/SystemLibraryManager.java (right):

https://chromiumcodereview.appspot.com/10391092/diff/6001/compiler/java/com/g...
compiler/java/com/google/dart/compiler/SystemLibraryManager.java:150: public URI
getRelativeUri(URI fileUri) {
I don't have source available, but I seem to recall that the term "relative URI"
is used elsewhere in dartc to mean "relative to the current working directory".
Perhaps "getDartURI" would be less subject to confusion.

https://chromiumcodereview.appspot.com/10391092/diff/6001/compiler/java/com/g...
compiler/java/com/google/dart/compiler/SystemLibraryManager.java:151: // TODO
(danrubel): does not convert dart: libraries outside the dart-sdk/lib directory
This implies that libraries outside the SDK *should* be converted, but it isn't
clear to me why they should be.

https://chromiumcodereview.appspot.com/10391092/diff/6001/compiler/java/com/g...
compiler/java/com/google/dart/compiler/SystemLibraryManager.java:152: if
(fileUri == null || !fileUri.getScheme().equals("file")) {
nit: seems like there must be a constant for this somewhere

https://chromiumcodereview.appspot.com/10391092/diff/6001/editor/tools/plugin...
File
editor/tools/plugins/com.google.dart.tools.core/src/com/google/dart/tools/core/internal/index/impl/InMemoryIndex.java
(right):

https://chromiumcodereview.appspot.com/10391092/diff/6001/editor/tools/plugin...
editor/tools/plugins/com.google.dart.tools.core/src/com/google/dart/tools/core/internal/index/impl/InMemoryIndex.java:237:
Resource indexResource;
nit: Perhaps "resource" would be a better variable name here. The name
"indexResource" sounds like a verb rather than a noun.

[danrubel, 2012-05-16 04:26:36]

On 2012/05/14 14:19:58, Brian Wilkerson wrote:
> I don't think I have enough context to understand these changes, so I find
them
> to be confusing. It looks like you're translating some "file:" URI's to
"dart:"
> URI's, but you're calling that "relative". Every time I see "relative" I ask
> "relative to what?", but I don't think you mean "relative" in that sense. What
> are you really doing here and why?

Per our discussion, translating "file:" URIs back to "dart:" URIs, for use when
calling DartC and updating the index

> It looks like you've also changed the resource id's used by the indexer
(though
> it's possible that the changes are preserving the id's that would otherwise
have
> been different based on other changes). 

Per our discussion, I'm trying to match the resource ids generated by the
original DartC / DartBuilder so that AnalysisServer will update the index in the
same manner. Once we get AnalysisServer enabled in the main build and tested, we
can revisit and simplify the URI story.

https://chromiumcodereview.appspot.com/10391092/diff/6001/compiler/java/com/g...
File compiler/java/com/google/dart/compiler/SystemLibraryManager.java (right):

https://chromiumcodereview.appspot.com/10391092/diff/6001/compiler/java/com/g...
compiler/java/com/google/dart/compiler/SystemLibraryManager.java:150: public URI
getRelativeUri(URI fileUri) {
On 2012/05/14 14:19:58, Brian Wilkerson wrote:
> I don't have source available, but I seem to recall that the term "relative
URI"
> is used elsewhere in dartc to mean "relative to the current working
directory".
> Perhaps "getDartURI" would be less subject to confusion.

"getDartUri" would be a better name given it's current implementation, but we
are enhancing this method, the "tranlateUri" method, and the "expandUri" method
to support the "package:" URI scheme. If you have a better name that does not
include the word "dart" ...

https://chromiumcodereview.appspot.com/10391092/diff/6001/compiler/java/com/g...
compiler/java/com/google/dart/compiler/SystemLibraryManager.java:151: // TODO
(danrubel): does not convert dart: libraries outside the dart-sdk/lib directory
On 2012/05/14 14:19:58, Brian Wilkerson wrote:
> This implies that libraries outside the SDK *should* be converted, but it
isn't
> clear to me why they should be.

Agreed.

The "config" can be modified to point to something outside the dart-sdk
directory, and there is a request to support "dart:" libraries under development
outside the dart-sdk/lib directory ... thus the comment that this method
implementation could be enhanced in the future.

https://chromiumcodereview.appspot.com/10391092/diff/6001/editor/tools/plugin...
File
editor/tools/plugins/com.google.dart.tools.core/src/com/google/dart/tools/core/internal/index/impl/InMemoryIndex.java
(right):

https://chromiumcodereview.appspot.com/10391092/diff/6001/editor/tools/plugin...
editor/tools/plugins/com.google.dart.tools.core/src/com/google/dart/tools/core/internal/index/impl/InMemoryIndex.java:237:
Resource indexResource;
On 2012/05/14 14:19:58, Brian Wilkerson wrote:
> nit: Perhaps "resource" would be a better variable name here. The name
> "indexResource" sounds like a verb rather than a noun.

Good point, but I named it such to remind myself that this is not an eclipse
resource, but an indexer resource. Perhaps "indexerResource" rather than
"indexResource".