-
Notifications
You must be signed in to change notification settings - Fork 29
Repos
Scripters, coders, installers, hackers, and admins (see Glossary) for the meanings of these user roles) all have different ways that they want to consume the deliverables. We need to decouple the way we organize our code and development, from the way that we distribute the results.
Equally, we need to anticipate a possible surge in popularity, with a number of related projects that have different drivers and schedules. We can do this technically (a plugin architecture) but we also need to do it organizationally (different repos.)
I propose a GitHub organization called Jycraft with a number of repos for different aspects of the project. The Jycraft-level GitHub organization will have the home page and the generated, Travis-tested, bundled consumables offered to outsiders, for those things blessed by the organization. Repos represent each unit that might be different based on: person driving, technology used, release schedule, and target audience.
Below are some possible repos based on current code and discussions.
This has the Pelican-generated website (at jycraft.) It also hosts the jycraft bootstrapper (see next heading) binary, delivered by the RawGit CDN. It likely also hosts all the Travis-passing plugins, although that part might change if we adopt something like a devpi private repo.
When people start to use Jycraft, they download this. It's a jar file which bootstraps the universe. See Install Experience. This is very focused on Java developers, toolchains, etc. It produces a versioned jar file, plus technical docs. It has an important release schedule: we don't want this thing to change very often.
Our bootstrapper will be written in Python, so this will have Jython in the JAR. It would be a shame to have another download for Jython, so this might also be the JAR file used by the actual server interpreter, to get the Python interpreter.
It will also need some things baked into the JAR which hopefully won't change very often: Python standard library stuff (including machinery used by pip), click (the Python package for command-line parsing), and whatever cookiecutter-like scaffolding approach we use.
This is a cookiecutter-like scaffold defining the fastest way to build a full site. It scripts the getting of a number of things, by asking the user questions for configuration: fetch CanaryMod, generate a eula, get our packages, generate directory structure, then run java -jar canarymod.jar (or Spigot).
This repo, like others, produces a Cookie Cutter scaffold that is not installed into site-packages.
This is a Java-oriented repo. Cloning it gives you something that feels like Java development. It produces the software that integrates into the CanaryMod or Spigot APIs. Hopefully as small a surface area as possible. It would be great to move more of the other stuff over to Python.
Long-term, one of the most valuable parts of the ecosystem. The software (hopefully in Python) which manages the installation, removal, discovery, loading, and unloading of plugins.
Similar to the above, but this is for the one-off script files left in a special directory.
The API which makes it a breeze for our target audience to interact with Minecraft.
A component which manages the pool of Python interpreters, inter-session communication, etc.
Self-explanatory, but hopefully moved over to Python.
Hopefully in Python.
Codecraft is one of the possible names for the web environment that does lots of cool social coding thingies in the future. Jycraft Builder is another possible name.
A tool aimed at administrators for managing a pool of Minecraft+Jycraft servers.
When doing development, much of the time you're in isolation. You won't need any Java, perhaps, to work on Codecraft. You might not need CanaryMod to work on jycraft_websocketserver. But when you do need a single environment for the universe, we can make a repo containing a buildout that simplifies getting all the pieces and producing output.