[
https://issues.apache.org/jira/browse/RAVE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma resolved RAVE-313.
----------------------------
Resolution: Fixed
> Incorrect dependency scopes for slf4j and log4j jars
> ----------------------------------------------------
>
> Key: RAVE-313
> URL: https://issues.apache.org/jira/browse/RAVE-313
> Project: Rave
> Issue Type: Bug
> Components: build & development
> Affects Versions: 0.4-INCUBATING
> Reporter: Ate Douma
> Assignee: Ate Douma
> Priority: Minor
> Fix For: 0.5-INCUBATING
>
>
> I accidentally discovered the problem when I noticed that the
> rave-portal-resources war, which is intentionally a shallow war (so: without
> any bundled dependencies/jars) currently has the slf4j-api and jcl-over-slf4j
> jars embedded: wrong!
> These dependencies are pulled in through the rave-portal-web dependency, even
> while that dependency is included *only* as provided (to support IDE tag lib
> lookup).
> The real problem however is that jcr-over-slf4j is defined in rave-project in
> the dependency management section with scope runtime.
> That is on a 'nearer' (and stronger: runtime) dependency resolution path than
> the transitive dependencies from rave-portal-web, thus resulting these jars
> (slf4j-api through jcr-over-slf4j) to be included by Maven (with scope
> runtime).
> The fix is to define the jcr-over-slf4j in the rave-project
> dependency-management section with default scope (compile).
> That way, the provided scope of rave-portal-web on rave-portal-resources is
> 'stronger' and these jars no longer will be bundled with that (intentionally)
> shallow war.
> And, then I noticed the scopes for log4j and slf4j-log4j12 also were
> incorrectly using scope runtime.
> AFAIK, all this is my own doing, so mea culpa.
> However, for the log4j and slf4j-log4j12 dependencies the configuration is
> wrong for a slightly different reason.
> These logging *implementation* jars should not be 'enforced' automatically:
> the whole point of using slf4j is that it allows you to choose which logging
> implementation to use.
> So, bundling these implementation jars should *only* be made for the final
> packaging, e.g. (in our case) the rave-portal war.
> Both scope compile and runtime would 'enforce' bundling these jars too early,
> and while scope provided would not do this, it does however 'expose' these
> jars API at compile time which also is undesirable.
> The (only) proper solution therefore is configuring these implementation jars
> in the dependency management with scope test.
> This ensures that only test classes will be 'exposed' to these implementation
> APIs (acceptable).
> But it also means that they then require to be *explicitly* defined as
> dependencies for the final packaging on rave-portal, preferably with scope
> runtime (instead of compile).
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
