You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by "Christian Munier (Jira)" <ji...@apache.org> on 2024/04/24 18:54:00 UTC
[jira] [Created] (DELTASPIKE-1473) Improve dependency consistency in JSF module (dependency-analyze + requireExplicitDependencyScope)
Christian Munier created DELTASPIKE-1473:
--------------------------------------------
Summary: Improve dependency consistency in JSF module (dependency-analyze + requireExplicitDependencyScope)
Key: DELTASPIKE-1473
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1473
Project: DeltaSpike
Issue Type: Improvement
Security Level: public (Regular issues)
Components: JSF-Module
Affects Versions: 2.0.0
Reporter: Christian Munier
As a follow-up to DELTASPIKE-1472 I think it would be helpful to include the {{analyze}} goal of {{maven-dependency-plugin}} so that dependency scopes that are to broad may come to attention while executing the build. In addition I find it helpful to activate the maven-enforcer-plugin with the rule {{requireExplicitDependencyScope}} so that an explicit scope has to be defined for each dependency.
By doing this, I dicovered the following obsolete dependencies in the JSF module:
{noformat}
api -> jakarta.el-api (compile)
impl -> deltaspike-proxy-module-api (compile)
impl -> xml-apis (test)
{noformat}
The following dependencies are used transitively, but are not explicitely defined:
{noformat}
api -> junit-jupiter-api (test)
impl -> arquillian-container-test-api (test)
impl -> arquillian-junit-core (test)
impl -> arquillian-test-api (test)
impl -> shrinkwrap-api (test)
impl -> selenium-api (test)
impl -> selenium-support (test)
{noformat}
The following scopes seem to be too broad:
{noformat}
impl -> jakarta.el-api (compile)
impl -> tomcat-servlet-api (compile)
{noformat}
I think we should always declare Jakarta EE APIs as "provided", because an Application Server already supplies the correct API version fitting its runtime.
I will supply a PR to show my idea.
If you like this idea, we could transfer this configuration to other modules. The configuration for the {{analyze}} goal of the {{maven-dependency-plugin}} could then be moved up to one of its parents or distributed according to modules that inherit dependencies to their children.
Further questions:
* Should dependency {{deltaspike-proxy-module-impl-asm}} be defined as an (optional) dependency of {{jsf-impl}} so that it will likely be automatically be included in the classpath?
* Should dependency {{tomcat-servlet-api}} be changed to Jakarta Servlet API?
* Should {{dependency junit-jupiter-api}} be replaced by JUnit Core (since it seems to have been used accidentally)?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)