I'm trying to get rid of all the errors and warnings suggested by the IDE (Intellij).

Among them, a warning occurs in the log4j2 dependency removal code, as shown below.

'exclude' cannot be applied to '(['group':java.lang.String, 'module':java.lang.String])' 

I searched for a way to get rid of the error, and I succeeded in removing it.

But I don't know why it disappeared.

(the above alert. However, there is no problem in actual operation)

1. configurations {
       all {
           exclude group: 'org.springframework.boot', module: 'spring-boot-starter-logging'
       }
   }
   

2. configurations {
       implementation {
           exclude group: 'org.springframework.boot', module: 'spring-boot-starter-logging'
       }
   }
   

3. configurations {
       all {
           implementation {
               exclude group: 'org.springframework.boot', module: 'spring-boot-starter-logging'
           }
       }
   }
   

The first method is to display an error message.

The second and third methods do not have any error messages and work normally.

Could you point me to the difference between these three methods?

CodePudding user response：

As far as the IntelliJ warning goes - it seems like this is a caching issue that can resolve itself.

Configurations

configurations is a ConfigurationContainer - it contains many instances of configurations, with the type Configuration. Each configuration has a name.

(Aside: yes, the name 'configuration' is confusing. It doesn't mean "properties or settings used to configure the Gradle project", it means "a collection of files that might be outgoing artifacts, or incoming dependencies")

• configurations.all {} will retrieve all configurations, and attempt to configure each one using the contents of the lambda.

  Unless we're inside a task, resolving all configurations is usually (but not always!) bad practice, because it might trigger work that could have been avoided, which will make the build slower. Instead, try and use configurations.configureEach {}.

• configurations.implementation {} will retrieve a single configuration that is named implementation. The implementation configuration is created by the Java plugin. Again, the lambda will configure the configuration.

In both cases - the contents of the lambda will have a receiver type of Configuration.

configurations {
    all {
        // configure *all* configurations
        // this is a Configuration
        Configuration currentReceiver = this
    }
    implementation {
        // configure the 'implementation' configurations
        // this is also a Configuration
        Configuration currentReceiver = this
    }
}

Nested configurations

Your third example is unusual.

configurations {
    all {
        implementation {
            exclude group: 'org.springframework.boot', module: 'spring-boot-starter-logging'
        }
    }
}

What this does is that any time a Configuration is added to the project's ConfigurationContainer, the lambda is triggered. The lambda that you've defined will configure the implementation configuration, and add an exclusion.

This is equivalent to this:

configurations {
    ConfigurationContainer confContainer = this
    all {
        confContainer.implementation {
            exclude group: 'org.springframework.boot', module: 'spring-boot-starter-logging'
        }
    }
}

Which is weird... try to avoid nesting configurations like this! In this simple example, it probably works out okay, but it will cause problems if the inner lambda is dependent on the other lambda, because implementation is part of all - so it might cause some weird recursions.