3 ms·

> 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 o

> 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?

JordiGarcL 3y ago
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
Macha 3y ago
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.
- lucumo 3y ago
  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.
corpMaverick 3y ago
Agree. Also, I wish maven allowed dependencies in one line. I am fine with using XML.
vbezhenar 3y ago
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.

JordiGarcL 3y ago

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

Macha 3y ago

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.

lucumo 3y ago
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.

corpMaverick 3y ago

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

vbezhenar 3y ago

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.