#Adam: Thank you for pointing to the transitive flag, which was a big miss on my part as the client module with transitivity was what I aimed at... I know about that, but lost sight during trying many things. There are more to it, however, see my below answer to Rene.
Those improvements in incoming gradle sounds great! Can you give some rough estimate how much work remained for 0.9 and next version after it? For me it is a bit hard to follow and keep in mind those subtle variations among possible dependency syntaxes/notations which can be very different in their meaning. #Rene: That's a magic! Can you explain how it does that? I have already got to Ivy documentations looking for info as to how these string are supposed to be constructed, but could not yet find the answer. Now, most of my dependencies gets resolved except the groovy one which gives: http://our.www.server/librepo/groovy/1.6-RC-1/groovy.jar The jar should contain the revision however: groovy-all-1.6-RC-1.jar Is it possible at all to mix client module transitive dependencies where some may contain revision in the artifact name and some are not? If I remember well, in an other type of dependency gradle makes efforts to find artifact with both versioned and unversioned forms. If not possible, then the only way to go repo has to contain revisioned jars, right? Both of yours help are very much appreciated! Zsolt -- View this message in context: http://old.nabble.com/How-to-define-custom-remote-repo-for-client-dependency--tp27255683p27270308.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
