Store library paths relative to a given application root folder.

Store library paths relative to a given application root folder.

In kernel, library import URIs now support an "app" scheme as an
alternative to the "file" scheme, representing a path relative to
the application root.

dartk takes an --app-root flag giving the application root. If none
is given, file URIs are used instead.

The intention is that kernel binaries should not carry irrelevant
path information, such as the path to the home directory of the
user who compiled a given file.

It is not the intention that end-users should see an app URI.
Import paths are currently not shown to users at all, and if we need
to do this, they should be translated to file paths first.

In theory we could stick to file URIs with relative paths, but the Uri
class from dart:core makes this difficult, as certain operations on it
assume that file paths should be absolute.

Source mapping URIs are not yet affected by this change.

R=kmillikin@google.com

Committed: https://github.com/dart-lang/sdk/commit/60adb852ad706ecf9424c77d47fa05583d543def

Reverted: https://github.com/dart-lang/sdk/commit/bb540416f27c39d75ee7f243899939fc37a2cd03
Committed: https://github.com/dart-lang/sdk/commit/709c1e0b759425ca0924f1c032e0ac6345625318

[asgerf, 2016-11-29 11:11:28]

Description was changed from

==========
Store library paths relative to a given application root folder.

In kernel, library import URIs now have the "app" scheme instead of
the "file" scheme, representing a path relative to the application root.

dartk takes an --app-root flag indicating the application root. This
defaults to the current working directory.

The intention is that kernel binaries should not carry irrelevant
path information, such as the path to the home directory of the
user who compiled a given file.

It is not the intention that end-users should see an app URI.
Import paths are currently not shown to users at all, and if we need
to do this, they should be translated to file paths first.

In theory we could stick to file URIs with relative paths, but the Uri
class from dart:core makes this difficult, as certain operations on it
assume that file paths should be absolute.
==========

to

==========
Store library paths relative to a given application root folder.

In kernel, library import URIs now have the "app" scheme instead of
the "file" scheme, representing a path relative to the application root.

dartk takes an --app-root flag indicating the application root. This
defaults to the current working directory.

The intention is that kernel binaries should not carry irrelevant
path information, such as the path to the home directory of the
user who compiled a given file.

It is not the intention that end-users should see an app URI.
Import paths are currently not shown to users at all, and if we need
to do this, they should be translated to file paths first.

Source mapping URIs are not yet affected by this change.

In theory we could stick to file URIs with relative paths, but the Uri
class from dart:core makes this difficult, as certain operations on it
assume that file paths should be absolute.
==========

[asgerf, 2016-11-29 11:11:58]

Description was changed from

==========
Store library paths relative to a given application root folder.

In kernel, library import URIs now have the "app" scheme instead of
the "file" scheme, representing a path relative to the application root.

dartk takes an --app-root flag indicating the application root. This
defaults to the current working directory.

The intention is that kernel binaries should not carry irrelevant
path information, such as the path to the home directory of the
user who compiled a given file.

It is not the intention that end-users should see an app URI.
Import paths are currently not shown to users at all, and if we need
to do this, they should be translated to file paths first.

Source mapping URIs are not yet affected by this change.

In theory we could stick to file URIs with relative paths, but the Uri
class from dart:core makes this difficult, as certain operations on it
assume that file paths should be absolute.
==========

to

==========
Store library paths relative to a given application root folder.

In kernel, library import URIs now have the "app" scheme instead of
the "file" scheme, representing a path relative to the application root.

dartk takes an --app-root flag indicating the application root. This
defaults to the current working directory.

The intention is that kernel binaries should not carry irrelevant
path information, such as the path to the home directory of the
user who compiled a given file.

It is not the intention that end-users should see an app URI.
Import paths are currently not shown to users at all, and if we need
to do this, they should be translated to file paths first.

In theory we could stick to file URIs with relative paths, but the Uri
class from dart:core makes this difficult, as certain operations on it
assume that file paths should be absolute.

Source mapping URIs are not yet affected by this change.
==========

[asgerf, 2016-11-29 11:12:15]

Description was changed from

==========
Store library paths relative to a given application root folder.

In kernel, library import URIs now have the "app" scheme instead of
the "file" scheme, representing a path relative to the application root.

dartk takes an --app-root flag indicating the application root. This
defaults to the current working directory.

The intention is that kernel binaries should not carry irrelevant
path information, such as the path to the home directory of the
user who compiled a given file.

It is not the intention that end-users should see an app URI.
Import paths are currently not shown to users at all, and if we need
to do this, they should be translated to file paths first.

In theory we could stick to file URIs with relative paths, but the Uri
class from dart:core makes this difficult, as certain operations on it
assume that file paths should be absolute.

Source mapping URIs are not yet affected by this change.
==========

to

==========
Store library paths relative to a given application root folder.

In kernel, library import URIs now have the "app" scheme instead of
the "file" scheme, representing a path relative to the application root.

dartk takes an --app-root flag giving the application root. This
defaults to the current working directory.

The intention is that kernel binaries should not carry irrelevant
path information, such as the path to the home directory of the
user who compiled a given file.

It is not the intention that end-users should see an app URI.
Import paths are currently not shown to users at all, and if we need
to do this, they should be translated to file paths first.

In theory we could stick to file URIs with relative paths, but the Uri
class from dart:core makes this difficult, as certain operations on it
assume that file paths should be absolute.

Source mapping URIs are not yet affected by this change.
==========

[asgerf, 2016-11-29 11:15:51]

asgerf@google.com changed reviewers:
+ kmillikin@google.com

[Kevin Millikin (Google), 2016-11-29 11:19:29]

lgtm

[asgerf, 2016-11-29 11:40:22]

Description was changed from

==========
Store library paths relative to a given application root folder.

In kernel, library import URIs now have the "app" scheme instead of
the "file" scheme, representing a path relative to the application root.

dartk takes an --app-root flag giving the application root. This
defaults to the current working directory.

The intention is that kernel binaries should not carry irrelevant
path information, such as the path to the home directory of the
user who compiled a given file.

It is not the intention that end-users should see an app URI.
Import paths are currently not shown to users at all, and if we need
to do this, they should be translated to file paths first.

In theory we could stick to file URIs with relative paths, but the Uri
class from dart:core makes this difficult, as certain operations on it
assume that file paths should be absolute.

Source mapping URIs are not yet affected by this change.
==========

to

==========
Store library paths relative to a given application root folder.

In kernel, library import URIs now have the "app" scheme instead of
the "file" scheme, representing a path relative to the application root.

dartk takes an --app-root flag giving the application root. This
defaults to the current working directory.

The intention is that kernel binaries should not carry irrelevant
path information, such as the path to the home directory of the
user who compiled a given file.

It is not the intention that end-users should see an app URI.
Import paths are currently not shown to users at all, and if we need
to do this, they should be translated to file paths first.

In theory we could stick to file URIs with relative paths, but the Uri
class from dart:core makes this difficult, as certain operations on it
assume that file paths should be absolute.

Source mapping URIs are not yet affected by this change.

R=kmillikin@google.com

Committed:
https://github.com/dart-lang/sdk/commit/60adb852ad706ecf9424c77d47fa05583d543def
==========

[asgerf, 2016-11-29 11:40:24]

Committed patchset #1 (id:1) manually as
60adb852ad706ecf9424c77d47fa05583d543def (presubmit successful).

[asgerf, 2016-11-29 14:37:01]

Description was changed from

==========
Store library paths relative to a given application root folder.

In kernel, library import URIs now have the "app" scheme instead of
the "file" scheme, representing a path relative to the application root.

dartk takes an --app-root flag giving the application root. This
defaults to the current working directory.

The intention is that kernel binaries should not carry irrelevant
path information, such as the path to the home directory of the
user who compiled a given file.

It is not the intention that end-users should see an app URI.
Import paths are currently not shown to users at all, and if we need
to do this, they should be translated to file paths first.

In theory we could stick to file URIs with relative paths, but the Uri
class from dart:core makes this difficult, as certain operations on it
assume that file paths should be absolute.

Source mapping URIs are not yet affected by this change.

R=kmillikin@google.com

Committed:
https://github.com/dart-lang/sdk/commit/60adb852ad706ecf9424c77d47fa05583d543def
==========

to

==========
Store library paths relative to a given application root folder.

In kernel, library import URIs now support an "app" scheme as an
alternative to the "file" scheme, representing a path relative to
the application root.

dartk takes an --app-root flag giving the application root. If none
is given, file URIs are used instead.

The intention is that kernel binaries should not carry irrelevant
path information, such as the path to the home directory of the
user who compiled a given file.

It is not the intention that end-users should see an app URI.
Import paths are currently not shown to users at all, and if we need
to do this, they should be translated to file paths first.

In theory we could stick to file URIs with relative paths, but the Uri
class from dart:core makes this difficult, as certain operations on it
assume that file paths should be absolute.

Source mapping URIs are not yet affected by this change.

R=kmillikin@google.com

Committed:
https://github.com/dart-lang/sdk/commit/60adb852ad706ecf9424c77d47fa05583d543def
==========

[asgerf, 2016-11-29 14:38:13]

Description was changed from

==========
Store library paths relative to a given application root folder.

In kernel, library import URIs now support an "app" scheme as an
alternative to the "file" scheme, representing a path relative to
the application root.

dartk takes an --app-root flag giving the application root. If none
is given, file URIs are used instead.

The intention is that kernel binaries should not carry irrelevant
path information, such as the path to the home directory of the
user who compiled a given file.

It is not the intention that end-users should see an app URI.
Import paths are currently not shown to users at all, and if we need
to do this, they should be translated to file paths first.

In theory we could stick to file URIs with relative paths, but the Uri
class from dart:core makes this difficult, as certain operations on it
assume that file paths should be absolute.

Source mapping URIs are not yet affected by this change.

R=kmillikin@google.com

Committed:
https://github.com/dart-lang/sdk/commit/60adb852ad706ecf9424c77d47fa05583d543def
==========

to

==========
Store library paths relative to a given application root folder.

In kernel, library import URIs now support an "app" scheme as an
alternative to the "file" scheme, representing a path relative to
the application root.

dartk takes an --app-root flag giving the application root. If none
is given, file URIs are used instead.

The intention is that kernel binaries should not carry irrelevant
path information, such as the path to the home directory of the
user who compiled a given file.

It is not the intention that end-users should see an app URI.
Import paths are currently not shown to users at all, and if we need
to do this, they should be translated to file paths first.

In theory we could stick to file URIs with relative paths, but the Uri
class from dart:core makes this difficult, as certain operations on it
assume that file paths should be absolute.

Source mapping URIs are not yet affected by this change.

R=kmillikin@google.com

Committed:
https://github.com/dart-lang/sdk/commit/60adb852ad706ecf9424c77d47fa05583d543def

Reverted:
https://github.com/dart-lang/sdk/commit/bb540416f27c39d75ee7f243899939fc37a2cd03
==========

[asgerf, 2016-11-29 14:41:51]

PTAL at patch #2

The issue with files outside the application root has been resolved.

[Kevin Millikin (Google), 2016-11-30 07:19:03]

LGTM.

[asgerf, 2016-11-30 09:39:53]

Description was changed from

==========
Store library paths relative to a given application root folder.

In kernel, library import URIs now support an "app" scheme as an
alternative to the "file" scheme, representing a path relative to
the application root.

dartk takes an --app-root flag giving the application root. If none
is given, file URIs are used instead.

The intention is that kernel binaries should not carry irrelevant
path information, such as the path to the home directory of the
user who compiled a given file.

It is not the intention that end-users should see an app URI.
Import paths are currently not shown to users at all, and if we need
to do this, they should be translated to file paths first.

In theory we could stick to file URIs with relative paths, but the Uri
class from dart:core makes this difficult, as certain operations on it
assume that file paths should be absolute.

Source mapping URIs are not yet affected by this change.

R=kmillikin@google.com

Committed:
https://github.com/dart-lang/sdk/commit/60adb852ad706ecf9424c77d47fa05583d543def

Reverted:
https://github.com/dart-lang/sdk/commit/bb540416f27c39d75ee7f243899939fc37a2cd03
==========

to

==========
Store library paths relative to a given application root folder.

In kernel, library import URIs now support an "app" scheme as an
alternative to the "file" scheme, representing a path relative to
the application root.

dartk takes an --app-root flag giving the application root. If none
is given, file URIs are used instead.

The intention is that kernel binaries should not carry irrelevant
path information, such as the path to the home directory of the
user who compiled a given file.

It is not the intention that end-users should see an app URI.
Import paths are currently not shown to users at all, and if we need
to do this, they should be translated to file paths first.

In theory we could stick to file URIs with relative paths, but the Uri
class from dart:core makes this difficult, as certain operations on it
assume that file paths should be absolute.

Source mapping URIs are not yet affected by this change.

R=kmillikin@google.com

Committed:
https://github.com/dart-lang/sdk/commit/60adb852ad706ecf9424c77d47fa05583d543def

Reverted:
https://github.com/dart-lang/sdk/commit/bb540416f27c39d75ee7f243899939fc37a2cd03
Committed:
https://github.com/dart-lang/sdk/commit/709c1e0b759425ca0924f1c032e0ac6345625318
==========

[asgerf, 2016-11-30 09:39:54]

Committed patchset #3 (id:40001) manually as
709c1e0b759425ca0924f1c032e0ac6345625318 (presubmit successful).