Smack/smack-tcp/build.gradle

description = """\
Smack for standard XMPP connections over TCP."""

dependencies {
	compile project(':smack-core')
	testCompile project(path: ":smack-core", configuration: "testRuntime")
}
Prefix subprojects with 'smack-' instead of using the old baseName=smack appendix=project.name approach, we are now going convention over configuration and renaming the subprojects directories to the proper name. Having a prefix is actually very helpful, because the resulting libraries will be named like the subproject. And a core-4.0.0-rc1.jar is not as explicit about what it actually is as a smack-core-4.0.0-rc1.jar. SMACK-265 2014-04-28 19:27:53 +02:00			`description = """\`
			`Smack for standard XMPP connections over TCP."""`

			`dependencies {`
			`compile project(':smack-core')`
Fix 'test' dependencies The previously used approach of project(':smack-core').sourceSets.test.runtimeClasspath caused the 'eclipse' target to produce duplicate classpath entries in .classpath when run with Gradle >= 2.6. It also relied on Gradle internals. Instead we now use project(path: ":smack-core", configuration: "testRuntime") project(path: ":smack-core", configuration: "archives") to be able to use test classes from other subprojects (usually smack-core) in e.g. smack-extensions. The 'archives' configuration includes the test jar. See also https://discuss.gradle.org/t/11784 Thanks to Lari Hotari for helping with this issue. 2016-02-10 12:39:18 +01:00			`testCompile project(path: ":smack-core", configuration: "testRuntime")`
Prefix subprojects with 'smack-' instead of using the old baseName=smack appendix=project.name approach, we are now going convention over configuration and renaming the subprojects directories to the proper name. Having a prefix is actually very helpful, because the resulting libraries will be named like the subproject. And a core-4.0.0-rc1.jar is not as explicit about what it actually is as a smack-core-4.0.0-rc1.jar. SMACK-265 2014-04-28 19:27:53 +02:00			`}`