I was happy to find a tutorial for my use-case at. In hindsight, the configuration of the NGINX web server proved to be the majority of the work. To set up these services correctly, we need to configure NGINX to use HTTPS and function as a reverse proxy for Nexus. My setup consists of a Docker Compose file that defines two services: a Sonatype Nexus 3, and an NGINX reverse proxy. The remainder of this post discusses how I set up such an artifact repository for Opencraft. It turns out that we can meet both requirements by using our own artifact repository. It also means that, once a SNAPSHOT version of a dependency is used to compile Opencraft, that SNAPSHOT may no longer change (Requirement 2). These requirements mean that dependencies must be permanently available, in case an older version of the code needs to be compiled (Requirement 1). The Opencraft binary only changes if its own source code changes. We can compile previous versions of Opencraft years after they have been used for experiments.This introduces two important requirements: Opencraft is a research project, which means many students and researchers use it to conduct their experiments. Only the x-most recent versions of these SNAPSHOTS are available from their artifact repository.They exclusively use SNAPSHOT versions, no releases.Specifically, these dependencies introduce two challenges: Although this works well for the majority of the dependencies, there a few dependencies that are more difficult to manage. Opencraft has tens of software dependencies, which are obtained from external sources by Maven. As part of this project, we design and develop our own large-scale Minecraft-like game, also called Opencraft. The goal of Opencraft is to discover and evaluate novel scalability techniques for large-scale online games. After struggling with sharing Maven artifacts for longer than I want to admit, I finally set up a dedicated artifact repository for Opencraft.įor my PhD, I work on a research project called Opencraft.
0 kommentar(er)
