Hacker News Reader

Comment by vbezhenar | Hacker News Reader

My suggestion is:

1. Use maven.

2. If you use spring, use spring boot parent, you don't really need to read the rest.

3. By default maven uses ancient plugin versions (for reasons I don't understand). So you have to define every single plugin you're using with latest version, including standard ones like maven-compiler-plugin.

4. Do not specify versions in <version> tag. Use properties for every single dependency and plugin.

5. Use "versions" maven plugin, it supports properties.

6. Learn maven, it's tiny. Learn about <dependencyManagement>, <pluginManagement> tags.

7. Do not use multi-project mono-repo setups.

8. If you really want to use multi-project setup, use Gradle. It sucks, but maven multi project configuration is hardly usable.

View on HN

> Use properties for every single dependency and plugin.

I see this a lot, but... why? Feels like putting far apart information that should be together (name of a dependency and its version).

It makes sense I guess when multiple artifacts have the same version, like a number of spring deps will all have the same verson, and then you only need to change it in one place, and you are certain they are synchronized. But when there is only one thing with its own version number, why define a property and put its value in a different place in the file?

Never understood this either, it increases complexity at a seemingly little to no benefit.

Many collection of artifacts that need to have the same version provide a BOM to define the version in a single place. And you can always use local variables anyway

The reason is that a sane format for dependencies (i.e. not XML) would be something like:

    "dependency-x": "1.0"
    "dependency-y": "3.2.1"

This is basically what Cargo.toml, package.json, even requirements.txt give you.

Compare that to the 6 lines minimum that each maven dependency is, plus the fact that you sometimes need to specify the same dependency again in the <dependencyManagement> section for what other languages's tools do with lockfiles, which could be several pages away because of the aforementioned bloat. So it ends up being a pain to find the version information, and to update it.

Then you add in the multi-module dependencies, where you're supposed to keep the versions in sync. Sure, there's parent POMs to help with this, but you can only use one at a time, and ultimately someone still needs to maintain the parent POM.

So then rather than specify the same version number 8 or so times in very distant locations, people put a bunch of properties with version numbers to simulate a less clunky dependency specification format.

You don't have to define the version multiple times. If you've specified it in dependencyManagement, you don't have to add a <version> under <dependencies>. If you do it in the parent POM, you won't have to specify versions in the child POMs either.

The only time you have to repeat the versions of dependencies is when there are related dependencies that should be the same version. E.g. dependencies with separate packages for modules, like Jackson or Spring. And if the dependency has a BOM pom, that's not needed either.

Agree. Also, I wish maven allowed dependencies in one line. I am fine with using XML.

Because versions plugin works with this format perfectly. You just type something like `mvn versions:display-property-updates` and get the full list of all updated dependencies and plugins. I can't remember why exactly it doesn't work this way with inline version strings, but I remember that there was a reason I started to use this approach (and I generally prefer not to introduce unnecessary complexity).

Another reason is uniformity. You'll inevitably have some group of dependencies with identical version, so it certainly makes sense to move that info to the property. And then you'll have your versions information spread around. Not very nice.

Reply on news.ycombinator.com