On Oct 24, 2009, at 10:59 PM, Adam Murdoch wrote:
Hi,
This problem is due to how we use ivy to resolve project
dependencies. Basically, for a project dependency, Gradle
(incorrectly) matches on the name of the target project, not the
path of the target. This means that if you have a dependency on a
project and there are multiple projects with the same name as the
target project, Gradle will always use the artifacts from an
arbitrarily chosen one of these projects.
The problem is that the projects with name java14/java15 share the
same group which is set in the root project to: group =
'org.springframework'
You could do in the build.gradle of :modules:spring-beans:
subprojects {
group += ".spring-beans"
}
and in core:
subprojects {
group += ".spring-core"
}
You will still get the same output as below, as this output is
generated before the :modules:spring-x projects are evaluated. But at
execution time everything should work fine.
To get the desired behavior at configuration time you can do
in :modules :
[project('java14'), project('java15')]*.group = 'org.springframework'
+ name
I've added: http://jira.codehaus.org/browse/GRADLE-718
Of course at the least you should have gotten an exception pointing
out the problem.
For pure resolution of project dependencies we could easily change the
behavior so that the group attribute is not necessary for this. On the
other hand the group attribute is needed if you want to publish your
multi-project build artifacts together with a ivy/pom xml.
What we could do is to define an extra attribute for the generated ivy
descriptor. This would contain the unique path of a project. This
attribute would be used for resolving project dependencies as part of
a Gradle multi-project build. For publishing we would use the group
attribute in the published ivy/pom xml. In the case of the attached
build, building the project would work. When doing publishing, the
second publishing would overwrite the artifacts of the first publishing.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
Steven Devijver wrote:
Hey Adam,
This output demonstrates the problem I'm experiencing:
Project for dependencies: spring-beans
For spring-beans:
F:\spring-framework-2.5.6.SEC01\modules\spring-beans\java14\build
\libs\java14-2.
5.6.SEC01.jar
Project for dependencies: spring-core
For spring-core:
F:\spring-framework-2.5.6.SEC01\modules\spring-beans\java14\build
\libs\java14-2.
5.6.SEC01.jar
:modules:spring-beans:java14:clean SKIPPED
:modules:spring-beans:java15:clean SKIPPED
:modules:spring-core:java14:clean SKIPPED
:modules:spring-core:java15:clean SKIPPED
:modules:spring-core:java14:compileJava SKIPPED
:modules:spring-core:java14:processResources SKIPPED
:modules:spring-core:java14:classes SKIPPED
:modules:spring-core:java14:jar SKIPPED
:modules:spring-core:java15:compileJava SKIPPED
:modules:spring-core:java15:processResources SKIPPED
:modules:spring-core:java15:classes SKIPPED
:modules:spring-core:java15:jar SKIPPED
:modules:spring-core:moduleJar SKIPPED
:modules:spring-beans:java14:compileJava SKIPPED
:modules:spring-beans:java14:processResources SKIPPED
:modules:spring-beans:java14:classes SKIPPED
:modules:spring-beans:java14:jar SKIPPED
:modules:spring-beans:java14:assemble SKIPPED
:modules:spring-beans:java14:compileTestJava SKIPPED
:modules:spring-beans:java14:processTestResources SKIPPED
:modules:spring-beans:java14:testClasses SKIPPED
:modules:spring-beans:java14:test SKIPPED
:modules:spring-beans:java14:check SKIPPED
:modules:spring-beans:java14:build SKIPPED
:modules:spring-beans:java15:compileJava SKIPPED
:modules:spring-beans:java15:processResources SKIPPED
:modules:spring-beans:java15:classes SKIPPED
:modules:spring-beans:java15:jar SKIPPED
:modules:spring-beans:java15:assemble SKIPPED
:modules:spring-beans:java15:compileTestJava SKIPPED
:modules:spring-beans:java15:processTestResources SKIPPED
:modules:spring-beans:java15:testClasses SKIPPED
:modules:spring-beans:java15:test SKIPPED
:modules:spring-beans:java15:check SKIPPED
:modules:spring-beans:java15:build SKIPPED
:modules:spring-core:java14:assemble SKIPPED
:modules:spring-core:java14:compileTestJava SKIPPED
:modules:spring-core:java14:processTestResources SKIPPED
:modules:spring-core:java14:testClasses SKIPPED
:modules:spring-core:java14:test SKIPPED
:modules:spring-core:java14:check SKIPPED
:modules:spring-core:java14:build SKIPPED
:modules:spring-core:java15:assemble SKIPPED
:modules:spring-core:java15:compileTestJava SKIPPED
:modules:spring-core:java15:processTestResources SKIPPED
:modules:spring-core:java15:testClasses SKIPPED
:modules:spring-core:java15:test SKIPPED
:modules:spring-core:java15:check SKIPPED
:modules:spring-core:java15:build SKIPPED
:modules:spring-beans:moduleJar SKIPPED
:modules:spring-beans:uploadArchives SKIPPED
:modules:spring-core:uploadArchives SKIPPED
:modules:spring-beans:java14:uploadArchives SKIPPED
:modules:spring-beans:java15:uploadArchives SKIPPED
:modules:spring-core:java14:uploadArchives SKIPPED
:modules:spring-core:java15:uploadArchives SKIPPED
BUILD SUCCESSFUL
Total time: 21.156 secs
As you can see the JAR for the java14 project which spring-core
depends on should be modules/spring-core/java14/... but is modules/
spring-beans/java14/...
I've uploaded the project here:
http://drop.io/uck6ryq
Run "gradle clean build upload -m" from the root of the project.
Steven
De : Adam Murdoch <[email protected]>
À : [email protected]
Envoyé le : Lun 19 Octobre 2009, 0 h 20 min 07 s
Objet : Re: [gradle-user] subprojects { } redux
Steven Devijver wrote:
Hey all,
It seems the project delegation situation with the subprojects { }
method is worse than I originally thought. Today I've discovered
that the dependencies { } method is also affected which means you
can't declare proper project dependencies in a multi-project build.
Do you have an example?
Generally, the stuff in dependencies { } is executed immediately,
so will not be affected by the delegate problem.
I've been working on porting spring to gradle for more than a week
now, mostly struggling with weird behavior that I've now all
attributed to the same issue. At this point I have to abandon my
work for now until this issue is fixed.
Here is an (ugly) workaround you can put in your root build script
somewhere. It will change the behaviour of the task action
closures, so that they work correctly when used in a subprojects
{ } closure. You can delete this chunk of code when the issue is
fixed.
subprojects {
afterEvaluate {project ->
project.tasks.each {task ->
task.actions.findAll { it instanceof
ClosureTaskAction }.each {
it.closure.delegate = project
it.closure.resolveStrategy = Closure.DELEGATE_FIRST
}
}
}
}
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
