[
https://issues.apache.org/jira/browse/RAVE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma updated RAVE-313:
---------------------------
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).
was:
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).
> 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 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).
>
--
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
