[
https://issues.apache.org/jira/browse/ONAMI-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13591837#comment-13591837
]
Simone Tripodi commented on ONAMI-98:
-------------------------------------
> -1 on provided for Guice. An important reason for having an explicit
> dependency on Guice (i.e. <scope>compile</scope>) is to make sure that the
> _correct_ version of Guice is used. You don't want Onami to work well one day
> and then when a new version of Guice is released it no longer works.
>
how would you handle the situation where different versions of Guice would be
included in the classpath, bue to Onami explicit transitive dependency?
> The main reason for scope: provided is for deps that will be included
> automatically in containers such as Tomcat. End users have no way of
> preventing the inclusion of provided deps.
again, this is false. In my team at Adobe we develop targeting OSGi platform
and we use `provided` scope only, because dependencies are expected to be
provided by the runtime environment.
> Improve dependency management
> -----------------------------
>
> Key: ONAMI-98
> URL: https://issues.apache.org/jira/browse/ONAMI-98
> Project: Apache Onami
> Issue Type: Improvement
> Components: parent
> Affects Versions: parent-3
> Reporter: Mikhail Mazursky
> Priority: Minor
>
> - Why Guice have "provided" scope in dep. management? I think it should be
> "compile".
> - We can set scope for JUnit, TestNg dependencies to be "test" to avoid
> setting it in each module.
> - We may want to remove explicit "compile" scope and "jar" type from all
> dependencies from all modules because they are defaults. Less noise in poms.
> - Manage all dependencies' versions from parent dependency management to
> ensure consistent versions and easy maintenance.
> WDYT?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
