Skip to content

Local Development

Jump to bottom
naraesk edited this page Nov 13, 2020 · 19 revisions

This side is under construction and incomplete. If something doesn't work, chances are good the mistake isn't yours. If you encounter any problems, please open an issue and we'll have a look at it.

Follow these steps to prepare your local environment for the development of Getaviz. Currently, they do not work for Windows Home.

Generator Development

Setting up Environment

  1. Install maven
  2. Go to the directory generator2/org.getaviz.generator/ and run mvn install to build the generator.
  3. Run docker-compose down in the root directory to stop all Getaviz containers.
  4. Open the file docker-compose.yml in the root directory and uncomment all lines marked with uncomment only for generator development. This will mount the local files into the respective container. This means that not all containers have to be rebuilt after local changes have been made. It is enough to rerun mvn install.
  5. Run docker-compose up to start the containers again
  6. Optional: * When you just need the generator and the user interface you can safely comment out the db service and the eval service from docker-compose.yml. This will reduce the starting time of the containers.

Testing and Debugging (with Docker)

  • After you make changes to the generator you have to run mvn package. This rebuilt the war package. If you have followed step 4 of section instructions, the new war package will be used automatically from the docker container when accessing http://localhost:8082/ui/index.php. With this approach, you can go through the complete visualization process and view the result in the user interface. This is helpful from time to time, but it is much more efficient to write unit tests that do not access Docker as described in the next section.

  • The logs for the generator can be found in /var/lib/jetty/logs/jetty.log inside the docker container

  • The generated visualizations can be found in /var/lib/jetty/data-gen. Usually, it is not necessary to access them manually. In this case consider writing a unit test as described in the next section.

  • You can explore the database using the neo4j Browser through http://localhost:7474/

  • Usually, rebuilding the complete docker container is not necessary, building the generator with maven will be enough. Rebuilding the container is only necessary if the Dockerfile itself has been changed (locally or in the main repository). In theory, this should not happen very often. Should it ever be necessary, it is done with the following command executed in the root directory: docker-compose build --no-cache backend

Testing and Debugging (without Docker)

  • Generator2 contains some unit test cases. They are executed locally (i.e., without docker) because it is faster and the debugger can be used. It is recommended to implement your own test cases. You can run them via maven using mvn test or you can execute the tests via IntelliJ.

  • Some test cases require a neo4j database which contains a scanned java system. Currently, only the Bank system is part of the repository. Bank.java executes the cypher script in org.getaviz.generator/src/test/resources/Bank.cypher to provide a running neo4j database under http://localhost:7689

  • Only you a neo4j database when unavoidable. Most test cases should work without a database.

UI Development

  1. Run docker-compose down in the root directory to stop all Getaviz containers.
  2. Open the file docker-compose.yml in the root directory and uncomment all lines marked with uncomment only for ui development. This will mount the local files into the respective container. This means that not all containers have to be rebuilt after local changes have been made.
  3. Install Node.js
  4. Run npm install in the ui directory
  5. Run docker-compose up from the root directory to start the containers again

You can now make changes to the user interface that will be applied immediately when accessing http://localhost:8082/ui/index.php

Usually, rebuilding the container is not necessary. This is only necessary if the Dockerfile itself has been changed (locally or in the main repository). In theory, this should not happen very often. Should it ever be necessary, it is done with the following command executed in the root directory: docker-compose build --no-cache frontend

Clone this wiki locally