You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by "Ate Douma (Resolved) (JIRA)" <ji...@apache.org> on 2011/10/20 02:01:11 UTC
[jira] [Resolved] (RAVE-313) Incorrect dependency scopes for slf4j
and log4j jars
[ 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