Java – dependency management and maven

I recently became a big fan of Maven to control the build cycle of my application However, I encountered some rough edges with Maven's dependency management I want to know whether these are the limitations of tools and examples, the necessary evil of relying on management, or whether I use the wrong tools

>The first is the problem of passing dependencies It is understood that if you provide dependencies, Maven will find them in turn It was great, but it didn't work for many of my dependencies For example, include hibernate in my project:

<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-core</artifactId>
    <version>3.3.2.GA</version>
</dependency>

Resulting slf4j in the loss of dependencies I need to add this dependency manually, which I think will be Maven's job So is spring If I add spring MVC as a dependency, shouldn't I add all the basic servlet dependencies (because spring MVC needs them)? I mean servlets, JSPS, JSTL libraries. > Second, warehouse management Maven comes with a default main repository, but I find that in many cases this repository is not up to date For example, if you want spring 3, you must add the springsource repository manually. If you want hibernate 3.5, you must add the JBoss repository When you have to trace the correct repository yourself, it seems to break the point of automatic dependency management The hunt will soon become complicated For example, by adding spring3, you may want to issue repo in spring, foreign exchange repo in spring and milestone repo in spring. > Closely related to number 2 is ensuring that you have the correct version of the artifact I have been burned several times by including the wrong version of the dependent artifact for a given artifact For example, the wrong version of APIs for spring 3 servlet / JSP / JSTL, or the wrong version of Hibernate persistence / annotation APIs These repositories are full of many versions, some of which are confusing names, such as productx-3 GA, productx-3-rc1, productx-3-snapshot, productx-3-cr, product-3-beta, etc Some of them are obvious (RC = release candidate), but trying to determine the order of these versions can be confusing. > Finally, the type of problem depends I may not know much about this, but many repo artifacts are of type "POM" rather than "jar" Several times I have added a dependency jar to my project. I can only find that the repo jar does not actually exist during construction (for example, org. Hibernate EJB3 persistence in JBoss repo)

Through some experiments, I can usually get a construction work, but dependency management is generally complex? I still like this method of manually adding jar files to my project, but I'm interested in learning how to improve my Maven dependency management skills

Solution

Not all parts of the question can be answered, but about some of them:

>Some portable dependency tags are optional, so people who don't need these features won't download them, but those who need them must explicitly set them in their POM. > The Maven central repository contains only versions Therefore, it does not include hibernate 3.5 (it is beta) and it does not include spring 3 until it is released (by the way, you do not need to specify a special spring repository for spring 3 - the release is already in Maven central) > slf4j is a very special dependency, and its runtime behavior depends on the implementation of slf4j you use Therefore, in order to control its behavior, you must explicitly specify slf4j implementation > about management skills: get useful information to maintain your POM XML, you can use MVN dependency: tree (especially - dverbose = true) and MVN dependency: analyze It is also useful to check the dependency POM file for optional dependencies