uschindler commented on a change in pull request #571:
URL: https://github.com/apache/lucene/pull/571#discussion_r778921454
##########
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:
Ah, so this is just for that special case. No problem, now I understand!
I remeber this one was always also a problem with the Maven build (for
non-modular reasons) so we had those fake projects with only tests or only
main, just to break the circular dep.
So in short Lucene core tests will run fully non-modular (testframework,
core, codecs all on classpath)?
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
