Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
0.4-INCUBATING
-
None
Description
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 jcl-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 jcl-over-slf4j) to be included by Maven (with scope runtime).
The fix is to define the jcl-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).