Add instructions, how to develop new feature across multiply reposito…

…ries and add note about proxy

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=<your proxy server>
+  -Dhttp.proxyPort=<your proxy server port>
+  -Dhttps.proxyHost=<your proxy server>
+  -Dhttps.proxyPort=<your proxy server port>
+
+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