Consolidating a few thoughts from other threads that I posted so I will be deleting them shortly..
I am concerned about how we will be installing/managing zips can be dificult to maintain and distribute. So I'm going to give some specific suggestions. This is all stuff I do for a living so I'm going to speak with some authority on the issue. I'll also go back and delete my posts in other threads since I'd like to keep this discussion in one place.
1. If we use zip files then everyone has to come up with their own way to manage and distribute their plugins.
2. We need a way to track versions and be able to see incremental builds or development (snapshot) builds and distribute them easily.
I suggest we consider using Maven to build and distribute our plugins. I just purchased a standalone copy of RW to confirm this but it looks like the standalone uses a helper application as Minecraft does so awesome bbq sauce! Now we need something simlar for plugins and possibly eventually distribution of the server jar with maybe a helper application (or script as well)
I personally manage a a few different maven repos at my job. Sonatype Nexus OSS is a free version that could possibly be integrated into rising-world.net. Not sure how it would link up with the current user database but it might be possible to make it a repository for our community only. I'm currently experimenting with Sonatype on my personal web server so I'll folow up on this when I can.
Now, Netbeans supports Maven-based projects. Here's a quick-start with screenshots. Essentially this allows you to build a jar following the versioning standard that Maven uses and I'll sumarize below:
So a few terms:
Artifact: anything that is built. A JAR would be an exmaple of an artifact
Release build: this is where you build an official release of a jar. This can represent one plugin. This is only one release artifact per version : e.g ... areaProtection-1.0.0.jar
Snapshot build: this is the development version that uses the same version as the intended release build. for example, areaProtection-1.0.0-SNAPSHOT.jar
each snapshot is built, deployed to maven, and available for testing. anyone who wants to examine the jar deployed will always get the latest 1.0.0-SNAPSHOT as snapshots contain many builds, each with an internal timestamp
About snapshots: The thing nice about snapshots is that they are incremental but keep the same version. The API jar that Red51 shared with us is a perfect candidate for maven. It has already been updated a few times but each time it is, we need to download and update our local copy.. If this was built with maven, we would essentially point our Netbeans to the maven repository and request something like:
once inside the each directory, you browse it the way you brows files on any typical webserver. here is an example of a common maven repo:
the namespaces inside can match whatever we want: e.g. for example, we might navigate to the API like this: net/jiwgames/risingworld/api/1.0 or if i wanted to add my own plugin I can use my own domain space and mine would be in us/zork-foxden/myFabulousPlugin/1.0.0-SNAPSHOT
Whenever Red51 updates a pre-release of his API and deploys it as a SNAPSHOT, we all now can pull the latest by referencing 1.0-SNAPSHOT rather than having to manually download and install. Then when us modders distribute our plugins, we deploy them into this maven repo and its available for anyone. Then someone has to write a plugin for RisingWorld (or Red can integrate it into the application) to help us manage versions. So lets say that in the game, we want to try out Zork's myFabulousPlugin-1.0. In RisingWorld, you look at the mods you are using, the system seens that you are on 1.0 but wait, there's a new version in the works... 1.1-SNAPSHOT. Now that means the snapshot 1.1 is still in the works and might be still a bit buggy but yuu can choose to filter out snapshots and just wait for the next release which would make the most recent 1.1-SNAPSHOT become 1.1. Maven allows you to filter releases and snapshots so its quite convenient.
Regarding installations of zips.....
The plugins folder should allow either zip or jar. If a developer wants to not use maven, they can make their own zip and come up with their own versioning scheme, or a make their own jar and provide install instructions to maually download the zip or jar and drop it into the plugins folder.
I've been thinking about this for a while and there should not be any extraction process on the zip or jar. Java always runs a jar without extracting it. The only reason we would need subfolders is if there might be user custom configuration so for example:
Scenario1: For simple plugins that do not have options for users to customize. file is not extracted as the contents will not be modified:
Scenario2: for plugins that might have config files within a folder created contains any generated and modified files (config files, databases, etc):
- libs (any additional libraries downloaded that werent in the jar)
- registeredUsers.db (custom user data that the plugin uses)
- configFile.txt (some config file)
In scenario 2, the directory matches the plugin name and is in the same folder level under plugins. The content in the directory is up to the plugin to establish. Not sure if the API should include something to create userdata folder and limit any file changes to that directory -- to prevent the plugin from accessing the rest of the filesystem). Version is explicitly not included so that if you upgrade your plugin, the config file remains in the same location. Not sure if this standard should be implemented in the game itself or if its up to us to figure this out our own.