[
https://issues.apache.org/jira/browse/LUCENE-8616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16726194#comment-16726194
]
Steve Rowe edited comment on LUCENE-8616 at 12/20/18 8:20 PM:
--------------------------------------------------------------
Attaching patch that increases minimum supported Maven from 2.2.1 to 3.2.1, and
that switches exclusions to wildcards in the grandparent POM's
{{<dependencyManagement>}} section.
I tested using Maven 3.5.3 on macOS.
Maven compilation works, and all Lucene tests pass. None of the Solr modules
pass all their tests, but that's also true of the unpatched Maven build, for me
anyway.
I had to upgrade the {{maven-remote-resources-plugin}} version, from (default)
1.4 to 1.6.0, because 1.4 apparently ignores wildcard exclusions.
I looked at differences between the generated grandparent POMs, and as
expected, all dependencies' {{<exclusions>}} sections are converted to
wildcards. One other notable difference: in the unpatched Maven build's
grandparent POM, 82/259 dependencies have zero exclusions (and hence no
{{<exclusions>}} section), while with the patch every dependency, including
these 82, includes wildcard exclusions. I looked at a random handful of these,
and they legitimately have no compile-time non-optional dependencies.
Declaring them with an {{exclusions}} section (as in the patched Maven build)
looks better though, since its presence makes explicit the intent to disable
transitive dependency resolution.
I also looked at the difference in output between the patched and the unpatched
Maven build for {{mvn dependency:tree}}, and there was only one difference
(repeated for each module with this dependency) - the *unpatched* Maven build
shows {{jdk.tools:jdk.tools}} as a transitive dependency of
{{hadoop-annotations}}:
{noformat}
[INFO] +- org.apache.hadoop:hadoop-annotations:jar:2.7.4:compile
[INFO] | \- jdk.tools:jdk.tools:jar:1.8:system
{noformat}
^^ looks like a failure of the dependency discovery mechanism used by the
{{mvndeps}} task (via the Ivy API); the patched Maven build does not include
this transitive dependency, so that would be an improvement.
This patch also includes a fix for a WARNING in the unpatched build:
{noformat}
[WARNING] Some problems were encountered while building the effective model for
org.apache.solr:solr-test-framework:jar:8.0.0-SNAPSHOT
[WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must
be unique: org.apache.lucene:lucene-test-framework:jar -> duplicate declaration
of version (?) @ org.apache.solr:solr-test-framework:[unknown-version],
/Users/sarowe/git/lucene-solr-3/maven-build/solr/test-framework/pom.xml, line
131, column 17
{noformat}
^^ This is caused by the {{lucene-test-framework}} dependency being listed
twice in the generated POM for {{solr-test-framework}}, once from the POM
template (to order it at the top of the dependency list, since it must precede
the {{lucene-core}} dependency) and another mention from the dependency
discovery mechanism. The included fix just adjusts the regex for the logic to
exclude some internal dependencies, so that it matches properly in this case
and causes {{lucene-test-framework}} not to be added by the dependency
discovery mechanism.
I won't commit until I get other opinions about the wisdom of doing so, given
the Ant support issues mentioned in my previous comment on this issue.
was (Author: steve_rowe):
Attaching patch that increases minimum supported Maven from 2.2.1 to 3.2.1, and
that switches exclusions to wildcards in the grandparent POM's
{{<dependencyManagement>}} section.
I tested using Maven 3.5.3 on macOS.
Maven compilation works, and all Lucene tests pass. None of the Solr modules
pass all their tests, but that's also true of the unpatched Maven build, for me
anyway.
I had to upgrade the {{maven-remote-resources-plugin}} version, from (default)
1.4 to 1.6.0, because 1.4 apparently ignores wildcard exclusions.
I looked at differences between the generated grandparent POMs, and as
expected, all dependencies' {{<exclusions>}} sections are converted to
wildcards. One other notable difference: in the unpatched Maven build's
grandparent POM, 82/259 dependencies have zero exclusions (and hence no
{{<exclusions>}} section), while with the patch every dependency, including
these 82, includes wildcard exclusions. I looked at a random handful of these,
and they legitimately have no compile-time non-optional dependencies.
Declaring them with an {{exclusions}} section (as in the patched Maven build)
looks better though, since its presence makes explicit the intent to disable
transitive dependency resolution.
I also looked at the difference in output between the patched and the unpatched
Maven build for {{mvn dependency:tree}}, and there was only one difference
(repeated for each module with this dependency) - the *unpatched* Maven build
shows {{jdk.tools:jdk.tools}} as a transitive dependency of
{{hadoop-annotations}}:
{noformat}
[INFO] +- org.apache.hadoop:hadoop-annotations:jar:2.7.4:compile
[INFO] | \- jdk.tools:jdk.tools:jar:1.8:system
{noformat}
^^ looks like a failure of the dependency discovery mechanism used by the
{{mvndeps}} task (via the Ivy API); the patched Maven build does not include
this transitive dependency, so that would be an improvement.
This patch also includes a fix for a WARNING in the unpatched build:
{noformat}
[WARNING] Some problems were encountered while building the effective model for
org.apache.solr:solr-test-framework:jar:8.0.0-SNAPSHOT
[WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must
be unique: org.apache.lucene:lucene-test-framework:jar -> duplicate declaration
of version (?) @ org.apache.solr:solr-test-framework:[unknown-version],
/Users/sarowe/git/lucene-solr-3/maven-build/solr/test-framework/pom.xml, line
131, column 17
{noformat}
^^ This is caused by the {{lucene-test-framework}} dependency being listed
twice in the generated POM for {{solr-test-framework}}, once from the POM
template (to order it at the top of the dependency list, since it must precede
the {{lucene-core}} dependency) and another mention from the dependency
discovery mechanism. The included fix just adjusts the regex for the logic to
exclude some internal dependencies, so that it matches properly in this case
and causes {{lucene-test-framework}} not to be added by the dependency
discovery mechanism.
I won't commit until I get other opinions about the wisdom of doing so, given
the Ant support issues mentioned in my previous commit.
> Maven build: Simplify the way transitive dependency resolution is disabled,
> and increase the minimum supported Maven from 2.2.1 to 3.2.1
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-8616
> URL: https://issues.apache.org/jira/browse/LUCENE-8616
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
> Reporter: Steve Rowe
> Assignee: Steve Rowe
> Priority: Major
> Attachments: LUCENE-8616.patch
>
>
> Right now the Maven build disables transitive dependency resolution for all
> dependencies by listing each dependency's dependencies in a nested
> {{<exclusions>}} section in the grandparent POM's {{<dependencyManagement>}}
> section.
> As of Maven 3.2.1, it's possible to use a wildcard syntax in nested
> {{<exclusions>}} sections to exclude all transitive deps: MNG-2315. This
> would make the grandparent POM much smaller and make the intent much clearer.
> We would have to increase our minimum supported Maven (currently 2.2.1), but
> that seems reasonable, given that Maven 2.x has been EOL'd:
> https://maven.apache.org/maven-2.x-eol.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
