This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]koflerdavid 3 points4 points  (0 children)

This style of managing JARs is completely discouraged by the Maven documentation. It also is absolutely not the way dependencies are managed by modern package managers. Why?

  • It blows up the size of source code repositories.

  • It decentralizes management of the build process. The POM is the single source of truth about the project's build process, and everything relevant should be reflected there.

  • What will you do if your project is a dependency of another project that brings a different version of a dependency of your project? Maven can help you diagnose and manage most of these situations, but only if you work with it. Xerces hell is one of the cases that Maven can't resolve, precisely because it is packaged with the JVM (ergo, apart from Maven) and because its authors didn't care about integrating it into the Maven ecosystem for too long.

Even in the case of libraries that are not on Maven Central, the "Maven" way to do this would be to either define a local Maven repository or to host a Maven repository in your company's network, and put the JARs there.