The Minecraft API is going to make mod development SO much easier. No more decompiling and patching hacks. I've been waiting for this since Mojang snagged the Bukkit team. I look forward to the first client/server builds that support it.
Leaving aside Java's packaging structure, if you're on Github, just use "t" and search for the filename you're looking for instead of clicking up and down the directory. hierarchy.
Who on earth thought deeply nested directories for packages was a good idea?
FWIW, if I were listing "things to criticize Java for", I can't imagine that the package mechanism would be anywhere near the top 25, top 50, or even top 100. Unless you're routinely navigating around that structure using command line tools (which I suppose some Java developers do), I don't see the problem. Pretty much any modern IDE makes it nearly painless to navigate around the source code.
Not much in here as of right now , so if you looking as to what can be done immediately there isn't much of anything. It is cool that this is being worked on in public. Honestly I don't know why this is a fresh project instead of just an official fork of Bukkit.
Besides the mentioned licensing-issues, Dinnerbone (the guy hired by Mojang, who used to work on Bukkit) – as well as others involved – has said that they like the opportunity to start fresh.
Things, which was done one way in Bukkit, isn't necessary the best way and given the opportunity to do it better, it's not a hard choice.
I think legal problems … I guess. Not sure. But it also seems like they want to do quite a few things differently, though I'm not sure whether that's good idea.
"A Project Object Model or POM is the fundamental unit of work in Maven. It is an XML file that contains information about the project and configuration details used by Maven to build the project."
Bit of history for those who might not know the back story.
Mods for Minecraft have been around almost as long as Minecraft has been. These mods took the form of patches to the decompiled .jar archives that the client and server code was distributed as.
It quickly became clear that different mods would often patch the same files, usually in contradictory ways, so applying different mods at the same time was near impossible.
Two projects sprang up to make the modder's life easier: hMod by hey0 [1] and the Minecraft Coders Pack (MCP) [2].
MCP was an attempt to translate decompiled obfuscated java code into something 'meaningful' that could be used to more easily write mods. Some of the people who would later go on to work on Bukkit were involved in this project. MCP also played a large role in keeping mods up to date as new versions were released.
Hey0's mod 'hmod' was the first successful server mod that provided an abstracted 'API' for developing plugins against. The community loved this idea, and an ecosystem of plugins sprung up extremely quickly around it. Server administrators were now able to install many different plugins, each of which would (almost certainly) work with each other at the same time.
Unfortunately, hey0 lost interest in the project, and the group that had started to maintain it felt they were often working against the code base, rather than with it. Hey0 was a relatively new programmer when he started the project (I think he was 14?) and while a lot was achieved there were a few architectural aspects that were extremely hard to change.
For better or worse (probably better in retrospect) the team that had started to maintain hmod broke off to a new project called Bukkit [3]. The four main team members at that point were EvilSeph, Dinnerbone, Grum and Tahg. This is the 'core' Bukkit team that was hired by Mojang a little while ago to work on Minecraft (and probably other things) full time.
I had started developing on hmod a few months before Bukkit started, and switched to it soon after. I eventually became one of the main contributors to that project, and still get involved from time to time.
Bukkit as a project aimed to learn from hmod, incorporating much of what was learnt from the mistakes in the original design. The project was still very young, and there was a lot of pressure on the project from the community. The pressure was primarily a result of hmod dying once the team that was supporting it moved on.
Every time a new Minecraft version was released, the server mods had to be updated. The new clients wouldn't work with an old server version, and there was no easy way to downgrade a client, so server administrators would have many angry users who could not connect to their modded server. The upgrade process was by far the most troublesome for a modding project, and was what the MCP project was most helpful in assisting with.
The source code would need to be decompiled, and then deobfuscated. Any changes by the mod would then need to be re-applied to the newly deobfuscated source, before repackaging everything for the server admins to install. One of the biggest problems with hmod was how incredibly hard and slow this process was. It would often take days if not weeks for this upgrade process to complete. When the team left hmod no one was left to rebuild it every time there was a new release, and so hmod died. It took a long time before anyone was able to revive that project [4]. Bukkit was designed first around making this process as easy as possible, and the results showed. A number of updates took less than a few hours from the time a new version was released by Mojang.
That being said, Bukkit had many issues. One that I was constantly working with was the number of classes implemented in the 'API' section of the code. We used two projects, Bukkit and CraftBukkit, to separate the plugins from the source code. Bukkit was what plugins linked against, and provided a stableish API that wouldn't break (too often). CraftBukkit implemented all the necessary hooks and behaviours in the server itself. Unfortunately, some classes were built into the API that made things quite difficult. We were locked into certain material behaviours, for example, because of the way they were implemented. Interestingly, one of the 'Coding standards' for the new API addresses this directly
Absolutely no already-implemented classes. Use interfaces, and have util classes created by a implementation-controlled Factory.
So I see it this way:
Bukkit was created 'from fresh' to address some extremely difficult problems that made maintaining the existing solution (hmod) extremely time consuming and troublesome. As Bukkit matured it was able to deal with lots of issues, but some kept re-occurring. Integrating with client-side mods was a common problem that had no easy solution in the way Bukkit worked, for example. When the opportunity to create a supported, integrated plugin system presented itself, experience said that starting fresh was going to be the easiest way.
Something that might not be clear is that the actual Minecraft source code is (apparently - I have never seen it myself) very different to the decompiled and de-obfuscated version that CraftBukkit built on. To take advantage of being able to change the original source code much of what CraftBukkit does would need to be rewritten. Changing the API side of things (Bukkit) at the same time frees them to make better choices and learn from mistakes.
We will surely find out if that turns out to be the case, but for now I am quite excited to see what happens.
[+] [-] swashbuck1r|13 years ago|reply
I added a Jenkins build job for it on BuildHive so anyone can download the bits if you want to play with the very limited banning API that they apparently have so far :) https://buildhive.cloudbees.com/job/swashbuck1r/job/Minecraf...
I hope they'll consider adding a build job for the official project.
[+] [-] DanielRibeiro|13 years ago|reply
Nonetheless the API is good news.
[+] [-] kreeger|13 years ago|reply
[+] [-] TazeTSchnitzel|13 years ago|reply
On my machine that means it would end up being: /home/ajf/Projects/2012/Minecraft/Minecraft-API/src/main/java/net/minecraft/workbench/
Who on earth thought deeply nested directories for packages was a good idea?
[+] [-] spacemanaki|13 years ago|reply
When I found this out, it changed my life.
[+] [-] dkhenry|13 years ago|reply
[+] [-] felipemnoa|13 years ago|reply
Java does not stop you from doing this:
Minecraft-API
[+] [-] mindcrime|13 years ago|reply
FWIW, if I were listing "things to criticize Java for", I can't imagine that the package mechanism would be anywhere near the top 25, top 50, or even top 100. Unless you're routinely navigating around that structure using command line tools (which I suppose some Java developers do), I don't see the problem. Pretty much any modern IDE makes it nearly painless to navigate around the source code.
[+] [-] angrycoder|13 years ago|reply
[+] [-] dkhenry|13 years ago|reply
[+] [-] josso|13 years ago|reply
[+] [-] aprendo|13 years ago|reply
[+] [-] prezjordan|13 years ago|reply
[+] [-] dpritchett|13 years ago|reply
You'll see this on lots of JVM-based projects.
[+] [-] iand675|13 years ago|reply
[+] [-] bvdbijl|13 years ago|reply
[+] [-] Cogito|13 years ago|reply
Mods for Minecraft have been around almost as long as Minecraft has been. These mods took the form of patches to the decompiled .jar archives that the client and server code was distributed as.
It quickly became clear that different mods would often patch the same files, usually in contradictory ways, so applying different mods at the same time was near impossible.
Two projects sprang up to make the modder's life easier: hMod by hey0 [1] and the Minecraft Coders Pack (MCP) [2].
MCP was an attempt to translate decompiled obfuscated java code into something 'meaningful' that could be used to more easily write mods. Some of the people who would later go on to work on Bukkit were involved in this project. MCP also played a large role in keeping mods up to date as new versions were released.
Hey0's mod 'hmod' was the first successful server mod that provided an abstracted 'API' for developing plugins against. The community loved this idea, and an ecosystem of plugins sprung up extremely quickly around it. Server administrators were now able to install many different plugins, each of which would (almost certainly) work with each other at the same time.
Unfortunately, hey0 lost interest in the project, and the group that had started to maintain it felt they were often working against the code base, rather than with it. Hey0 was a relatively new programmer when he started the project (I think he was 14?) and while a lot was achieved there were a few architectural aspects that were extremely hard to change.
For better or worse (probably better in retrospect) the team that had started to maintain hmod broke off to a new project called Bukkit [3]. The four main team members at that point were EvilSeph, Dinnerbone, Grum and Tahg. This is the 'core' Bukkit team that was hired by Mojang a little while ago to work on Minecraft (and probably other things) full time.
I had started developing on hmod a few months before Bukkit started, and switched to it soon after. I eventually became one of the main contributors to that project, and still get involved from time to time.
Bukkit as a project aimed to learn from hmod, incorporating much of what was learnt from the mistakes in the original design. The project was still very young, and there was a lot of pressure on the project from the community. The pressure was primarily a result of hmod dying once the team that was supporting it moved on.
Every time a new Minecraft version was released, the server mods had to be updated. The new clients wouldn't work with an old server version, and there was no easy way to downgrade a client, so server administrators would have many angry users who could not connect to their modded server. The upgrade process was by far the most troublesome for a modding project, and was what the MCP project was most helpful in assisting with.
The source code would need to be decompiled, and then deobfuscated. Any changes by the mod would then need to be re-applied to the newly deobfuscated source, before repackaging everything for the server admins to install. One of the biggest problems with hmod was how incredibly hard and slow this process was. It would often take days if not weeks for this upgrade process to complete. When the team left hmod no one was left to rebuild it every time there was a new release, and so hmod died. It took a long time before anyone was able to revive that project [4]. Bukkit was designed first around making this process as easy as possible, and the results showed. A number of updates took less than a few hours from the time a new version was released by Mojang.
That being said, Bukkit had many issues. One that I was constantly working with was the number of classes implemented in the 'API' section of the code. We used two projects, Bukkit and CraftBukkit, to separate the plugins from the source code. Bukkit was what plugins linked against, and provided a stableish API that wouldn't break (too often). CraftBukkit implemented all the necessary hooks and behaviours in the server itself. Unfortunately, some classes were built into the API that made things quite difficult. We were locked into certain material behaviours, for example, because of the way they were implemented. Interestingly, one of the 'Coding standards' for the new API addresses this directly
Absolutely no already-implemented classes. Use interfaces, and have util classes created by a implementation-controlled Factory.
So I see it this way: Bukkit was created 'from fresh' to address some extremely difficult problems that made maintaining the existing solution (hmod) extremely time consuming and troublesome. As Bukkit matured it was able to deal with lots of issues, but some kept re-occurring. Integrating with client-side mods was a common problem that had no easy solution in the way Bukkit worked, for example. When the opportunity to create a supported, integrated plugin system presented itself, experience said that starting fresh was going to be the easiest way.
Something that might not be clear is that the actual Minecraft source code is (apparently - I have never seen it myself) very different to the decompiled and de-obfuscated version that CraftBukkit built on. To take advantage of being able to change the original source code much of what CraftBukkit does would need to be rewritten. Changing the API side of things (Bukkit) at the same time frees them to make better choices and learn from mistakes.
We will surely find out if that turns out to be the case, but for now I am quite excited to see what happens.
[1] http://www.ohloh.net/p/hmod - there is probably a better resource, but I can't find it
[2] http://mcp.ocean-labs.de/index.php/Main_Page
[3] http://bukkit.org/
[4] http://www.canarymod.net/
EDIT: grammar and such
[+] [-] visian|13 years ago|reply
[+] [-] vineet|13 years ago|reply
[+] [-] cjdentra|13 years ago|reply