Contributing

NetLogo Web and its constituent projects, Galapagos and Tortoise, are open source software and we welcome contributions. If you've read the Technical Details and got your local repositories Building and Running you should be ready to contribute.

Git Usage and Branching

Development is expected to follow pretty standard git best practices, like using atomic commits with good, clear messages and doing work on side-branches instead of on master. Depending on the size of the work, good names for working branches are things like wip-feature-name (wip for "work in progress") as well as topic-feature-name for those projects that are larger in scope.

Testing

Galapagos includes some automated tests, but at the moment most feature testing for model runs is done manually in the browser. It can be helpful to create special "feature test" NetLogo models that can be quickly loaded and checked to see if the changes are successful or not.

Publishing Tortoise Changes

If you have made changes in the Tortoise repository and you want to try them out in the browser using Galapagos, do the following:

• Launch ./sbt.sh in the Tortoise repository, if you haven't already.
• Run publishLocalVersioned netLogoWeb.
• Run publishLocalVersioned compilerJVM.

This will publish the two Tortoise .jars to your local .jar repository (~/.ivy2), which will make them accessible to you in your local copy of Galapagos.

• Find the new version hash that was just published. You can check Git or from the logs that printed during publishLocalVersioned.
  • Example log entry: [info] Packaging ~/Github/Tortoise/netlogo-web/target/netlogowebjs-1.0-e9dc67a.jar ...
  • So $VERSION_HASH should be e9dc67a
• Copy the new version hash into the Galapagos repository's build.sbt, where we set tortoiseVersion.
  • Example: val tortoiseVersion = "1.0-$VERSION_HASH" or val tortoiseVersion = "1.0-e9dc67a" as per the above.

It is important to note that if you did not commit your work in the Tortoise repository, the version will be something like 1.0...$VERSION_HASH-dirty. So make sure to include -dirty in your build.sbt version if that is that case.