subprojects { } redux
|
View:
New views
10 Messages
—
Rating Filter:
Alert me
|
 |
subprojects { } redux
by Steven Devijver-3
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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. 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. It's safe to say that multi-project builds are effectively impossible with gradle at this time. Steven |
|
|
Re: subprojects { } redux
by Steve Ebersole
::
Rate this Message:
|
|
|
Re: subprojects { } redux
by Russel Winder-4
::
Rate this Message:
Steven,
On Sat, 2009-10-17 at 21:47 +0000, 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. > 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. It's safe to say that multi-project > builds are effectively impossible with gradle at this time. Sorry to hear that Gradle is not working for your situation. Hopefully Hans and Adam can address your needs quickly and effectively. When you say "multi-project builds are effectively impossible with gradle at this time." This is clearly not true. You are over-generalizing from you situation. Multi-project builds are working fine for me, doing what I need. At least at the moment. > -- Russel. ============================================================================= Dr Russel Winder Partner xmpp: russel@... Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 voip: sip:russel.winder@... London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder |
|
|
Re: subprojects { } redux
by hdockter
::
Rate this Message:
|
|
|
Re: subprojects { } redux
by Adam Murdoch-2
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Steven Devijver wrote:
Do you have an example? Generally, the stuff in dependencies { } is executed immediately, so will not be affected by the delegate problem.
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 |
|
|
Re : [gradle-user] subprojects { } redux
by Steven Devijver-3
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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: Run "gradle clean build upload -m" from the root of the project. Steven De : Adam Murdoch <a@...> À : user@... Envoyé le : Lun 19 Octobre 2009, 0 h 20 min 07 s Objet : Re: [gradle-user] subprojects { } redux Steven Devijver wrote:
Do you have an example? Generally, the stuff in dependencies { } is executed immediately, so will not be affected by the delegate problem.
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 |
|
|
Re: Re : [gradle-user] subprojects { } redux
by Adam Murdoch-2
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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. I've added: http://jira.codehaus.org/browse/GRADLE-718 Steven Devijver wrote:
-- Adam Murdoch Gradle Developer http://www.gradle.org |
|
|
Re: Re : [gradle-user] subprojects { } redux
by hdockter
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
On Oct 24, 2009, at 10:59 PM, Adam Murdoch wrote:
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 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
|
|
|
Re: Re : [gradle-user] subprojects { } redux
by hdockter
::
Rate this Message:
|
|
|
Re : [gradle-user] Re : [gradle-user] subprojects { } redux
by Steven Devijver-3
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hey Hans, Thanks very much, works like a charm! Steven De : Hans Dockter <mail@...> À : user@... Envoyé le : Lun 26 Octobre 2009, 12 h 57 min 28 s Objet : Re: [gradle-user] Re : [gradle-user] subprojects { } redux Hi Steven, this issue is fixed in
trunk. I now get the following output for your build (without having done any changes to your build.gradle's): For spring-beans: /Users/hans/tmp/spring-framework-2.5.6.SEC01/modules/spring-beans/java14/build/libs/java14-2.5.6.SEC01.jar Project for dependencies: spring-core :modules:spring-core:java14 For spring-core: /Users/hans/tmp/spring-framework-2.5.6.SEC01/modules/spring-core/java14/build/libs/java14-2.5.6.SEC01.jar Just remember to give unique group:name:version ids when you want to publish to a Maven repo. - Hans -- Hans Dockter Gradle Project Manager On Oct 20, 2009, at 5:03 PM, Steven Devijver
wrote:
|
signature.asc (204 bytes) | Free embeddable forum powered by Nabble | Forum Help |
