uschindler commented on a change in pull request #571:
URL: https://github.com/apache/lucene/pull/571#discussion_r778683708
##########
File path: gradle/validation/validate-source-patterns.gradle
##########
@@ -154,12 +154,11 @@ class ValidateSourcePatternsTask extends DefaultTask {
(~$/\n\s*var\s+.*=.*<>.*/$) : 'Diamond operators should not be used with
var'
]
- def found = 0;
def violations = new TreeSet();
def reportViolation = { f, name ->
- logger.error('{}: {}', name, f);
- violations.add(name);
- found++;
+ String msg = String.format(Locale.ROOT, "%s: %s", f, name)
Review comment:
Those changes here are not related, you just changed the task to get
better output?
##########
File path: gradle/java/modules.gradle
##########
@@ -27,194 +29,167 @@ allprojects {
modularity.inferModulePath.set(false)
}
- // Map convention configuration names to "modular" corresponding
configurations.
- Closure<String> moduleConfigurationNameFor = { String configurationName ->
- return "module" + configurationName.capitalize().replace("Classpath",
"Path")
- }
-
- //
- // For each source set, create explicit configurations for declaring
modular dependencies.
- // These "modular" configurations correspond 1:1 to Gradle's conventions
but have a 'module' prefix
- // and a capitalized remaining part of the conventional name. For example,
an 'api' configuration in
- // the main source set would have a corresponding 'moduleApi'
configuration for declaring modular
- // dependencies.
- //
- // Gradle's java plugin "convention" configurations extend from their
modular counterparts
- // so all dependencies end up on classpath by default for backward
compatibility with other
- // tasks and gradle infrastructure.
//
- // At the same time, we also know which dependencies (and their transitive
graph of dependencies!)
- // should be placed on module-path only.
- //
- // Note that an explicit configuration of modular dependencies also opens
up the possibility of automatically
- // validating whether the dependency configuration for a gradle project is
consistent with the information in
- // the module-info descriptor because there is a (nearly?) direct
correspondence between the two:
- //
- // moduleApi - 'requires transitive'
- // moduleImplementation - 'requires'
- // moduleCompileOnly - 'requires static'
+ // Configure modular extensions for each source set.
//
project.sourceSets.all { SourceSet sourceSet ->
- ConfigurationContainer configurations = project.configurations
-
- // Create modular configurations for convention configurations.
- Closure<Configuration> createModuleConfigurationForConvention = { String
configurationName ->
- Configuration conventionConfiguration =
configurations.maybeCreate(configurationName)
- Configuration moduleConfiguration =
configurations.maybeCreate(moduleConfigurationNameFor(configurationName))
- moduleConfiguration.canBeConsumed(false)
- moduleConfiguration.canBeResolved(false)
- conventionConfiguration.extendsFrom(moduleConfiguration)
-
- project.logger.info("Created module configuration for
'${conventionConfiguration.name}': ${moduleConfiguration.name}")
- return moduleConfiguration
- }
-
- Configuration moduleApi =
createModuleConfigurationForConvention(sourceSet.apiConfigurationName)
- Configuration moduleImplementation =
createModuleConfigurationForConvention(sourceSet.implementationConfigurationName)
- moduleImplementation.extendsFrom(moduleApi)
- Configuration moduleRuntimeOnly =
createModuleConfigurationForConvention(sourceSet.runtimeOnlyConfigurationName)
- Configuration moduleCompileOnly =
createModuleConfigurationForConvention(sourceSet.compileOnlyConfigurationName)
- // sourceSet.compileOnlyApiConfigurationName // This seems like a very
esoteric use case, leave out.
-
- // Set up compilation module path configuration combining corresponding
convention configurations.
- Closure<Configuration> createResolvableModuleConfiguration = { String
configurationName ->
- Configuration conventionConfiguration =
configurations.maybeCreate(configurationName)
- Configuration moduleConfiguration = configurations.maybeCreate(
- moduleConfigurationNameFor(conventionConfiguration.name))
- moduleConfiguration.canBeConsumed(false)
- moduleConfiguration.canBeResolved(true)
- moduleConfiguration.attributes {
- // Prefer class folders over JARs. The exception is made for tests
projects which require a composition
- // of classes and resources, otherwise split into two folders.
- if (project.name.endsWith(".tests")) {
- attribute(LibraryElements.LIBRARY_ELEMENTS_ATTRIBUTE,
objects.named(LibraryElements, LibraryElements.JAR))
- } else {
- attribute(LibraryElements.LIBRARY_ELEMENTS_ATTRIBUTE,
objects.named(LibraryElements, LibraryElements.CLASSES))
- }
- }
-
- project.logger.info("Created resolvable module configuration for
'${conventionConfiguration.name}': ${moduleConfiguration.name}")
- return moduleConfiguration
- }
-
- Configuration compileModulePathConfiguration =
createResolvableModuleConfiguration(sourceSet.compileClasspathConfigurationName)
- compileModulePathConfiguration.extendsFrom(moduleCompileOnly,
moduleImplementation)
-
- Configuration runtimeModulePathConfiguration =
createResolvableModuleConfiguration(sourceSet.runtimeClasspathConfigurationName)
- runtimeModulePathConfiguration.extendsFrom(moduleRuntimeOnly,
moduleImplementation)
-
// Create and register a source set extension for manipulating
classpath/ module-path
- ModularPathsExtension modularPaths = new ModularPathsExtension(project,
sourceSet,
- compileModulePathConfiguration,
- runtimeModulePathConfiguration)
+ ModularPathsExtension modularPaths = new ModularPathsExtension(project,
sourceSet)
sourceSet.extensions.add("modularPaths", modularPaths)
- // Customized the JavaCompile for this source set so that it has proper
module path.
+ // LUCENE-10344: We have to provide a special-case extension for ECJ
because it does not
+ // support all of the module-specific javac options.
+ ModularPathsExtension modularPathsForEcj = modularPaths
+ if (sourceSet.name == SourceSet.TEST_SOURCE_SET_NAME && project.path in [
+ ":lucene:spatial-extras",
+ ":lucene:spatial3d",
+ ]) {
+ modularPathsForEcj =
modularPaths.cloneWithMode(ModularPathsExtension.Mode.CLASSPATH_ONLY)
+ }
+ sourceSet.extensions.add("modularPathsForEcj", modularPathsForEcj)
+
+ // TODO: the tests of these projects currently don't compile or work in
+ // module-path mode. Make the modular paths extension use class path
only.
+ if (sourceSet.name == SourceSet.TEST_SOURCE_SET_NAME && project.path in [
+ // Circular dependency between artifacts or source set outputs,
+ // causing package split issues at runtime.
Review comment:
I thought we have removed the split packages? What's the problem here?
Sorry you lost me :-)
##########
File path: lucene/core.tests/src/java/module-info.java
##########
@@ -0,0 +1,24 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+/**
+ * A placeholder module descriptor just so that we can check whether
referencing it from the actual
+ * test module works.
+ */
+module org.apache.lucene.core.tests.main {
Review comment:
This is only here for `TestRuntimeDependenciesSane`, correct? I hope we
do not need to do this for every modular test package like analysis random
chains or morfologik?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
