3 ms·

Maven isn't Java. I've used java for over 20 years and managed to almost completely avoid it. As with npm - I think automatic dependency management at the lib

Maven isn't Java. I've used java for over 20 years and managed to almost completely avoid it. As with npm - I think automatic dependency management at the library level pulls in far too much of the world - most of which your code doesn't actually depend on because the one function you need in lib A, doesn't actually require lib B, and therefore lib B dependencies C&D etc etc etc. Madness. If you do dependency management at the source level ( using the compiler.... ) then life is generally much simpler ( reflection being the only aspect you need to manage ).

datadeft 4y ago
> Maven isn't Java. The wheels aren't the car. Sure, try to drive around without wheels.
- peterashford 4y ago
  I've used Java since it came out and I have never used Maven
- DrScientist 4y ago
  In my experience using Maven is like driving around with a set of powerful magnets tied to the back with string. You gradually pull in more and more c*p.
za3faran 4y ago
Could you elaborate on what you mean by "dependency management at the source level"? Do you mean manual JAR inclusions into the project?
- DrScientist 4y ago
  The key thing to remember is the transitive nightmare of dependencies that you let Maven manage is largely created by the way Maven works! So if you don't do it that way, just you need to manage the dependencies yourself, but they are much much simplier! In a bit more detail - at the top of your source code is: import someorg.somepackge.class; If you have the source code for someorg.somepackage in your sourcepath/classpath ( and the source of any transitive dependencies ) then the compiler will magically find all the transitive dependencies for class at the class level at compile time. [1] This results in the minimal number of classes you have to ship and as a result the minimal number of transitive dependencies. Now your build tool/script ( whatever tool you use ) will need to bring in those dependencies from a versions repo somewhere - but that can be your own source code repo ( vendoring I think it's called ). Yes - you need need to keep that build config yourself - but frankly that's time well spent as it results in you have proper control over your dependencies, and they don't balloon out of control. Occasions like some random third party has added dependency D to C which is brought in via an A->B->C chain and then you have some library version clash are much much less as a result. That's not to say I don't occasionally use jar files in the classpath - but that's typically only if that library is self contained, single focus and small - and again you can put that in your build script. In my view, Maven magic is part of the problem, not a solution - and to sum up why - it hides the cost of the dependencies - if people had to manually add the chain of true dependencies when they decided to use a apache utility class, they might think twice about whether that chain of dependencies is well designed or not. [1] With the reflection proviso I mentioned above.

datadeft 4y ago

> Maven isn't Java. The wheels aren't the car. Sure, try to drive around without wheels.

peterashford 4y ago
I've used Java since it came out and I have never used Maven
DrScientist 4y ago
In my experience using Maven is like driving around with a set of powerful magnets tied to the back with string. You gradually pull in more and more c*p.

za3faran 4y ago

Could you elaborate on what you mean by "dependency management at the source level"? Do you mean manual JAR inclusions into the project?

DrScientist 4y ago
The key thing to remember is the transitive nightmare of dependencies that you let Maven manage is largely created by the way Maven works! So if you don't do it that way, just you need to manage the dependencies yourself, but they are much much simplier! In a bit more detail - at the top of your source code is: import someorg.somepackge.class; If you have the source code for someorg.somepackage in your sourcepath/classpath ( and the source of any transitive dependencies ) then the compiler will magically find all the transitive dependencies for class at the class level at compile time. [1] This results in the minimal number of classes you have to ship and as a result the minimal number of transitive dependencies. Now your build tool/script ( whatever tool you use ) will need to bring in those dependencies from a versions repo somewhere - but that can be your own source code repo ( vendoring I think it's called ). Yes - you need need to keep that build config yourself - but frankly that's time well spent as it results in you have proper control over your dependencies, and they don't balloon out of control. Occasions like some random third party has added dependency D to C which is brought in via an A->B->C chain and then you have some library version clash are much much less as a result. That's not to say I don't occasionally use jar files in the classpath - but that's typically only if that library is self contained, single focus and small - and again you can put that in your build script. In my view, Maven magic is part of the problem, not a solution - and to sum up why - it hides the cost of the dependencies - if people had to manually add the chain of true dependencies when they decided to use a apache utility class, they might think twice about whether that chain of dependencies is well designed or not. [1] With the reflection proviso I mentioned above.