Hi Sander, Thank you for your quick reply! Yes, I am asking if it's a best practice. Your answer sounds very reasonable to me.
By the way, I would like to add a paragraph for such practice on the https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html tutorial. I think a piece of brief description for this kind of scenario would be very helpful for Maven newcomers like me. I'll prepare a pull request for it. Best, John Lin Sander Verhagen <san...@sanderverhagen.net> 於 2019年1月10日 週四 下午5:10寫道： > Okay, sorry, it's late over here. You didn't ask for a tool, you asked if > it's a best practice. I think IT IS a best practice to strive for direct > dependencies. I just don't think it's worth being religious about (as > explained in my previous answer). But you make that tradeof, based on the > shape of your project, and the quality of your team, I'd say. > > Sander. > > > > Sander Verhagen > [ san...@sanderverhagen.net<mailto:san...@sanderverhagen.net> ] > > On 10/01/2019 01:07, Sander Verhagen wrote: > > Hi John Lin, > > > The Maven Dependency Plugin offers analyses to detect dependencies that > are used and undeclared; unused and declared. I think that's what you're > asking for. It is one of the tools to really nail down correctness of > dependencies (the Maven Enforcer Plugin also has some relevant rules, such > as dependency convergence). I have used these on larger projects, where > dependency management had inherently gotten quite a bit riskier (risky in > the sense that things tended to break when someone casually changed a > dependency version). These tools were valuable, but they also came with a > price of being forced to chase down dependency issues that the tool > rightfully asserted, that didn't have any practical impact on the > application. In projects with good test coverage (for me those tend to be > smaller projects) I have never used tools like this, because if a high > quality test suite succeeds with an imperfect dependency tree, the team is > still delivering working software. As always, there's tradeofs, and you > make the decision for your project. Good luck. > > Sander. > > https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html > https://maven.apache.org/enforcer/enforcer-rules/index.html > > > > Sander Verhagen > [ san...@sanderverhagen.net<mailto:san...@sanderverhagen.net><mailto: > san...@sanderverhagen.net><mailto:san...@sanderverhagen.net> ] > > On 10/01/2019 00:51, ??? wrote: > > Hi, > > I feel a bit uncomfortable with using the classes in transitive > dependencies. For example, my project A depends on other project B, and > project B depends on project C. When I directly use the classes of projects > C in my project A, I expected that Maven would throw a warning on it, since > project B may someday remove or update the version of the dependency of > project C. However, it complains nothing. It makes me wonder what's Maven's > recommendation for such scenario. After reading the tutorial on > > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > , > I still couldn't find out what Maven suggests. > > When I use a class in my project, is it a better practice to specify the > project containing the class as a direct dependency, or just let the > transitive dependency do its job? What's the catch? Thanks! > > Best, > John Lin > > > > > > >
