search

JPro-one / JPro

The right place to report about bugs or suggest improvements for JPro.
https://www.jpro.one
9 stars 4 forks source link

Dependency conflicts when trying to integrate the jpro plugin in existing gradle project #125

Closed effad closed 2 years ago

effad commented 2 years ago

We have an existing (and rather complex) gradle project setup. I've tried to add jpro by adding 

        maven {
            url "https://sandec.jfrog.io/artifactory/repo"
        }

and

    dependencies {
        ...
        classpath 'com.sandec.jpro:jpro-plugin-gradle:2022.1.0'
    }

and

    apply plugin: 'com.sandec.jpro';

to the topmost build.gradle

Now when I try to start gradle (version 7.3), I get version conflicts within the used libraries:

[rli@rlimbus ControlCenter]$ gradlew tasks

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring project ':project:apps:AbbyyOCRTest'.
> Could not resolve all dependencies for configuration ':project:apps:AbbyyOCRTest:jproserver'.
   > Conflict(s) found for the following module(s):
       - com.typesafe.play:twirl-api_2.12 between versions 1.5.1 and 1.4.2
       - com.google.inject:guice between versions 5.0.1 and 4.2.3
       - commons-io:commons-io between versions 2.7 and 2.6
       - commons-codec:commons-codec between versions 1.14, 1.10 and 1.11
       - org.scala-lang:scala-library between versions 2.12.15, 2.12.12, 2.12.13, 2.12.8, 2.12.11, 2.12.0 and 2.12.10
       - org.scala-lang:scala-reflect between versions 2.12.15, 2.12.12, 2.12.11 and 2.12.10
       - junit:junit between versions 4.13.2 and 4.11
       - com.google.guava:guava between versions 30.1.1-jre, 30.1-jre and 25.0-jre
       - org.slf4j:slf4j-api between versions 1.7.32, 1.7.26 and 1.7.7
       - org.slf4j:jul-to-slf4j between versions 1.7.32 and 1.7.26
       - com.fasterxml.jackson.core:jackson-core between versions 2.11.4 and 2.9.8
       - ... and more
     Run with:
         --scan or
         :project:apps:AbbyyOCRTest:dependencyInsight --configuration jproserver --dependency com.typesafe.play:twirl-api_2.12
     to get more insight on how to solve the conflict.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

See https://docs.gradle.org/7.3/userguide/command_line_interface.html#sec:command_line_warnings

BUILD FAILED in 9s
5 actionable tasks: 5 up-to-date

I've run gradlew --scan and according to https://scans.gradle.com/s/v3tasvaerfvrc/dependencies?dependencies=com.typesafe&expandAll&focusedDependency=WzAsMCwyNzYsWzAsMCxbN11dXQ&focusedDependencyView=versions the conflicting versions all come from JPro.

FlorianKirmaier commented 2 years ago

I assume you are not using Scala or Play in any way, right?

Do you get the same error, when you run this way in the HelloJPro project? I tried it, and I think It looks good, but i don't know whether I've done the same as you.

It should just always pick the newest specified version - but I guess dependent on the configuration - having multiple versions is considered to be an error.

effad commented 2 years ago

I assume you are not using Scala or Play in any way, right?

Right, not using those myself.

Do you get the same error, when you run this way in the HelloJPro project? I tried it, and I think It looks good, but i don't know whether I've done the same as you.

I've cloned the HelloJPro project and it works fine.

It should just always pick the newest specified version - but I guess dependent on the configuration - having multiple versions is considered to be an error.

Maybe this is triggered by some other plugin we're using simultanously... Or it is the fact that we have a gradle multi-project setup.

FlorianKirmaier commented 2 years ago

And Scala also isn't used by some dependency or some subproject?

It's shouldn't be a problem, that JPro is used in a multi-project setup, we do this for most of our projects.

But does this cause any issue, when using JPro, except by showing these warnings? I think it should be fine - it's just doesn't like how the dependencies are overwritten, but this shouldn't cause problems, it's tested countless times, and it works.

effad commented 2 years ago

But does this cause any issue, when using JPro, except by showing these warnings? These are not warnings, they are error. As soon as the jpro plugin is applied to the project, I can no longer build. gradlew jproRun will also not work of course ...


[rli@rlimbus ControlCenter]$ gradlew jproRun

Configure project :project:apps:CodeTest
Project :project:apps:CodeTest => no module-info.java found

Configure project :project:libs:GUI
Project :project:libs:GUI => no module-info.java found

Configure project :project:libs:XDSCommon
Project :project:libs:XDSCommon => no module-info.java found

Configure project :project:products:ControlCenter
Project :project:products:ControlCenter => no module-info.java found

FAILURE: Build failed with an exception.

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

See https://docs.gradle.org/7.3/userguide/command_line_interface.html#sec:command_line_warnings

BUILD FAILED in 2s 5 actionable tasks: 5 up-to-date



Maybe one of the other gradle plugins uses scala...
FlorianKirmaier commented 2 years ago

To me, this looks like the dependencies, internally used by JPro - which are just resolved normally by taking the latest version of each dependency. My guess is, that somewhere Gradle is configured differently to warn/error about these dependencies.

Did you receive my email with your contact request?

FlorianKirmaier commented 2 years ago

If you suspect this is caused by a Gradle plugin - what you can do is, add these Plugins to our HelloWorld, and check whether it then created the same error.

effad commented 2 years ago

I've tried to remove all plugins from our build configuration -- to no avail. I think a screen-sharing-session is probably the best way to go forward...

effad commented 2 years ago

I've found the culprit. It was a very well hidden piece of code in our build system setup:

    def addDependencyResolutionStrategy() {
        project.configurations.all {
            resolutionStrategy {
                failOnVersionConflict()
            }
        }       
    }

which should only prevent our products from being built with conflicting dependencies (we resolve them manually). However, since configurations.all is used it also extends to the configuration JPro adds.