Adam Murdoch wrote: > > replace external dependencies that refer to projects in the same build > with actual project dependencies. > I previously tried the/ replace way/, but (most probably for my inexperience with gradle) something went wrong. While adapting your snippet for gradle-1.0-milestone-3, I noticed the external dependency is never actually removed, hence leading to unresolved deps. So given a multiproject including prj1 and prj2, with prj2 having an external dependency on the main artifact of prj1, if I launch following script from prj2
I get this output I guess /config.dependencies/ returns some sort of detached view, hence removal instruction has no effects cause it does not operates on actual dependencies structure (if you assign it to a variable you can see that it is a LinkedHashSet instance, and it actually removes the element). Adam Murdoch wrote: > > This is definitely a use case I want to tackle soon after Gradle 1.0 is > available. We'd start probably with a plugin that packages up the above > logic. You'd apply the plugin and provide us with some mapping from > external dependency to target project directory. We'd then improve the > plugin over time > ... > There's lot of interesting stuff we can do in this space. > That's great news!!! I wonder if IDE plugin developers could eventually benefit from API extensions for such mapping... Thank you very much Cheers Davide -- View this message in context: http://gradle.1045684.n5.nabble.com/Is-it-possible-to-elect-a-local-gradle-project-to-satisfy-other-projects-deps-tp4497854p4781773.html Sent from the gradle-user mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
