Skip to content

Import the PhantomJS env from the Scala.js core repository. #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 94 commits into from
May 21, 2017

Conversation

sjrd
Copy link
Member

@sjrd sjrd commented May 18, 2017

This is the initial import of the PhantomJS env and its sbt plugin from the Scala.js core repository. The history of this commit reflects the entire history of relevant files from the core repo, filter-branch'ed to appear as if they had always been in this repo. This commit adds the specific setup of the build and tests.

The history was obtained as follows, starting from commit scala-js/scala-js@f21e7f5 of the core repo.

First, we identified all the paths where relevant files have lived in the past, through renamings along their history. This is the list:

js-envs/src/test/scala/org/scalajs/jsenv/test/RetryingComJSEnvTest.scala
js-envs-test-suite/src/test/scala/org/scalajs/jsenv/test/RetryingComJSEnvTest.scala
phantomjs-env/src/test/scala/org/scalajs/jsenv/phantomjs/RetryingComJSEnvTest.scala

js-envs/src/main/scala/org/scalajs/jsenv/RetryingComJSEnv.scala
phantomjs-env/src/main/scala/org/scalajs/jsenv/phantomjs/RetryingComJSEnv.scala

sbt-plugin/src/test/scala/scala/scalajs/sbtplugin/test/env/PhantomJSTest.scala
js-envs/src/test/scala/org/scalajs/jsenv/test/PhantomJSTest.scala
js-envs-test-suite/src/test/scala/org/scalajs/jsenv/test/PhantomJSTest.scala
phantomjs-env/src/test/scala/org/scalajs/jsenv/phantomjs/PhantomJSTest.scala

js-envs-test-suite/src/test/scala/org/scalajs/jsenv/test/PhantomJSWithCustomInitFilesTest.scala
phantomjs-env/src/test/scala/org/scalajs/jsenv/phantomjs/PhantomJSWithCustomInitFilesTest.scala

sbt-plugin/src/main/scala/scala/scalajs/sbtplugin/env/phantomjs/*
js-envs/src/main/scala/org/scalajs/jsenv/phantomjs/*
phantomjs-env/src/main/scala/org/scalajs/jsenv/phantomjs/*

phantomjs-sbt-plugin/src/main/scala/org/scalajs/jsenv/phantomjs/sbtplugin/PhantomJSEnvPlugin.scala

sbt-plugin-test/build.sbt
sbt-plugin-test/jetty9/src/main/resources/test.txt
sbt-plugin-test/project/Jetty9Test.scala
sbt-plugin-test/project/build.sbt

Based on that, we filter-branch'ed to keep only those files, using the following incantation, inspired by http://stackoverflow.com/a/6006679/1829647:

git filter-branch \
    --prune-empty \
    --index-filter '
  git ls-tree -z -r --name-only --full-tree $GIT_COMMIT \
    | grep -z -v "^js-envs/src/test/scala/org/scalajs/jsenv/test/RetryingComJSEnvTest.scala$" \
    | grep -z -v "^js-envs-test-suite/src/test/scala/org/scalajs/jsenv/test/RetryingComJSEnvTest.scala$" \
    | grep -z -v "^phantomjs-env/src/test/scala/org/scalajs/jsenv/phantomjs/RetryingComJSEnvTest.scala$" \
    | grep -z -v "^js-envs/src/main/scala/org/scalajs/jsenv/RetryingComJSEnv.scala$" \
    | grep -z -v "^phantomjs-env/src/main/scala/org/scalajs/jsenv/phantomjs/RetryingComJSEnv.scala$" \
    | grep -z -v "^sbt-plugin/src/test/scala/scala/scalajs/sbtplugin/test/env/PhantomJSTest.scala$" \
    | grep -z -v "^js-envs/src/test/scala/org/scalajs/jsenv/test/PhantomJSTest.scala$" \
    | grep -z -v "^js-envs-test-suite/src/test/scala/org/scalajs/jsenv/test/PhantomJSTest.scala$" \
    | grep -z -v "^phantomjs-env/src/test/scala/org/scalajs/jsenv/phantomjs/PhantomJSTest.scala$" \
    | grep -z -v "^js-envs-test-suite/src/test/scala/org/scalajs/jsenv/test/PhantomJSWithCustomInitFilesTest.scala$" \
    | grep -z -v "^phantomjs-env/src/test/scala/org/scalajs/jsenv/phantomjs/PhantomJSWithCustomInitFilesTest.scala$" \
    | grep -z -v "^sbt-plugin/src/main/scala/scala/scalajs/sbtplugin/env/phantomjs/" \
    | grep -z -v "^js-envs/src/main/scala/org/scalajs/jsenv/phantomjs/" \
    | grep -z -v "^phantomjs-env/src/main/scala/org/scalajs/jsenv/phantomjs/" \
    | grep -z -v "^phantomjs-sbt-plugin/src/main/scala/org/scalajs/jsenv/phantomjs/sbtplugin/PhantomJSEnvPlugin.scala$" \
    | grep -z -v "^sbt-plugin-test/build.sbt$" \
    | grep -z -v "^sbt-plugin-test/jetty9/src/main/resources/test.txt$" \
    | grep -z -v "^sbt-plugin-test/project/Jetty9Test.scala$" \
    | grep -z -v "^sbt-plugin-test/project/build.sbt$" \
    | xargs -0 -r git rm -r --cached
  ' HEAD

That gave the result visible in https://github.com/sjrd/scala-js-env-phantomjs/tree/import-from-core-step1. Unfortunately, --prune-empty does not prune empty merge commits. We fixed that using the solution found in http://stackoverflow.com/a/38420284/1829647:

git filter-branch --prune-empty --parent-filter 'sed "s/-p //g" | xargs -r git show-branch --independent | sed "s/\</-p /g"'

giving https://github.com/sjrd/scala-js-env-phantomjs/tree/import-from-core-step2

Now, we had a clean history, except that it was orphaned wrt. the Initial commit of this repository, which is 51c45de. To have a nice PR with a history that appears to have come from the Initial commit, we reattached the first meaningful commit to the Initial commit using:

git filter-branch --parent-filter 'sed "s/ca1d58a31e27756c0d07fd65fbfdb1a3e0c6642e/51c45de4e5079a999abe964bc0e06dadcac8e789/"'

which yielded https://github.com/sjrd/scala-js-env-phantomjs/tree/import-from-core-step3.

Almost there, except that now the files from the Initial commit have been removed in the first meaningful commit of the filter-branch. We restored them using:

git filter-branch --index-filter 'git reset 51c45de4e5079a999abe964bc0e06dadcac8e789 -- .gitignore LICENSE README.md'

giving the history in https://github.com/sjrd/scala-js-env-phantomjs/tree/import-from-core-step4.

As a final polish, we rewrite, in commit messages, references to tickets of the form #123 to scala-js/scala-js#123, so that they point to issues in the scala-js/scala-js repository. This is done using the following incantation:

git filter-branch --msg-filter 'sed -r -e "s/(#[0-9]+)/scala-js\/scala-js\1/g"'

and gives the result in https://github.com/sjrd/scala-js-env-phantomjs/tree/import-from-core-step5.

This PR is one commit on top of that final step.

gzm0 and others added 30 commits May 2, 2014 16:50
- Fix scala-js/scala-js#442: Add Phantom.js environment
- Add a setting whether a project requires the DOM
…s#958)

This commit removes support for `__ScalaJSExportsNamespace`. Use
`__ScalaJSEnv.exportsNamespace` instead.
Note that we cannot use the AutoPlugin in our build itself,
because we need the *abstract* set of settings. However, the
AutoPlugin is tested in sbt-plugin-test.
This hopefully simplifies build definitions that need to tweak some
command line options or just force a given environment.

At the same time, this also fixes scala-js/scala-js#1302 (use proper class loader for
PhantomJSEnv in our CI).
Rename former RuntimeDOM to RuntimeDOMDep to avoid import conflicts.
sjrd added 5 commits April 10, 2017 21:06
…SEnv API.

`JSEnv#jsRunner` and friends `asyncRunner` and `comRunner` now
only take a `Seq[VirtualJSFiles]`, containing all JS files to be
given to the JS environment.

The JS environments therefore make no distinction between "library"
files and the "code" file. The disinction was arbitrary anyway,
and unifying them makes sure that all the JS files are first-class.
In particular, it forced to solve shortcomings in terms of error
handling in `JSDOMNodeJSEnv`.
…nker).

The previous test had basically been inhibited when we switched
the default environment from Rhino to Node.js. Indeed, this caused
`loadedJSEnv` not to use the linker itself, but rather depend on
the result of `fastOptJS`. The test was therefore not testing
anything anymore.

We restore this test in a more explicit and robust way, with a
custom task to concurrently use the linker of `fullOptJS`, and a
dedicated test task to directly depend on the former + `fullOptJS`.
We use `fullOptJS` instead of `fastOptJS` because it takes more
time, increasing the likelihood of concurrent execution.
…loadedJSEnv.

We remove `resolvedJSEnv` simply by initializing `jsEnv` by default
in the project scope, and using `jsEnv` instead of `resolvedJSEnv`.

We remove `loadedJSEnv` by using instead the pair
`jsEnv` + `jsExecutionFiles` explicitly.

Finally, we can remove `JSEnv.loadLibs`, as it was only useful for
`loadedJSEnv`.
Only trivial merge conflicts.

Additionally, the partest `run/t1430` and `run/t4729` are moved
to the blacklist in 2.12.2 and 2.13.0-M1. This brings those two
versions up to par with 2.12.0 and 2.12.1, for which they had been
blacklisted in 497e463.
@sjrd sjrd requested a review from gzm0 May 18, 2017 15:01
@sjrd sjrd force-pushed the import-from-core branch 6 times, most recently from 3b54dbd to f148967 Compare May 18, 2017 22:01
@sjrd
Copy link
Member Author

sjrd commented May 18, 2017

Phew ... managed to get it green. I had to resort to using coursier on Travis, because the normal ivy resolution was simply killing all the time allocated to jobs on Travis!

Ping @gzm0. Since it's a new repo, I'm not sure you received earlier notifications.

@gzm0
Copy link
Contributor

gzm0 commented May 20, 2017

Will the references to issues "in the future" (e.g. fix #2883) make our life harder in the future?

If yes, consider s/(#[0-9]+)/sjs\1/g

I'm still reviewing the rest.

@gzm0
Copy link
Contributor

gzm0 commented May 20, 2017

The longer I think of it, the more unsure I get about importing the history. I do not understand what it buys us. IIUC, those commits won't build anyways, so we will not have bisecting capabilities or something.

Have you considered just replacing everything with a commit saying "copied from scala/scala@..."? Yes, that would make us lose the history if we lose Scala.js, but then again, this would make this repo quite useless.

Ok, I now understand that it gives us blame capabilities. So maybe we should retain it.

I'll proceed with reviewing the filter branch procedure and the last commit.

@sjrd
Copy link
Member Author

sjrd commented May 20, 2017

Ok, I now understand that it gives us blame capabilities. So maybe we should retain it.

Yes, it's essentially for the blames.

@sjrd
Copy link
Member Author

sjrd commented May 20, 2017

Will the references to issues "in the future" (e.g. fix #2883) make our life harder in the future?

Hum, good point. Yes, I think you're right and we should rewrite those.

@gzm0
Copy link
Contributor

gzm0 commented May 20, 2017

Yes, I think you're right and we should rewrite those.

If you are doing this and you need to repeat step 3 and step 4, note that I think they are just a convoluted way to do a rebase --onto.

@sjrd
Copy link
Member Author

sjrd commented May 20, 2017

Nah I'll do that as a step 5.

A rebase --onto flattens out all merges, so not good to import a history. (plus, it reassigns the "committer" field--different from "author"--, not a big deal but still annoying for an entire history)

@gzm0
Copy link
Contributor

gzm0 commented May 20, 2017

A rebase --onto flattens out all merges, so not good to import a history

Ah, ah, indeed.

.travis.yml Outdated
- oraclejdk8
install:
- mkdir -p $HOME/.sbt/0.13/plugins/
- echo 'addSbtPlugin("io.get-coursier" % "sbt-coursier" % "1.0.0-RC3")' > $HOME/.sbt/0.13/plugins/coursier.sbt
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider commenting why you need coursier.

sbt ++$TRAVIS_SCALA_VERSION testAdapter/publishLocal sbtPlugin/publishLocal &&
sbt ++2.11.11 compiler/publishLocal library/publishLocal testInterface/publishLocal
fi
- cd ..
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to double check, this will all go away (starting at git clone .../scala-js.git) once we have a published version of SJS 1.x, right? (comment?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, indeed.

directories:
- $HOME/.ivy2/cache
- $HOME/.sbt
- $HOME/.coursier/cache
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to double check: Neither ivy nor coursier copy local artifacts to the cache? Otherwise this would be a problem, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No they don't ;) (I checked). Even if they did, each new publishLocal would override the previous thing anyway, and they would have to use the updated one, because otherwise it would simply be unbearable even for local iterative development.

This is the initial import of the PhantomJS env and its sbt
plugin from the Scala.js core repository. The history of this
commit reflects the entire history of relevant files from the core
repo, filter-branch'ed to appear as if they had always been in
this repo. This commit adds the specific setup of the build and
tests.
@sjrd sjrd force-pushed the import-from-core branch from f148967 to 686d8a3 Compare May 20, 2017 16:30
@sjrd
Copy link
Member Author

sjrd commented May 20, 2017

Updated:

  • Point issue references to the scala-js/scala-js repo
  • Add requested comments in the .travis.yml

Copy link
Contributor

@gzm0 gzm0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants