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.
Bukkit made it really far with community extensibility via non-official APIs. Now they get to help define the official API based on real-word experience about what developers want to do with customizing Minecraft. They also recently announced that they are merging single player and multi-player, creating a single mod-able codebase.
http://www.mojang.com/2012/07/minecraft-1-3-info-snapshot-w2...
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.
Every time I've used it, it downloads hundreds of megabytes of who-knows-what from who-knows-where on the Internet. It's not like apt-get, which uses a central server where there's some level of QA to make sure all the versions of all the pieces work together.
Maven just shoves 100 different components from 100 different servers on your disk. If any one of those servers happens to be down, or moved, or the organization running it dies off, there goes your build.
I'll stick with Ant and manual dependency downloading, thanks. They're a pain in the arse, but at least you can keep the tarballs of the stuff you download around, and can have different library versions for different applications.
Maven looks locally first, then falls back to the internet. You can insert your own package repository in between so you control the point of failure. Configuring Artifactory to work as a transparent proxy to take care of all of this for you is a walk in the park, and is only one of its possible use cases.
Maven lets you keep different library versions around for different applications. This is actually a fundamental thing I've noticed everywhere I've personally seen it used: specify the versions. However you use Maven is evil. Your usage pattern needs to be improved.
If local dependency resolution is your thing you can tell maven to use a local repository. it has the concept of multiple places to look for things, I normally set it to use my local cache first then go out to servers as it needs to.
Its a little bit to wrap your head around to get started with maven. The first time I had to write a pom.xml file I almost burnt down my house. However SBT came along and fixed that problem. The only problem I have with maven now is that there is no way to tell it to make a single binary without a plugin.
The project setup in the repository also has two "superfluous" levels of hierarchy:
|- main
|- java
At this early stage this seems like overengineering, and if at some point the project gets code e.g. javascript, it might be worth it to add ./js-src at the top-level first.
Which has nothing to do with Java. The developer chose that hierarchy.
Correction: As per the message below I guess I should say that it has nothing to do with Java, the ecosystem, framework he is using is forcing him to use that hierarchy.
EDIT: This is meant to be educational, not a rant. I'm hoping people take it that way.
Maven requires a standard directory layout. Maven chose that hierarchy, because:
1) Namespacing. With tens or hundreds of thousands of packages out there, there needs to be an unambiguous way to refer to them separately.
2) Multiple language support. Maven can do Java, Scala, Clojure, Groovy, and so on - in the same project, even. It can even do Javascript, which isn't a JVM language, in certain cases. For the JVM languages, if you want a multi-lamguage project, there has to be an easy way to interoperate (this is enabled by namespacing).
3) Separation of test code and program code. Don't ship tests with your binary package.
4) Separation of code from data.
5) Automation - of packaging, IDE support, etc. This has to do with all of the previous ones. You want to produce a JAR, but don't want to include the default log configuration. So you package the project up. It just happens. You want to edit the code in your IDE. So you add the project. All libraries are downloaded and on your classpath. Add a few lines to your config (as a per-system-user setting or per-project setting, take your pick). Java documentation and source code for those libraries is automatically downloaded. Eclipse hooks it up for you.
Suddenly, this:
src/main/java
src/main/scala
src/main/resources
src/test/java
src/test/scala
src/test/resources
...makes a lot more sense. It's hardly overengineering, but even then, the engineer isn't the one engineering the build system; these are details Maven takes care of.
[Aside: I am appalled and flabbergasted by the ignorance typically leveled at Java by people who don't understand it✝. It has real flaws, don't get me wrong, but making dependency resolution and installation ridiculously straightforward, multi-language builds dead simple, and unit testing a core feature - these are good things.]
Take a look at ant and compare it to maven and you'll see which one makes your life easier✝✝.
✝ I have worn many hats, and have experience with Python, Ruby, PHP, C, Java, and a little bit of Scala in real world contexts, among others. So I'm not a noob who hasn't experienced elegance or conciseness or performance. Java is actually an amazing language that many people don't give it credit for. Though the syntax can be pretty ugly even when the code is conceptually solid.
✝✝ Losing a bit of nuance here - ant gives you configuration. maven gives you convention. Ant is good for very custom; maven is good for straightforward processes.
It is true that more steps have to be done "manually," but the build is 10x more deterministic than Maven. For example, think about this:
With Maven I spend two months developing $APP on my machine. Maven does its magic dependency downloading at time t0. Then someone else starts hacking on $APP at time t1 on their machine, and as the first step, they do the magic dependency downloading and it breaks. Why does it break? Different configuration? Different OS? One of the 100 servers for the app's 100 dependencies broke? An incompatible change introduced in one of the 100 dependencies during an interval of t1-t0 = 2 months? Different version of one of the 100 dependencies?
At least Ant builds are deterministic. Maven builds depend on remote Internet resources remaining the same over time. Spoiler: They don't. Libraries are updated all the time. Often the changes are incompatible (sometimes intentionally, sometimes not). URL's become dead as businesses and organizations change their file structure, change CMS'es, change domain names, merge, go out of business.
With Maven, I'll admit that when things work, they're easier. But when they break, there's so much automagic going on -- including the contents of remote servers you don't control -- that it's tough to know where to begin finding the problem. Whereas with Ant, it's fairly easy to understand exactly what's going on, and you have a good chance of fixing it.
I'm sure most HN readers know exactly how frequently build systems of all stripes break, and how important it is to quickly troubleshoot build issues so you can get back to work that actually creates some sort of value :)
Well, technically, it's good form to run with your own repository. It's not too difficult to, at a user level, specify a caching artifactory instance to hold these.
In practice, as far as I've seen, one should specify the exact versions of the library you're pulling. This is done explicitly in the name of build reproducibility. The "main" repositories should be preferred unless something really custom is needed - in which case, you should be running your own package repository with the libraries you need.
So I guess more tips for maven:
1) Prefer releases over snapshots of libraries whenever possible.
2) Consider running an artifact repository if you're working with a large enough team. It's simple enough that it'd speed you up nicely even if your entire project lives on one laptop, if you're comfortable with a few details of running it. This is strictly optional but will make certain team-based workflows smoother.
3) Always specify versions manually! Don't set it to use the latest automatically. Is this ever a good idea?
4) Try not to include too many third-party repositories if you can.
It's not hard to get Maven dependencies under control. The dependencies are also cached locally, so Maven builds should depend on the internet only the very first time their dependency is included, and thereafter, every time they are updated, only for the package that was updated. Maven is actually -very- good at repeatable builds by default.
I agree with your posts, this one was the best. Maven has caused me more pain the goodness. Ant is dependable and predictable and Eclipse works far better IMO with Ant than when Maven tries to Mavenize a project.
I agree with you, but I think it would be nice if the convention scaled down to something simpler. I don't think that's impossible. (E.g. src/lang_n, src/res, test/lang_n, test/res; or even src-lang_n/, res/, test/lang_n, test/res.)
Technically speaking you can create a new project from scratch without namespaces. This is assuming you are not going to be running in an ecosystem that requires namespaces.
This is a fair point but an API is -always- going to be running in an ecosystem. If it's the Java ecosystem, not using a namespace flies in the face of tens or hundreds of thousands of people's conception of common convention. Which is most definitely not wise, even if src/main/java/reverse/dns/namespace is aesthetically unpleasing to some.
Things like the Play! Framework can get away with it because the framework is basically an exoskeleton around the Java code rather than a traditional container.
Well, obviously, by using them in the language without requiring them on the filesystem? I think you should be able to cat together all the .java files in your project and it should still compile. I guess you could easily do it using a very simple preprocessor.
If you do that you will no longer be able to tell the overall structure of your project at a single glance without using an IDE like Eclipse. Adding and removing packages becomes harder without the IDE. What are the upsides? You've increased the complexity for no good reason.
Easier rapid prototyping and exploratory programming. Edit all the classes of your small/exploratory project in a single file. If the project expands, it should be an automated refactoring to move classes to their own files.
I do this all the time using static inner classes.
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.
I use the command line for everything, including java projects. I usually just create symbolic links: ln -s src/main/java/net/minecraft/workbench/ source
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 completely understand the start fresh mentality. I just know there is a lot of man hours that went into the Bukkit API to get it to the level of features it at now. I would hate to see it take just as long to get the official API up to feature parity.
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."
He was making a joke about misreading 'pom.xml' as 'porn.xml' (all caps: 'POM.XML', 'PORN.XML'). I guess the issue works both ways for those more used to seeing maven projects than pornography!
This is the real reason that Notch is working on 0x10c. He's hoping that along the way, he'll learn enough physics to develop time travel, so he can release code before he even begins development.
I tip my hat to him for his commitment to "release early, release often."
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.
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.