[
https://issues.apache.org/jira/browse/DELTASPIKE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Munier updated DELTASPIKE-1473:
-----------------------------------------
Description:
As a follow-up to DELTASPIKE-1472 I think it would be helpful to include the
{{analyze-only}} 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? Or should it rather not be included by default,
leaving it up to the consumer?
* Should compile/provided 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 and only within this single project)?
was:
As a follow-up to DELTASPIKE-1472 I think it would be helpful to include the
{{analyze-only}} 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? Or should it rather not be included by default,
leaving it up to the consumer?
* Should compile/provided 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)?
> 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
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As a follow-up to DELTASPIKE-1472 I think it would be helpful to include the
> {{analyze-only}} 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? Or should it rather not be included by default,
> leaving it up to the consumer?
> * Should compile/provided 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 and only within this single project)?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
