docs: replace Bazel and Intellij documentation with SBT and VSCode (DEV-607)

.github/workflows/main.yml

@@ -187,7 +187,7 @@ jobs:
             {"type": "chore", "section": "Maintenance", "hidden": false },
             {"type": "refactor", "section": "Maintenance", "hidden": false },
             {"type": "docs", "section": "Documentation", "hidden": false }
-          ]'
+            ]'
 
   # publish only on release
   publish:

.gitignore

@@ -44,3 +44,7 @@ dependencies.txt
 metals.sbt
 
 .tmp/
+
+# exclude python virtual environments used for serving docs locally
+env/
+venv/

README.md

@@ -1,17 +1,17 @@
-# Knora — Knowledge Organization, Representation, and Annotation
+# DSP-API — DaSCH Service Platform API
 
 [![Github](https://img.shields.io/github/v/tag/dasch-swiss/dsp-api?include_prereleases&label=Github%20tag)](https://github.com/dasch-swiss/dsp-api)
 [![Docker](https://img.shields.io/docker/v/daschswiss/knora-api?label=Docker%20image)](https://hub.docker.com/r/daschswiss/knora-api)
 [![CI](https://github.com/dasch-swiss/dsp-app/workflows/CI/badge.svg)](https://github.com/dasch-swiss/dsp-api/actions?query=workflow%3ACI)
 
-[Knora](https://www.knora.org/) is a server application for storing, sharing, and working with primary sources and data in the humanities.
+[DSP API](https://admin.dasch.swiss/) is a server application for storing, sharing, and working with primary sources and data in the humanities.
 
 It is developed by the [Swiss National Data and Service Center for the Humanities](https://dasch.swiss)
 at the [University of Basel](https://www.unibas.ch), and is supported by the
 [Swiss Academy of Humanities and Social Sciences](https://www.sagw.ch) and
 the [Swiss National Science Foundation](https://snf.ch).
 
-Knora is [free software](http://www.gnu.org/philosophy/free-sw.en.html),
+DSP-API is [free software](http://www.gnu.org/philosophy/free-sw.en.html),
 released under the [Apache License, Version 2.0](http://www.apache.org/licenses/LICENSE-2.0).
 
 ## Features
@@ -39,10 +39,6 @@ released under the [Apache License, Version 2.0](http://www.apache.org/licenses/
 * [Knora Admin API](https://docs.knora.org/03-apis/api-admin/)
 * Distribution packaging using [Docker](https://www.docker.com/)
 
-### New features under development
-
-* See the [Roadmap](https://github.com/dasch-swiss/knora-api/wiki/Roadmap)
-
 ## Requirements
 
 ### For developing and testing the API server
@@ -129,7 +125,7 @@ implementing the desired functionality.
 
 Use `camelCase` for names of classes, variables, and functions. Make names descriptive, and don't worry if they're long.
 
-Use [Scalafmt](https://scalameta.org/scalafmt/) in [IntelliJ IDEA](https://www.jetbrains.com/idea) to format Scala code.
+Use [Scalafmt](https://scalameta.org/scalafmt/) in Visual Studio Code to format Scala code.
 
 Use whitespace to make your code easier to read.
 Add lots of implementation comments describing what your code is doing,
@@ -143,7 +139,6 @@ There are three sets of automated tests:
 
 * Unit tests, route-to-route tests, and end-to-end tests are under `webapi/src/test`. To run these, type `graphdb:test` or `graphdb-free:test` (depending on which triplestore you're using) at the SBT console in the `webapi` project. To run a single test, use `graphdb:test-only *NameOfTestSpec`.
 * Integration tests, which can involve [Sipi](https://github.com/daschswiss/sipi), are under `src/it`. To run these, first start Sipi, then type `it:test` at the SBT console in the `webapi` project.
-* Browser interaction tests are under `salsah/src/test`, and are written using [Selenium](https://www.seleniumhq.org). To run these, you will need to unpack the correct [ChromeDriver](https://sites.google.com/a/chromium.org/chromedriver/) for your platform found under `salsah/lib/chromedriver` and put it in the same folder. Then start Sipi and the Knora API server, and type `test` at the SBT console in the `salsah` project.
 
 Whenever you add a new feature or fix a bug, you should add one or more tests
 for the change you made.
@@ -175,15 +170,4 @@ data would be necessary, e.g., any changes to the Knora-Base ontologies which ar
 
 ## Release Notes Generation
 
-A pull request usually resolves one issue or user story defined on [Youtrack](https://dasch.myjetbrains.com/youtrack/). Since we started to use the [release-please-action](https://github.com/marketplace/actions/release-please-action) it's very important to set the PR title in the correct way, especially becuase all commits added within the pull request are squashed. Please read the official [DSP Contribution Documentation](https://docs.dasch.swiss/developers/dsp/contribution/#pull-request-guidelines) carefully!
-
-## Acknowledgments
-
-![YourKit](https://www.yourkit.com/images/yklogo.png)
-
-The Knora project is using YourKit for profiling.
-
-YourKit supports open source projects with its full-featured Java Profiler.
-YourKit, LLC is the creator of [YourKit Java Profiler](https://www.yourkit.com/java/profiler/)
-and [YourKit .NET Profiler](https://www.yourkit.com/.net/profiler/),
-innovative and intelligent tools for profiling Java and .NET applications.
+A pull request usually resolves one issue or user story defined on [Jira](https://dasch.atlassian.net/browse/DEV). Since we started to use the [release-please-action](https://github.com/marketplace/actions/release-please-action) it's very important to set the PR title in the correct way, especially because all commits added within the pull request are squashed. Please read the official [DSP Contribution Documentation](https://docs.dasch.swiss/developers/dsp/contribution/#pull-request-guidelines) carefully!

docs/05-internals/development/building-and-running.md

@@ -103,6 +103,12 @@ Lastly, to print out the entire logs of the running knora-stack, use
 $ make stack-logs
 ```
 
+With the Docker plugin installed, you can attach a terminal to the docker container within VS Code. This will stream the docker logs to the terminal window of the editor.
+
+![screenshot 'VSCode Docker'](figures/vscode-docker.png)
+
+The docker plugin also allows for a number of other useful features, like inspecting the container's file system or attaching a shell to the container.
+
 ## Running the automated tests
 
 To run all test targets, use the following in the command line:

docs/05-internals/development/index.md

@@ -6,13 +6,11 @@
 # Development
 
 - [Overview](overview.md)
-- [Starting GraphDB](graphdb.md)
 - [Build and Running](building-and-running.md)
-- [Setup IntelliJ for development of Knora](intellij-config.md)
+- [Setup Visual Studio Code for development of Knora](vscode-config.md)
 - [Testing](testing.md)
 - [Docker Cheat Sheet](docker-cheat-sheet.md)
 - [Monitoring Knora](monitoring.md)
-- [Profiling Knora](profiling.md)
 - [Starting the Knora Stack inside Docker Container](docker-compose.md)
 - [Updating Repositories](updating-repositories.md)
 - [Generating Client Test Data](generating-client-test-data.md)

docs/05-internals/development/overview.md

@@ -25,20 +25,7 @@ installation of Knora. The different parts are:
 A number of triplestore implementations are available, including [free
 software](http://www.gnu.org/philosophy/free-sw.en.html) as well as
 proprietary options. DSP-API is designed to work with any
-standards-compliant triplestore. It is primarily tested with [Ontotext
-GraphDB](http://ontotext.com/products/graphdb/), a high-performance,
-proprietary triplestore. We recommend GraphDB Standard Edition, but
-GraphDB Free (which is proprietary but available free of charge) also
-works.
-
-DSP-API includes support for [Apache Jena](https://jena.apache.org/),
-which is [free software](http://www.gnu.org/philosophy/free-sw.en.html),
-but use of Jena is deprecated, and support for it will probably be
-removed in the future.
-
-Built-in support and configuration for other triplestores is planned.
-
-See the chapter on [Starting GraphDB](graphdb.md) for more details.
+standards-compliant triplestore. It is primarily tested with [Apache Jena](https://jena.apache.org/).
 
 ## Sipi
 

docs/05-internals/development/third-party.md

@@ -1,16 +1,51 @@
 # Third-Party Dependencies
 
-The following section discusses on how third-party dependencies should be defined.
+Third party libraries are managed by SBT.
 
-Third-party dependencies are defined in the `third_party` folder. There are
-two main types of dependencies: (1) Maven library dependencies and (2) Docker
-image versions.
+## Defining Dependencies in `Dependencies.scala`
+
+Within the `build.sbt` file, the `Dependencies` package is referenced, which is located in `project/Dependencies.scala`.
+All third party dependencies need to be declared there:
+
+### Referencing a third party library
+
+There is an object `Dependencies` where each library should be declared in a `val`.
+
+```scala
+val akkaHttpCors = "ch.megard" %% "akka-http-cors" % "1.0.0"
+```
+
+The first string corresponds to the group/organization in the library's maven artefact,
+the second string corresponds to the artefact ID and the third string defines the version.
+
+The strings are combined with the `%`-operator or the `%%`-operator, the latter fixing the dependency to the specified scala-version.
+
+It is also possible to use variables in these definitions, e.g. if multiple dependencies share a version number:
+
+```scala
+val ZioVersion = "2.0.0-RC2"
+val zio = "dev.zio" %% "zio" % ZioVersion
+val zioTest = "dev.zio" %% "zio-test" % ZioVersion
+```
+
+### Assigning the dependencies to a specific subproject
+
+For each SBT project, there is one `Seq` in the `Dependencies` object.
+In order to make use of the declared dependencies, they must be referred to in the `Seq` of the respective subproject.
+
+```scala
+val webapiLibraryDependencies = Seq(
+    akkaActor,
+    akkaHttp,
+    akkaSlf4j % Runtime,
+    akkaHttpTestkit % Test,
+    ...
+)
+```
+
+By default, the dependencies will be scoped to compile time. But it's possible to override this to `Runtime` or `Test`.
 
-TODO add documentation for Dependencies.scala
 
 ## Docker Image Versions
 
-The required Docker image versions of `Sipi` and `Fuseki` are defined in the
-`third_party/versions.bzl` file. For the Docker images, the supplied digest
-hashes are relevant for getting the image. These digest hashes can be found
-on Docker-Hub when inspecting the tag of the Docker image in question.
+The required Docker image versions of `Sipi` and `Fuseki` are also defined in the `Dependencies.scala` file.