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
