Live data from Hacker News

The Minecraft API Is Now On Github

github.com

31–40 of 53 posts

Re: The Minecraft API Is Now On Github

#31
post #22

Earlier quoted context omitted.

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.…

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.

Re: The Minecraft API Is Now On Github

#32
post #4

Earlier quoted context omitted.

He started working on it 3 hours ago

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."

Notch isn't the one working on this code, and it's not released, just open.

Re: The Minecraft API Is Now On Github

#33

Directory structure: Minecraft-API |- src |- main |- java |- net |- minecraft |- workbench Good old Java. 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?

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.

Re: The Minecraft API Is Now On Github

#34

Directory structure: Minecraft-API |- src |- main |- java |- net |- minecraft |- workbench Good old Java. 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?

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 i…

I routinely navigate by command line.

But yes, Java's packaging is mostly a good thing.

Re: The Minecraft API Is Now On Github

#35
post #32

Earlier quoted context omitted.

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."

Notch isn't the one working on this code, and it's not released, just open.

He probably established the "Early/often"policy for Mojang though.

Re: The Minecraft API Is Now On Github

#36

Directory structure: Minecraft-API |- src |- main |- java |- net |- minecraft |- workbench Good old Java. 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?

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.

When I found this out, it changed my life.

Re: The Minecraft API Is Now On Github

#37

Directory structure: Minecraft-API |- src |- main |- java |- net |- minecraft |- workbench Good old Java. 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?

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 i…

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

Re: The Minecraft API Is Now On Github

#38
post #32

Earlier quoted context omitted.

Notch isn't the one working on this code, and it's not released, just open.

He probably established the "Early/often"policy for Mojang though.

Sure, but is this project on github because of that policy? I doubt it.

Re: The Minecraft API Is Now On Github

#39
post #23

Directory structure: Minecraft-API |- src |- main |- java |- net |- minecraft |- workbench Good old Java. 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?

This is partially due to Maven as well. Its a pretty standard convention that most IDE's can abstract around.

Maven is evil. It needs to die.

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.

Re: The Minecraft API Is Now On Github

#40
post #22

Earlier quoted context omitted.

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.…

Ant makes my life easier.

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 :)

Post reply on HN