bmuschko / gradle-cargo-plugin

Gradle plugin that provides deployment capabilities to local and remote containers via Cargo
Apache License 2.0
258 stars 63 forks source link

No value has been specified for property 'classpath' #207

Closed morayKevin closed 1 year ago

morayKevin commented 1 year ago

Hi, I use the cargo plugin (2.8.0) to deploy on payara servers. To do this, I have a gradle file (master) which contains this: buildscript { repositories { maven { url = "http://w2016-nexus.fedris.be:8089/nexus/repository/maven-central/" } maven { url = "http://w2016-nexus.fedris.be:8089/nexus/repository/plugin-gradle/" } } dependencies { classpath("com.bmuschko:gradle-cargo-plugin:2.8.0") } }

and my cargo tasks are in another gradle file (deployment.gradle) apply from: System.getenv('GRADLE_UTILS') + '\\fedris\\deployment.gradle'

Everything works fine.

but now I want to use Sonarqube plugin. So I modified my dependencies to add this plugin.

So I have this in my buildscript buildscript { repositories { maven { url = "http://w2016-nexus.fedris.be:8089/nexus/repository/maven-central/" } maven { url = "http://w2016-nexus.fedris.be:8089/nexus/repository/plugin-gradle/" } } dependencies { classpath ("org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:3.4.0.2513") classpath("com.bmuschko:gradle-cargo-plugin:2.8.0") } }

simply adding a new classpath in the dependencies causes cago to no longer work. It gives me the following error: **A problem was found with the configuration of task ':undeployFromGlassfish'.

No value has been specified for property 'classpath'.**

how can i solve this problem? I imagine that it is possible to use several plugins at the same time

bmuschko commented 1 year ago

I'd need to see a full example to see what's going on here. Can you put together a GitHub repository that reproduces the issue and doesn't point to your internal binary repository? Make sure to check in your Gradle wrapper.

morayKevin commented 1 year ago

here is a project that reproduces the problem: https://github.com/morayKevin/cargo_bug

I am currently using gradle 6.x but I have the same problem with gradle 7.x. I didn't test with gradle 8.x

in the master branch, the cargo plugin "works" gradle undeployFromGlassfish -Pbranch=environment/test -PuserLogin=login -PuserPassword=password I get an error from the cargo plugin just normal: > java.lang.IllegalStateException: error submitting remote command and displaying classpath gives this: Cargo classpath : configuration ':cargo'

in the bug branch, I added the sonarqube plugin, the cargo plugin don't works gradle undeployFromGlassfish -Pbranch=environment/test -PuserLogin=login -PuserPassword=password I get an error with the classpath: No value has been specified for property 'classpath'. and displaying classpath gives this: Cargo classpath : null

I hope it can help you

bmuschko commented 1 year ago

Do me a favor and check in the Gradle Wrapper with the version you are using for your project. I am already using Gradle 8 which your project isn't compatible with anymore. A couple of things you should address up-front:

morayKevin commented 1 year ago

I am using gradle version 6.9.

I know that if I want to use the 7+ version, I have to replace compile and ...

I did not configure the cargo plugin in a sub-project. the gradles files which is in externalGradles are not part of the project. There is only domain, service, web as a sub-project.

The goal is to have gradle files common to all my projects in order to avoid code duplication. So I have to configure the plugin in the root project for it to work.

And it works, provided you don't add a second plugin.

I can try upgrading to gradle 8.

bmuschko commented 1 year ago

You configure the plugin in deployment.gradle and the root project. Either way, it is not necessary. And keep in mind that you do add the plugin to the classpath but you do not apply the plugin. That causes the classpath property of the Cargo tasks not to have a value.

You may think that adding a second plugin is the issue, but it may just cause some evaluation to happen that you don't see otherwise. The real reason is the one above.

morayKevin commented 1 year ago

Ok, i just pushed in the bug branch in order to be compabtible with gradle 8.

I understand your explanation, but I don't see how to solve it?

If I remove from the root project, I get the following error: Plugin with id 'com.bmuschko.cargo-base' not fount

if I remove it from deployment.gradle I get the following error: `Could not compile script 'C:\Users\moray\IdeaProjects\cargo_bug\externalGradle\deployment.gradle'.

startup failed: script 'C:\Users\moray\IdeaProjects\cargo_bug\externalGradle\deployment.gradle': 7: unable to resolve class com.bmuschko.gradle.cargo.convention.Deployable @ line 7, column 1. import com.bmuschko.gradle.cargo.convention.Deployable ^ script 'C:\Users\moray\IdeaProjects\cargo_bug\externalGradle\deployment.gradle': 8: unable to resolve class com.bmuschko.gradle.cargo.convention.ContainerProperties @ line 8, column 1. import com.bmuschko.gradle.cargo.convention.ContainerProperties ^ script 'C:\Users\moray\IdeaProjects\cargo_bug\externalGradle\deployment.gradle': 9: unable to resolve class com.bmuschko.gradle.cargo.tasks.remote.CargoDeployRemote @ line 9, column 1. import com.bmuschko.gradle.cargo.tasks.remote.CargoDeployRemote ^ script 'C:\Users\moray\IdeaProjects\cargo_bug\externalGradle\deployment.gradle': 10: unable to resolve class com.bmuschko.gradle.cargo.tasks.remote.CargoRedeployRemote @ line 10, column 1. import com.bmuschko.gradle.cargo.tasks.remote.CargoRedeployRemote ^ script 'C:\Users\moray\IdeaProjects\cargo_bug\externalGradle\deployment.gradle': 11: unable to resolve class com.bmuschko.gradle.cargo.tasks.remote.CargoUndeployRemote @ line 11, column 1. import com.bmuschko.gradle.cargo.tasks.remote.CargoUndeployRemote ^ 5 errors`

can you tell me what to change?

bmuschko commented 1 year ago

You are running into a "limitation" of how Gradle handles classpaths for different contexts, my guess.

  1. The deployment.gradle has its own build script classpath compared to the root build.gradle file. You have a lot of use of script plugins where one script plugin calls another one. I'd try to get rid of that. Each of them have their own classpath.
  2. The concept of a script plugin isn't necessarily recommended to be used anymore by Gradle. You should implement the plugin as a binary plugin under buildSrc.
  3. There's also this weird mismatch in behavior between the buildscript and plugins notation in Gradle especially if you are importing classes.
  4. I would apply the code for deployment only to the web subproject. That's the only place where this is really relevant.

Sorry, I can't give you any concrete "fix" or guidance. I simply don't have the time for it. I'd recommend asking about this on the Gradle forum or community Slack channel. Personally, I'd try to move the build code to where it belongs first without the use of script plugins. Then as a next step, implement the logic as binary plugins under buildSrc. There's still the possibility that the Sonarqube plugin messes with the build script classpath somehow but I'd need to look their source code.

morayKevin commented 1 year ago

I tried to put the use of the cargo plugin in the web project. `buildscript { repositories { maven { url = "http://w2016-nexus.fedris.be:8089/nexus/repository/maven-central/" } } dependencies { classpath("com.bmuschko:gradle-cargo-plugin:2.8.0") } }

apply from: System.getenv('GRADLE_UTILS') + '\fedris\deployment.gradle' apply from: System.getenv('GRADLE_UTILS') + '\fedris\fedrisgwt.gradle'`

and then to use the sonar plugin in the root project. but i still get the same error

`buildscript { repositories { maven { url = "http://w2016-nexus.fedris.be:8089/nexus/repository/maven-central/" } maven { url = "http://w2016-nexus.fedris.be:8089/nexus/repository/plugin-gradle/" } } dependencies { classpath ("gradle.plugin.io.github.http-builder-ng:http-plugin:0.1.1") classpath ("org.sonarsource.scanner.gradle:sonarqube-gradle-plugin:3.4.0.2513") } }

apply plugin: 'org.sonarqube'`

morayKevin commented 1 year ago

but if i do the opposite, put sonar in web and cargo in root, it seems ok

Vampire commented 1 year ago

@bmuschko you can close this, it has nothing to do with your plugin. It's just the usual classloader fun if someone has the idea to use legacy script plugins. If you are interested in the full story, see my comment at https://discuss.gradle.org/t/no-value-has-been-specified-for-property-classpath/45212/2.

But you should maybe consider at some point removing the usage of internal convention mapping functionality and replacing it by the proper public APIs. :-) Not that it would have changed anything in this case.

bmuschko commented 1 year ago

@Vampire Thanks, I provided most of your points here: https://github.com/bmuschko/gradle-cargo-plugin/issues/207#issuecomment-1478236024. Happy to accept a PR to change convention mapping as I am not planning to work on it myself at this time. See README.md.

Vampire commented 1 year ago

I only found this issue after I answered there. As I'm not even knowing what this plugin is about, don't expect any PRs from me. :-D

bmuschko commented 1 year ago

@Vampire No worries. This was more of a general statement to community. Thanks!