Grails 7: grails-spring-security-cas

[bkoehm]

No description provided.

[codeconsole]

@bkoehm please seem my question regarding the configurations {} block

[codeconsole]

@bkoehm I was referring to the configurations.configureEach {} block where you are forcing the version of gradle. That should not be needed if you have groovyVersion set in gradle.properties

[codeconsole]

@bkoehm

onfigurations {
    all {
        exclude group: 'javax.servlet'
        exclude group: 'javax.xml.bind'
    }
}

why is that needed in plugin/build.gradle?

[bkoehm]

@bkoehm

onfigurations {
    all {
        exclude group: 'javax.servlet'
        exclude group: 'javax.xml.bind'
    }
}

why is that needed in plugin/build.gradle?

Because there are dependencies that leak javax.servlet and javax.xml.bind (at least, there were as of a few days ago).

[codeconsole]

why is that needed in plugin/build.gradle?

Because there are dependencies that leak javax.servlet and javax.xml.bind (at least, there were as of a few days ago).

I don't see anywhere where that should be the case. If so, they should be updated to the latest version.

grails-spring-security-cas/plugin/build.gradle

Lines 65 to 82 in 545d30b

	dependencies {
	compileOnly "javax.servlet:javax.servlet-api:$javaxServletApiVersion"
	compileOnly "org.springframework.boot:spring-boot-starter-logging"
	compileOnly "org.grails:grails-web-boot"
	profile "org.grails.profiles:web-plugin"
	api "org.grails.plugins:spring-security-core:$springSecurityCoreVersion"
	api "org.jasig.cas.client:cas-client-core:$casClientCoreVersion", {
	exclude module: 'slf4j-api'
	}
	api "org.springframework.security:spring-security-cas:$springSecurityVersion", {
	['spring-beans', 'spring-context', 'spring-core', 'spring-security-core',
	'spring-security-web', 'spring-web'].each { exclude module: it }
	}
	documentation "com.github.javaparser:javaparser-core:3.25.8"
	}

If it is ever the case, the preference is the exclusion on the dependency that has the older dependency.

[bkoehm]

why is that needed in plugin/build.gradle?

Because there are dependencies that leak javax.servlet and javax.xml.bind (at least, there were as of a few days ago).

I don't see anywhere where that should be the case. If so, they should be updated to the latest version.

grails-spring-security-cas/plugin/build.gradle

Lines 65 to 82 in 545d30b

	dependencies {
	compileOnly "javax.servlet:javax.servlet-api:$javaxServletApiVersion"
	compileOnly "org.springframework.boot:spring-boot-starter-logging"
	compileOnly "org.grails:grails-web-boot"
	profile "org.grails.profiles:web-plugin"
	api "org.grails.plugins:spring-security-core:$springSecurityCoreVersion"
	api "org.jasig.cas.client:cas-client-core:$casClientCoreVersion", {
	exclude module: 'slf4j-api'
	}
	api "org.springframework.security:spring-security-cas:$springSecurityVersion", {
	['spring-beans', 'spring-context', 'spring-core', 'spring-security-core',
	'spring-security-web', 'spring-web'].each { exclude module: it }
	}
	documentation "com.github.javaparser:javaparser-core:3.25.8"
	}

If it is ever the case, the preference is the exclusion on the dependency that has the older dependency.

Ok, removed.

[codeconsole]

@bkoehm thanks, quick question, you deleted the second server. How is it tested now? Do you just start the first server on a different port?

[bkoehm]

@bkoehm thanks, quick question, you deleted the second server. How is it tested now? Do you just start the first server on a different port?

Yes, the second test app was a dupe of the first one. And it requires a working CAS server to test with. It's not an automated test.

[codeconsole]

@bkoehm thanks, quick question, you deleted the second server. How is it tested now? Do you just start the first server on a different port?

Yes, the second test app was a dupe of the first one. And it requires a working CAS server to test with. It's not an automated test.

@bkoehm Was there an automated test previously? I am sure it would be easy enough to just pass the port at startup so removing it was the right call.

[bkoehm]

@bkoehm thanks, quick question, you deleted the second server. How is it tested now? Do you just start the first server on a different port?

Yes, the second test app was a dupe of the first one. And it requires a working CAS server to test with. It's not an automated test.

@bkoehm Was there an automated test previously? I am sure it would be easy enough to just pass the port at startup so removing it was the right call.

No, there wasn't.