Hi Adrian, I think that this is a Gradle problem. The reason seems to be that Gradle is gathering the dependencies of the configuration using Configuration#getAllDependencies()<http://www.gradle.org/current/docs/javadoc/org/gradle/api/artifacts/Configuration.html#getAllDependencies%28%29>- see the SelfResolvingDependencyResolver<https://github.com/gradle/gradle/blob/REL_1.0-milestone-3/subprojects/core/src/main/groovy/org/gradle/api/internal/artifacts/ivyservice/SelfResolvingDependencyResolver.java> .
This method returns a Set so there cannot be 2 dependencies which are equal in it. If you examine DefaultExternalModuleDependencies<https://github.com/gradle/gradle/blob/REL_1.0-milestone-3/subprojects/core/src/main/groovy/org/gradle/api/internal/artifacts/dependencies/DefaultExternalModuleDependency.java>'s equals() method (delegates to AbstractModuleDependency<https://github.com/gradle/gradle/blob/REL_1.0-milestone-3/subprojects/core/src/main/groovy/org/gradle/api/internal/artifacts/dependencies/AbstractModuleDependency.java>isKeyEquals()), you will notice that the artifacts are not part of the comparison, so when the two Foo dependencies (one using classifier) are added to this Set, the last one will overwrite the previous. This can be demonstrated with the following task: task printDependencies() << { def Closure printDependency = { Dependency d -> println "$d.group:$d.name:$d.version" if (d instanceof ModuleDependency) { if (d.artifacts.size() > 0) { d.artifacts.each { DependencyArtifact a -> println "\tartifact name=$a.name, type=$a.type, classifier=$a.classifier" } } else { //print default artifact println "\tartifact name=$d.name, type=jar" } } } println "\nPrinting all dependencies for configuration 'testCompile'" project.configurations.testCompile.allDependencies.each(printDependency) println "\nNow printing each dependency in the hierarchy of configuration 'testCompile'" project.configurations.testCompile.hierarchy.each { Configuration conf -> conf.dependencies.each(printDependency) } } So I guess it's the same bug: http://issues.gradle.org/browse/GRADLE-1442 Regards, Detelin On Thu, Jul 14, 2011 at 4:37 PM, Adrian Abraham <[email protected]>wrote: > I'm familiar with that thread, and it's what allowed me to get to where I > am now. > > I've attached a sample project demonstrating the problem and my current > (imperfect) solution. Foo and Bar are two separate projects (no master > here). Bar main depends on Foo, and Bar tests depends on both Foo main and > Foo tests. > > When "gradle install" is run from Foo, three artifacts get created in the > local Maven repository: foo, foo-tests, and foo-testsonly. You'll note that > the files in both foo and foo-tests are identical (except for the names), > and that the Maven metadata is present. As far as dependencies go, this > works OK, even if it is wasteful. However, the sources jars are a problem, > since the Idea plugin automatically uses jars with a "sources" classifier. > Since I have to use "testsources" as the classifier for the test sources, > the Idea plugin doesn't pick it up. > > I included foo-testsonly to demonstrate the problem with Maven metadata. > You'll notice that, in the Maven repository, only the tests jars are present > - no Maven metadata is generated. (However, I think I've found a bug. If you > run "gradle install" twice, foo-onlytests actually gets populated with every > jar and with the Maven metadata.) > > Ideally, I think Foo's main source and binary archives should go into > foo/foo (with no classifier and the "sources" classifier, respectively), > Foo's tests source and binary archive should go into foo/foo-tests (with no > classifier and the "sources" classifier, respectively), and both foo and > foo-tests should have Maven metadata generated. > > Thank you for your help. > > - Adrian > > > On Tue, Jul 12, 2011 at 8:43 PM, Luke Daley <[email protected]>wrote: > >> Hi Adrian, >> >> Unfortunately, Ivy is full of problems with artifacts with classifiers. >> The crux of the problem is that in some cases it doesn't see that artifacts >> with the same details except the classifier are actually different. This is >> something we are aware of and are working to remedy. >> >> This means now though that you should avoid classifiers if at all possible >> except to satisfy the maven repository requirement for -sources and -javadoc >> jars. >> >> >> You should indeed model your tests jar as a separate artifact. If you can >> describe how your project is laid out we can help you with the config to do >> this. >> >> Towards the end of the following thread it starts discussing generating >> multiple artifacts in a project: >> >> >> http://gradle.1045684.n5.nabble.com/Create-multiple-jars-from-same-sourceset-td4490899.html >> >> -- >> Luke Daley >> Principal Engineer, Gradleware >> http://gradleware.com >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > >
