-
Notifications
You must be signed in to change notification settings - Fork 26
Resubmitting an Extension for Listing in NetLogo 7
If you had an extension listed in the Extension Manager for NetLogo 6, it will not be automatically listed in NetLogo 7. Loading extensions that target old versions of the NetLogo API raises a warning to users that they might be loading code that is incompatible with the current API. It's possible (and even likely) that NetLogo 6 extensions can work in NetLogo 7 without any changes to the code, but that is not something that can be confidently known without compiling the extension against NetLogo 7 and testing it. We require extension authors to do that updating, compilation, and testing, and to resubmit the extension as a new pull request in this repository, before we list that extension for users to download in NetLogo 7.
First, you must obtain a recent version of the NetLogo .jar file to compile against.
If you use a tool other than SBT to manage the version of NetLogo that you compile against (like Maven or Gradle), you can find instructions here for how to get the latest NetLogo version. Some extension authors download and build against the plain netlogo-<xyz>.jar file (which can be downloaded from that link), but we don't generally recommend doing this, because most extensions will also need several of NetLogo's dependencies on their classpath in order to compile. Tools like Maven, Gradle, and SBT can handle the dependency-management for you.
Doing this with SBT is easy, and works for both Java and Scala code. Once SBT has been installed, you can use the String extension as an example, copying the build.sbt file and project directory, and replacing most of the string values in build.sbt to be accurate to your own extension. Then, you can open your extension's directory in your terminal and run sbt compile to compile your code. When doing so, you may want to update the netLogoVersion key in build.sbt to use 7.0.0-beta2-de24f27, which is the most recent NetLogo beta snapshot.
While it varies from one extension to the next, NetLogo 7 will not require most extensions to make substantial (if any) changes to their code. If your extension was written in Scala 2, it will need to be updated to use Scala 3, but most third-party extensions are written in Java and don't have much to worry about. The main NetLogo API changes moving classes to new packages, things being renamed, or changing the number of arguments passed to a function, and the main functionality affected by these sorts of changes was the code for the graphical interface.
Once your extension is compiling against the latest NetLogo version and working as expected, you need to package it.
If you build the packages manually or with Makefiles, be sure to update the NetLogo-Extension-API-Version value in your manifest file to be 7.0, and then build a .zip file that contains your extension's .jar file (with the manifest inside of it), the .jar files of all dependencies and transitive dependencies, and any supporting files (e.g. demo models) that you want included with your extension.
With SBT, you can simply run sbt packageZip from your terminal, and it will generate the .zip file for you, including all of your required dependencies, supporting files, and the appropriate extension manifest file. The packageZip command will also provide you with the information needed for libraries.conf in the next step.
Once everything is bundled into a .zip, it's time to upload it. Fork this branch, add your .zip file to the extensions folder, and update the libraries.conf file with the appropriate information (name, codeName, shortDescription, longDescription, version, homepage). Note that the downloadURL key is no longer used in the libraries.conf file, and, instead, all extension bundles must use the naming format <codeName>-<version>.zip, placed within the extensions folder. Once your fork contains a commit that adds your extension, open a pull request here.