[
https://issues.apache.org/jira/browse/MNG-8015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17808936#comment-17808936
]
ASF GitHub Bot commented on MNG-8015:
-------------------------------------
desruisseaux commented on PR #1378:
URL: https://github.com/apache/maven/pull/1378#issuecomment-1902173221
Applied most of above comments (still thinking for a solution about the two
remaining ones). The build continues to fail on Java 11, again because of
Javadoc, but this new error is more annoying. The error message is _"Header
used out of sequence: `<H4>`"_. This error happens when HTML title headers are
used in Javadoc for clear separation of sections. Javadoc verifies that the
numbers are used in sequential order: `<H4>` inside `<H3>`, themselves inside
`<H2>`, _etc_. A difficulty is that Javadoc uses `<H1>`, `<H2>`, _etc._ for its
own purpose, so the first level available in the Javadoc of a method starts at
`<H4>`. Javadoc verifies that we use the proper level, which is good. The
problem is that the expected level changed somewhere between Java 11 and Java
17 (I think it was around Java 13). Java 13 (approximately) and later expects
`<H4>`. Java 11 expected something else. All versions raise an error when the
HTML header level is not what they expected.
So it is impossible (as far as I know) to have a code compilable on both
Java 11 and Java 17 when HTML headers are used in Javadoc and Javadoc checks
are enabled. If compilation or Javadoc generation passes on one, it fails on
the other. Workaround can be one of the following:
* Do not use HTML headers.
* Disable Javadoc checks.
* Requires Java 17 for compilation but target Java 11 or 8 with `--release`
option.
Which approach should we take? The last one would be the one allowing most
gradual transition to newest Java versions (by allowing the use of most recent
conventions right now) while preserving compatibility.
> Control the type of path where each dependency can be placed
> ------------------------------------------------------------
>
> Key: MNG-8015
> URL: https://issues.apache.org/jira/browse/MNG-8015
> Project: Maven
> Issue Type: Improvement
> Components: Core
> Affects Versions: 4.0.0-alpha-12
> Reporter: Martin Desruisseaux
> Priority: Major
>
> Make possible to declare where each dependency can be placed: on the
> module-path, class-path, agent path, doclet path, taglet path, annotation
> processing path, _etc._ The proposed improvement consists in adding a new
> {{PATH_TYPES}} property that can be associated to dependencies. The property
> value is an array of {{PathType}}, a new enumeration-like class with values
> such as {{CLASSES}}, {{MODULES}}, {{DOCLET}}, _etc._ Contrarily to real Java
> enumerations, this enumeration-like class is extensible: plugins can add
> their own enumeration values. This is required at least for the
> {{--patch-module}} option, where a new {{PathType}} enumeration value need to
> be created for each module to patch.
> Users can control indirectly the {{PathType}} of a dependency by specifying
> the dependency type. Note that there is no direct mapping between the
> dependency type and where the dependency will be placed, but only an indirect
> mapping caused by the fact that using a dependency type implies implicit
> values of some properties such as classifier, and (with this proposal) path
> types:
> * {{<type>jar</type>}} implies {{PathType.CLASSES}} and {{PathType.MODULES}}.
> * {{<type>modular-jar</type>}} implies {{PathType.MODULES}} only.
> * {{<type>classpath-jar</type>}} implies {{PathType.CLASSES}} only.
> * _etc._
> When a plugin requests the paths of dependencies, the plugin specifies the
> types of path it is interested in. For example, a Java compiler plugin can
> specify that it is interested in {{PathType.CLASSES}} and
> {{PathType.MODULES}}, but not {{PathType.DOCLET}}. If a dependency declared
> that it can be placed on the class-path or the doclet-path, only the
> class-path is left after intersection with plugin's request. This is
> important for the next step.
> If, after all filtering such as above paragraph are applied, a dependency has
> only one {{PathType}} left, then there is no ambiguity and we are done.
> Combined with above-cited dependency types like {{modular-jar}} or
> {{classpath-jar}}, this rule allows users to control where the dependency
> will be placed. But if there are two or more {{PathType}} left after
> filtering, then a choice needs to be done. For example if there are both
> {{PathType.CLASSES}} and {{PathType.MODULES}} (which may happen when
> {{<type>jar</type>}} is used), then an heuristic rule similar to Maven 3 can
> be applied: check if a {{module-info.class}} file or an {{Automatic-Name}}
> manifest attribute is present, and base the decision on that.
> This proposal aims to fix MNG-7855.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
