diff --git a/developers.adoc b/developers.adoc index 9fe9cb8..9665840 100644 --- a/developers.adoc +++ b/developers.adoc @@ -84,6 +84,25 @@ automatically. It shouldn't really matter even which version of sbt you use for bootstrap, as sbt will pull relevant sbt update packages automatically as well. +=== Configuring proxy + +Note, that if you behind proxy, you need to run `sbt` with flags +[source] + -Dhttp.proxyHost= + -Dhttp.proxyPort= + -Dhttps.proxyHost= + -Dhttps.proxyPort= + +for example +[source,shell] + sbt -Dhttp.proxyHost=proxy.com -Dhttp.proxyPort=3128 -Dhttps.proxyHost=proxy.com -Dhttps.proxyPort=3128 + +Unfortunately, `sbt` doesn't understand `http(s)_proxy` environment variable properly, if it contains +address of proxy server in `host:port` format, so flags is necessary. + +This flags needed only on first run or when you want to check and upgrade dependencies. After first `sbt` +run all dependencies will be downloaded and access to the internet not required anymore. + === Building for JVM We use http://www.scala-sbt.org/sbt-native-packager/[sbt-native-packager] to @@ -175,6 +194,55 @@ actually be JavaScript libraries, not Java jars. . Go to https://oss.sonatype.org/#stagingRepositories . Continue to follow Java runtime publishing instructions +== Developing new feature + +Usually, you will develop new feature in your own fork of sub-project and then +make a PR when you are done. But because integration tests are in your own repository, +the question arises as to how to test your work. + +You can easily clone https://github.com/kaitai-io/kaitai_struct, and then replace contents +of sub-project folder with contents of you sub-project fork. That will give you the very same +environment, but with your changes. the right way to do this it is use git submodules. +To do this, you need to do the following: + +[source,shell] + # Assumed, that this will be done + # git clone --recursive https://github.com/kaitai-io/kaitai_struct.git + # cd kaitai_struct + # + # Select subproject you want to modify + cd ${sub-project} + # See current status + git remote -v + # Add your repository as remote with name my-repo + git remote add ${my-repo} https://github.com/${my-repo}/${sub-project}.git + # Check youself + git remote -v + # Get you work + git fetch ${my-repo} + # or, if you want to fetch only one branch `my-feature`. Use local branch name, + # without repository name prefix, ie. just `some-feature` but not `my-repo/some-feature` + # git fetch ${my-repo} ${my-feature} + # + # Switch to you feature branch + git checkout ${my-feature} + +Also, you can use `use-fork.sh` script in the root project to automate there things. +Repeat this for all forks you want to work with. After that you can test you changes +as described below. + +For example, if you want to test parallel changes in the compiler and Java runtime, use: +[source,shell] + ./use-fork.sh compiler myGithubName my-compiler-branch + ./use-fork.sh runtime java myGithubName my-runtime-branch + cd tests + ./build-compiler + # Convert all test `.ksy` formats into all target languages (including Java), + # which will give you tests/compiled/java + ./build-formats + # will run all the tests for Java; results will be in `tests/test_out/java` + ./run-java + == Tests TODO