dweiss commented on a change in pull request #571:
URL: https://github.com/apache/lucene/pull/571#discussion_r778718571
##########
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?
These projects can't be configured properly. They're the upper-right box in
the diagram in my comment in LUCENE-10328, but they require modular
dependencies that break split package constraint.
For example, when running core tests, the core sources and tests are on
classpath but they require the test framework (modular) which in turn requires
codecs (modular) which in turn requires core (modular, main sourceset). Either
you will have an unresolved module (core) or split packages between the core
and tests (on classpath).
I don't think this is solvable, but be my guest and try it. You can easily
see what is happening if you uncomment one of these projects from the
classpath-forced statement above and then running:
```
gradlew -p lucene/core test -Pbuild.debug.paths=true
```
Take a look at what's on modular path, what's on classpath and you'll see
the problem.
--
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
