Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Somehow this plugin is excluding junit #21

Closed
wgorder opened this issue Dec 18, 2014 · 9 comments
Closed

Somehow this plugin is excluding junit #21

wgorder opened this issue Dec 18, 2014 · 9 comments

Comments

@wgorder
Copy link

wgorder commented Dec 18, 2014

To Reproduce:

go to start.spring.io create a new groovy/gradle/java 1.8 project with web, security, and actuator.

Alter the build.gradle to use the dependency management:

buildscript {
    ext {
        springBootVersion = '1.2.0.RELEASE'
    }
    repositories {
        mavenCentral()
    }
  dependencies {
    classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
    classpath 'io.spring.gradle:dependency-management-plugin:0.3.0.RELEASE'
  }
}

apply plugin: 'groovy'
apply plugin: 'eclipse'
apply plugin: 'idea'
apply plugin: 'spring-boot'
apply plugin: 'io.spring.dependency-management'

jar {
    baseName = 'my-appi'
    version = '0.0.1-SNAPSHOT'
}
sourceCompatibility = 1.8
targetCompatibility = 1.8

repositories {
    mavenCentral()
}

dependencyManagement {
  imports {
    mavenBom "org.springframework.boot:spring-boot-versions:${springBootVersion}"
  }
}

dependencies {
    compile("org.springframework.boot:spring-boot-starter-security")
    compile("org.springframework.boot:spring-boot-starter-web")
    compile("org.springframework.boot:spring-boot-starter-actuator")
    compile("org.codehaus.groovy:groovy")
    testCompile("org.springframework.boot:spring-boot-starter-test")
}

eclipse {
    classpath {
         containers.remove('org.eclipse.jdt.launching.JRE_CONTAINER')
         containers 'org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.8'
    }
}

task wrapper(type: Wrapper) {
    gradleVersion = '1.12'
}

The test will fail because of a missing junit dependency:
running gradle dependencies will show that indeed for whatever reason that one dependency is excluded.

Remove the dependency plugin and it works again.

@wilkinsona
Copy link
Contributor

Looks like a bug in 0.3.0 that aims to honour Maven exclusions. You may want to try 0.2.1 until a fix is available. Alternatively, declaring a direct dependency on JUnit should also work.

@wilkinsona wilkinsona added this to the 0.3.1 milestone Dec 18, 2014
szpak added a commit to 4finance/micro-infra-spring that referenced this issue Dec 18, 2014
There is a bug in dependency-management-plugin 0.3.0 which fails the
build:
spring-gradle-plugins/dependency-management-plugin#21

This reverts commit 14c4ab3.
@wgorder
Copy link
Author

wgorder commented Dec 18, 2014

Unfortunately the direct dependency on junit does not work. I had tried that first :)

@wilkinsona
Copy link
Contributor

Sorry about that. I'm intrigued now. There's a test that verifies that a direct dependency prevents an exclusion.

As an aside, and it won't help with this problem, you should use spring-boot-dependencies rather than spring-boot-versions.

@wgorder
Copy link
Author

wgorder commented Dec 18, 2014

I was wondering about that. I used the same convention as spring-cloud, although I noticed all spring boot does is pull in the dependencies pom anyway. I have no idea how that test passes based on what I saw, seems like a mystery.

@wgorder
Copy link
Author

wgorder commented Dec 19, 2014

Here is another weird one. With 0.3.0 this worked

dependencyManagement {
  imports {
    mavenBom "org.springframework.boot:spring-boot-dependencies:${springBootVersion}"
  }
}

but on 0.2.1 you have to do this

dependencyManagement {
  imports {
    mavenBom "org.springframework.boot:spring-boot-dependencies:1.2.0.RELEASE"
  }
}

or you get the error

 No such field: springBootVersion for class: io.spring.gradle.dependencymanagement.DependencyManagementHandler

@wgorder
Copy link
Author

wgorder commented Dec 19, 2014

Nvm :)
#17

@wilkinsona
Copy link
Contributor

This should now be fixed in 0.3.1.BUILD-SNAPSHOT which is available from https://repo.spring.io/plugins-snapshot. It'd much appreciated if you could give it a quick test and confirm that it's now working for you too. I might just manage to squeeze in a 0.3.1 release before Christmas.

@wgorder
Copy link
Author

wgorder commented Dec 19, 2014

Its working for me. Nice work!

@wilkinsona
Copy link
Contributor

Excellent. Thanks for testing it.

szpak added a commit to 4finance/micro-infra-spring that referenced this issue Dec 30, 2014
There is a bug in dependency-management-plugin 0.3.0 which fails the
build:
spring-gradle-plugins/dependency-management-plugin#21

This reverts commit 14c4ab3.
wilkinsona added a commit to wilkinsona/dependency-management-plugin that referenced this issue Jul 1, 2024
Previously, the dependency management plugin used a before resolve
action to apply Maven-style exclusions. Gradle performs configuration
resolution in two passes and, despite its name, a before resolve
action is called after the first pass. With Gradle 8.8 and later,
using a before resolve action to configure the exclusions can result
in a deprecation warning. The deprecation warning states that support
for mutating the dependency attributes of a configuration after it
has been resolved has been deprecated.

This commit addresses the deprecation warning by configuring the
exclusions earlier, in the withDependencies callback. The callback is
called before the first pass of the resolution process, thereby
avoiding the warning. Configuring the exclusions at this step
prevents the exclusions from being configured on a per-dependency
basis so they are now configured on the configuration. Without any
additional changes, this regresses the fix for spring-gradle-pluginsgh-21 as the
exclusions are now inherited and cause an exclusion in one
configuration where it should apply to leak into another
configuration where it should not. To overcome this regression,
exclusions are only applied to configurations that can be resolved.
Typically, these are configurations like compileClasspath,
testRuntimeClasspath and so on, that are leaves and are not extended
by other configurations, thereby minimizing the risk of any
inheritance-related problems.

Closes spring-gradle-pluginsgh-384
wilkinsona added a commit that referenced this issue Jul 2, 2024
Previously, the dependency management plugin used a before resolve
action to apply Maven-style exclusions. Gradle performs configuration
resolution in two passes and, despite its name, a before resolve
action is called after the first pass. With Gradle 8.8 and later,
using a before resolve action to configure the exclusions can result
in a deprecation warning. The deprecation warning states that support
for mutating the dependency attributes of a configuration after it
has been resolved has been deprecated.

This commit addresses the deprecation warning by configuring the
exclusions earlier, in the withDependencies callback. The callback is
called before the first pass of the resolution process, thereby
avoiding the warning. Configuring the exclusions at this step
prevents the exclusions from being configured on a per-dependency
basis so they are now configured on the configuration. Without any
additional changes, this regresses the fix for gh-21 as the
exclusions are now inherited and cause an exclusion in one
configuration where it should apply to leak into another
configuration where it should not. To overcome this regression,
exclusions are only applied to configurations that can be resolved.
Typically, these are configurations like compileClasspath,
testRuntimeClasspath and so on, that are leaves and are not extended
by other configurations, thereby minimizing the risk of any
inheritance-related problems.

Closes gh-384
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants