Is specifying direct dependencies a good practice?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Is specifying direct dependencies a good practice?

林自均
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
Reply | Threaded
Open this post in threaded view
|

Re: Is specifying direct dependencies a good practice?

Sander Verhagen
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
[  [hidden email]<mailto:[hidden email]>  ]

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



Reply | Threaded
Open this post in threaded view
|

Re: Is specifying direct dependencies a good practice?

Sander Verhagen
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
[  [hidden email]<mailto:[hidden email]>  ]

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
[  [hidden email]<mailto:[hidden email]><mailto:[hidden email]><mailto:[hidden email]>  ]

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






Reply | Threaded
Open this post in threaded view
|

Re: Is specifying direct dependencies a good practice?

林自均
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 <[hidden email]> 於 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
> [  [hidden email]<mailto:[hidden email]>  ]
>
> 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
> [  [hidden email]<mailto:[hidden email]><mailto:
> [hidden email]><mailto:[hidden email]>  ]
>
> 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
>
>
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Is specifying direct dependencies a good practice?

Mark H. Wood
In reply to this post by 林自均
On Thu, Jan 10, 2019 at 04:51:17PM +0800, 林自均 wrote:

> 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!
I try always to declare all direct dependencies, regardless of whether
they are also transitive dependencies (today).

One reason for this is that it improves the documentation of the
project.  Not only does it provide useful information to reporting
tools driven by Maven, but you can learn useful things about a project
by just reading the POM.

Another reason is that I'm uncomfortable relying on the inclusion of
direct dependencies by happenstance.  An upgraded dependency, which
*was* pulling in another direct dependency but does no more, can break
the build in a way that is quite avoidable.

--
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Is specifying direct dependencies a good practice?

Mark H. Wood
On Thu, Jan 10, 2019 at 09:14:45AM -0500, Mark H. Wood wrote:

> I try always to declare all direct dependencies, regardless of whether
> they are also transitive dependencies (today).
>
> One reason for this is that it improves the documentation of the
> project.  Not only does it provide useful information to reporting
> tools driven by Maven, but you can learn useful things about a project
> by just reading the POM.
>
> Another reason is that I'm uncomfortable relying on the inclusion of
> direct dependencies by happenstance.  An upgraded dependency, which
> *was* pulling in another direct dependency but does no more, can break
> the build in a way that is quite avoidable.
A third reason is that it gives you a chance to specify what versions
of your dependencies are used, instead of letting other dependencies
set (and change!) those versions.  Use with caution:  there may be
strong reasons for those other dependencies to require the versions
that they do.

If you have an assembly composed from multiple complex projects, you
may be able to harmonize versions of shared dependencies instead of
ending up with multiple versions of the same artifact and wondering
which one is used.

--
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Is specifying direct dependencies a good practice?

林自均
Hi Mark,

Thank you for your feedback. I will try to include your 3 reasons in my
pull request. They are very clear and useful to me.

Best,
John Lin

Mark H. Wood <[hidden email]> 於 2019年1月10日 週四 下午10:26寫道:

> On Thu, Jan 10, 2019 at 09:14:45AM -0500, Mark H. Wood wrote:
> > I try always to declare all direct dependencies, regardless of whether
> > they are also transitive dependencies (today).
> >
> > One reason for this is that it improves the documentation of the
> > project.  Not only does it provide useful information to reporting
> > tools driven by Maven, but you can learn useful things about a project
> > by just reading the POM.
> >
> > Another reason is that I'm uncomfortable relying on the inclusion of
> > direct dependencies by happenstance.  An upgraded dependency, which
> > *was* pulling in another direct dependency but does no more, can break
> > the build in a way that is quite avoidable.
>
> A third reason is that it gives you a chance to specify what versions
> of your dependencies are used, instead of letting other dependencies
> set (and change!) those versions.  Use with caution:  there may be
> strong reasons for those other dependencies to require the versions
> that they do.
>
> If you have an assembly composed from multiple complex projects, you
> may be able to harmonize versions of shared dependencies instead of
> ending up with multiple versions of the same artifact and wondering
> which one is used.
>
> --
> Mark H. Wood
> Lead Technology Analyst
>
> University Library
> Indiana University - Purdue University Indianapolis
> 755 W. Michigan Street
> Indianapolis, IN 46202
> 317-274-0749
> www.ulib.iupui.edu
>
Reply | Threaded
Open this post in threaded view
|

Re: Is specifying direct dependencies a good practice?

林自均
Hi Sander & Mark,

I've submitted a pull request: https://github.com/apache/maven-site/pull/61.
Any feedback is welcome. Thank you.

Best,
John Lin

林自均 <[hidden email]> 於 2019年1月10日 週四 下午11:08寫道:

> Hi Mark,
>
> Thank you for your feedback. I will try to include your 3 reasons in my
> pull request. They are very clear and useful to me.
>
> Best,
> John Lin
>
> Mark H. Wood <[hidden email]> 於 2019年1月10日 週四 下午10:26寫道:
>
>> On Thu, Jan 10, 2019 at 09:14:45AM -0500, Mark H. Wood wrote:
>> > I try always to declare all direct dependencies, regardless of whether
>> > they are also transitive dependencies (today).
>> >
>> > One reason for this is that it improves the documentation of the
>> > project.  Not only does it provide useful information to reporting
>> > tools driven by Maven, but you can learn useful things about a project
>> > by just reading the POM.
>> >
>> > Another reason is that I'm uncomfortable relying on the inclusion of
>> > direct dependencies by happenstance.  An upgraded dependency, which
>> > *was* pulling in another direct dependency but does no more, can break
>> > the build in a way that is quite avoidable.
>>
>> A third reason is that it gives you a chance to specify what versions
>> of your dependencies are used, instead of letting other dependencies
>> set (and change!) those versions.  Use with caution:  there may be
>> strong reasons for those other dependencies to require the versions
>> that they do.
>>
>> If you have an assembly composed from multiple complex projects, you
>> may be able to harmonize versions of shared dependencies instead of
>> ending up with multiple versions of the same artifact and wondering
>> which one is used.
>>
>> --
>> Mark H. Wood
>> Lead Technology Analyst
>>
>> University Library
>> Indiana University - Purdue University Indianapolis
>> 755 W. Michigan Street
>> Indianapolis, IN 46202
>> 317-274-0749
>> www.ulib.iupui.edu
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Is specifying direct dependencies a good practice?

Hervé BOUTEMY
Thank you for transforming a learning done on the mailing list into a PR

We already have some feedback on the PR from Maven developers, but feedback
from users would be awesome also, since it's about making sure the
explanations are easy to understand, then the more eyes, the better

Regards,

Hervé

Le samedi 12 janvier 2019, 03:30:55 CET 林自均 a écrit :

> Hi Sander & Mark,
>
> I've submitted a pull request: https://github.com/apache/maven-site/pull/61.
> Any feedback is welcome. Thank you.
>
> Best,
> John Lin
>
> 林自均 <[hidden email]> 於 2019年1月10日 週四 下午11:08寫道:
>
> > Hi Mark,
> >
> > Thank you for your feedback. I will try to include your 3 reasons in my
> > pull request. They are very clear and useful to me.
> >
> > Best,
> > John Lin
> >
> > Mark H. Wood <[hidden email]> 於 2019年1月10日 週四 下午10:26寫道:
> >
> >> On Thu, Jan 10, 2019 at 09:14:45AM -0500, Mark H. Wood wrote:
> >> > I try always to declare all direct dependencies, regardless of whether
> >> > they are also transitive dependencies (today).
> >> >
> >> > One reason for this is that it improves the documentation of the
> >> > project.  Not only does it provide useful information to reporting
> >> > tools driven by Maven, but you can learn useful things about a project
> >> > by just reading the POM.
> >> >
> >> > Another reason is that I'm uncomfortable relying on the inclusion of
> >> > direct dependencies by happenstance.  An upgraded dependency, which
> >> > *was* pulling in another direct dependency but does no more, can break
> >> > the build in a way that is quite avoidable.
> >>
> >> A third reason is that it gives you a chance to specify what versions
> >> of your dependencies are used, instead of letting other dependencies
> >> set (and change!) those versions.  Use with caution:  there may be
> >> strong reasons for those other dependencies to require the versions
> >> that they do.
> >>
> >> If you have an assembly composed from multiple complex projects, you
> >> may be able to harmonize versions of shared dependencies instead of
> >> ending up with multiple versions of the same artifact and wondering
> >> which one is used.
> >>
> >> --
> >> Mark H. Wood
> >> Lead Technology Analyst
> >>
> >> University Library
> >> Indiana University - Purdue University Indianapolis
> >> 755 W. Michigan Street
> >> Indianapolis, IN 46202
> >> 317-274-0749
> >> www.ulib.iupui.edu





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Is specifying direct dependencies a good practice?

林自均
Hi Hervé,

Thank you for the review on my PR. I've updated the PR. Please let me know
if you have further feedback.

Best,
John Lin

Hervé BOUTEMY <[hidden email]> 於 2019年1月13日 週日 下午5:23寫道:

> Thank you for transforming a learning done on the mailing list into a PR
>
> We already have some feedback on the PR from Maven developers, but
> feedback
> from users would be awesome also, since it's about making sure the
> explanations are easy to understand, then the more eyes, the better
>
> Regards,
>
> Hervé
>
> Le samedi 12 janvier 2019, 03:30:55 CET 林自均 a écrit :
> > Hi Sander & Mark,
> >
> > I've submitted a pull request:
> https://github.com/apache/maven-site/pull/61.
> > Any feedback is welcome. Thank you.
> >
> > Best,
> > John Lin
> >
> > 林自均 <[hidden email]> 於 2019年1月10日 週四 下午11:08寫道:
> >
> > > Hi Mark,
> > >
> > > Thank you for your feedback. I will try to include your 3 reasons in my
> > > pull request. They are very clear and useful to me.
> > >
> > > Best,
> > > John Lin
> > >
> > > Mark H. Wood <[hidden email]> 於 2019年1月10日 週四 下午10:26寫道:
> > >
> > >> On Thu, Jan 10, 2019 at 09:14:45AM -0500, Mark H. Wood wrote:
> > >> > I try always to declare all direct dependencies, regardless of
> whether
> > >> > they are also transitive dependencies (today).
> > >> >
> > >> > One reason for this is that it improves the documentation of the
> > >> > project.  Not only does it provide useful information to reporting
> > >> > tools driven by Maven, but you can learn useful things about a
> project
> > >> > by just reading the POM.
> > >> >
> > >> > Another reason is that I'm uncomfortable relying on the inclusion of
> > >> > direct dependencies by happenstance.  An upgraded dependency, which
> > >> > *was* pulling in another direct dependency but does no more, can
> break
> > >> > the build in a way that is quite avoidable.
> > >>
> > >> A third reason is that it gives you a chance to specify what versions
> > >> of your dependencies are used, instead of letting other dependencies
> > >> set (and change!) those versions.  Use with caution:  there may be
> > >> strong reasons for those other dependencies to require the versions
> > >> that they do.
> > >>
> > >> If you have an assembly composed from multiple complex projects, you
> > >> may be able to harmonize versions of shared dependencies instead of
> > >> ending up with multiple versions of the same artifact and wondering
> > >> which one is used.
> > >>
> > >> --
> > >> Mark H. Wood
> > >> Lead Technology Analyst
> > >>
> > >> University Library
> > >> Indiana University - Purdue University Indianapolis
> > >> 755 W. Michigan Street
> > >> Indianapolis, IN 46202
> > >> 317-274-0749
> > >> www.ulib.iupui.edu
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>