I'm using gradle-7.6.4 and JDK17. I have multi-pro...
# community-support
s
I'm using gradle-7.6.4 and JDK17. I have multi-project setup. When i save root project/subproject build.gradle file in vscode editor, i'm getting below warnings: Resolution of the configuration api container commonannotationProcessor was attempted from a context different than the project context. Have a look at the documentation to understand why this is a problem and how it can be resolved. This behaviour has been deprecated and is scheduled to be removed in Gradle 8.0. See https://docs.gradle.org/7.6.4/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors for more details. Resolution of the configuration api container commonarchives was attempted from a context different than the project context. Have a look at the documentation to understand why this is a problem and how it can be resolved. This behaviour has been deprecated and is scheduled to be removed in Gradle 8.0. See https://docs.gradle.org/7.6.4/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors for more details. Resolution of the configuration api container commoncompileClasspath was attempted from a context different than the project context. Have a look at the documentation to understand why this is a problem and how it can be resolved. This behaviour has been deprecated and is scheduled to be removed in Gradle 8.0. See https://docs.gradle.org/7.6.4/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors for more details. Resolution of the configuration api container commondefault was attempted from a context different than the project context. Have a look at the documentation to understand why this is a problem and how it can be resolved. This behaviour has been deprecated and is scheduled to be removed in Gradle 8.0. See https://docs.gradle.org/7.6.4/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors for more details. Resolution of the configuration api container commonruntimeClasspath was attempted from a context different than the project context. Have a look at the documentation to understand why this is a problem and how it can be resolved. This behaviour has been deprecated and is scheduled to be removed in Gradle 8.0. See https://docs.gradle.org/7.6.4/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors for more details. Resolution of the configuration api container commontestAnnotationProcessor was attempted from a context different than the project context. Have a look at the documentation to understand why this is a problem and how it can be resolved. This behaviour has been deprecated and is scheduled to be removed in Gradle 8.0. See https://docs.gradle.org/7.6.4/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors for more details. Resolution of the configuration api container commontestCompileClasspath was attempted from a context different than the project context. Have a look at the documentation to understand why this is a problem and how it can be resolved. This behaviour has been deprecated and is scheduled to be removed in Gradle 8.0. See https://docs.gradle.org/7.6.4/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors for more details. Resolution of the configuration api container commontestRuntimeClasspath was attempted from a context different than the project context. Have a look at the documentation to understand why this is a problem and how it can be resolved. This behaviour has been deprecated and is scheduled to be removed in Gradle 8.0. See https://docs.gradle.org/7.6.4/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors for more details. CONFIGURE SUCCESSFUL in 848ms When i run the tasks, build etc commands from command line, i dont see any warnings. I followed the doc shared in the warning details.. but couldn't figure out.. I want to make sure my changes won't break when i upgrade to Gradle-8.0 in future.. Below are details about gradle files: rootproject's settings.gradle
Copy code
rootProject.name = 'my-root-project'
include 'platform'
include 'api-container-framework'
rootproject's build.gradle
Copy code
plugins {
    id 'java-platform'
    id 'maven-publish'
}

ext {
    repoConfig = {
        url = uri(myserver)
        credentials {
            username = repoUsername
            password = repoPassword
        }
        allowInsecureProtocol true
        
    }
} 

allprojects {
    repositories {
        //for fetching dependencies...
        maven   repoConfig
    }
}


subprojects {
    //except platform, remaining need to be published as jars...
    //if (project != project(':platform')) { 
        apply plugin: 'maven-publish'
    //}
   
    publishing {

        repositories {
            //repoConfig() //for publishing artifacts...
            maven repoConfig
            
        }

        publications {
            if (plugins.hasPlugin('java')) { //publish java plugin projects only
                mavenJava(MavenPublication) {
                    from components.java
                }
            }
        } 
    }
}
platform/build.gradle
Copy code
plugins {
    id 'java-platform'
}


dependencies {
    constraints {
    	api "org.springframework:spring-core:5.3.22"
    	api "org.springframework:spring-beans:5.3.22"
		api "org.springframework:spring-context:5.3.22"
		api "org.springframework:spring-aop:5.3.22"
		api "org.springframework:spring-web:5.3.22"
		
		api 'org.apache.cxf:cxf-core:3.5.3'
		api "org.apache.cxf:cxf-rt-transports-http:3.5.3"
		api "org.apache.cxf:cxf-rt-frontend-jaxrs:3.5.3"
		
		...
    } 
	
}
api-container-framework/build.gradle
Copy code
plugins {
	id 'java'
}


dependencies {
	
	implementation(enforcedPlatform(project(':platform')))


	
    implementation 'org.springframework:spring-core'
    implementation "org.slf4j:slf4j-api"
    
    //this will be provided by containers like tomcat at runtime, so just add it for compilation
    compileOnly "jakarta.servlet:jakarta.servlet-api" 
}
🧵 2
v
Please do not post that long messages to the main channel, but better post a short message and further details and snippets in the thread. Otherwise it is for example hard to follow the channel from mobile devices. Where those deprecations are coming from, you should be able to find out by using
--stacktrace
(resp. the according Gradle property
org.gradle.logging.stacktrace
as you said it is not happening from commandline). But anyway as you said it is only while syncing in VSC and not when building from commandline, it sounds like VSC is doing something evil that you need to report. Besides that you follow quite some bad practices in your build scripts if you care. For example: • do not use
ext
when you could use a local variable, or actually never use
ext
anyway, each time you use
ext
it is a sign that you do some work-around instead of doing it properly • better use the built-in credential handling instead of reading Gradle properties manually and setting them explicitly (https://docs.gradle.org/7.6.4/userguide/declaring_repositories.html#sec:handling_credentials) • do not use any way of cross-project configuration like
allprojects { ... }
,
subprojects { ... }
,
project(...) { ... }
, or any other means. This immediately introduces project coupling, working against some more sophisticated Gradle features and optimizations. Better consider using convention plugins from
buildSrc
or and included build, for example implemented as precompiled script plugins • do not use the legacy
apply ...
to apply plugins, but always the
plugins { ... }
block • never use
project.plugins
(see its Javadoc), instead if you want to react to a plugin being applied use
pluginManager.withPlugin(...) { ... }
which also works independent from when the plugin is applied, now or later •
enforcedPlatform
should be a really exceptional very-last-resort thing and should almost never be used. Especially not in something that is a library but if at all then only in an end project. Given the name "...-framework" I at least assume this is a library, not an end product. Also if it is a library, better use
java-library
plugin, not
java
. • And last but not least more a personal recommendation. Consider switching to Kotlin DSL. By now it is the default DSL, you immediately get type-safe build scripts, actually helpfule error messages if you mess up the syntax, and amazingly better IDE support when using a good IDE like IntelliJ IDE or Android Studio.
s
Thanks a lot for taking time and giving reply in detail. Sure next time will create a thread as you suggested and coming to your suggestions, will definitely look into them and try to follow. šŸ™‚
šŸ‘Œ 1
Except the last recommendation, followed everything.. now i have buildSrc where i defined common stuff for subprojects and i have platform/build.gradle to manage dependencies across subprojects.. Along with this im defining a bom at root project's build.gradle to publish the same to consumers.. everything works fine.. but i wanted to centralize the repositories definition .. currently im defining in 3 gradle files, one at root bom, one at platform bom and at buildSrc/java-conventions.gradle to publish like this.. below code i defined at root project's
build.gradle
..
Copy code
def isLocal = project.findProperty('bom.mode') == 'local'
println "islocal: $isLocal"

dependencies {
    constraints {
       if (isLocal) {
            // Use local project references
            api platform(project(':platform'))
            api project(':api-container-framework')
            api project(':api-container-common')
           //api project(':api-container-introspector')
        } else {
            // Use published artifacts for external consumers
            api "pg-inhouse:api-framework-platform-bom:${version}"
            api "pg-inhouse:api-container-framework:${version}"
            api "pg-inhouse:api-container-common:${version}"
            //api "pg-inhouse:api-container-introspector:${version}"
        }
    }
}

//centralized configuration for publishing
ext.configurePublishingRepositories = {
    repositories {
        println "inside configurePublishingRepositories islocal: $isLocal"

        if (isLocal) {
            maven {
                name = 'local'
                url = uri("${rootProject.buildDir}/repo")
            }
        } else {
            maven {
                name = 'ivyRepo'
                url = uri(repoUrl)
                credentials(PasswordCredentials)
                allowInsecureProtocol true
            }
        }
    }
}
Just to update, above logic i got from chatgpt.. it asked me to call the same at in each gradle file like this...
Copy code
publishing {
         publications {
            mavenJava(MavenPublication) {
                from components.java
            }
        } 

        configurePublishingRepositories()
}
but its not at all working.. artifacts not getting published but i see that method getting invoked with isLocal true
but if i copy the code and use at each gradle file publishing block, its working as expected.. not sure what i'm missing..
v
if (isLocal) {
for the dependencies / constraints should not be necessary, when you publish, the project dependencies should be written to the POM as normal coordinates.
if (isLocal) {
for the publishing repositories, better just declare two repositories, then you get a task for each of them and can just choose by the task you call to which you want to publish and even can publish to both at once if you want. Btw. you said you followed all recommendations, but I still see an
ext.
. šŸ˜‰
not sure what i'm missing.
You miss, that you use ChatGPT for something it is not suited for. All those AI tools are very good in giving answers that look correct, but utterly bad in giving answers that are correct. They are suitable to do things for you that you could do yourself but are too lazy to do. (the good kind of lazy, not the bad one) But you always have to understand exactly what it gave you and need to be able to verify and fix the non-sense it produces.
šŸ˜… 1
s
Yeah... i had to use
ext
for this logic only to share the method across all subprojects.. anyways, will get rid of that.. thanks for the witty reply .. šŸ˜„ .. just few doubts, i) for dependencies, you are saying, i dont need to have isLocal logic at all .. instead i can simply use referencing projects itself whether its local or to external consumers.. ultimately only dependencies co-ordinates will be published to BOMs/POMs.. ii) for publishing, i don't want to publish to org artifactory when publishing from local machine to verify changes.. so i put that condition.. will try your task suggestions for this.. I agree these AI tools are not always correct, will verify the solutions before i actually put them in use.. šŸ™‚