[morsch]

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.

[felipemnoa]

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.

[koko775]

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.

[csense]

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

[koko775]

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.

[jebblue]

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.

[morsch]

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

[felipemnoa]

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.

[koko775]

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.