> > Yes I do use project(path: ":path:to:project", configuration: "conf") when >> I have a custom config and this works. To be clear, the general dependency >> works. It used to be that this particular task would get the whole consumer >> project's config.buildDependencies as a task dependency and this did work >> (calling the task would make sure all the consumed projects would get >> builds). Now I'm trying to only put a dependency on the project that builds >> this artifact and it's just not working at the task level. >> > > What I've ended up doing as a temp workaround is depend on the task name > (because i can compute it), so my task will now depend on > ":consumedProject:assembleFoo" and this works. >
Oh I think I understand it now. So you don't want all build dependencies of given target configuration but rather depend on a specific artifact. Another option is to have a specific configuration for specific artifact (then, 'archives' configuration could extend those individual configurations and group all artifacts together). Depending on task by name/path, provided that it's based on well established naming convention is a fine approach at the moment. I'd say that it's the most idiomatic approach currently. The idea of project dependencies that refer to specific artifact rather than specific configuration is change in the model that Adam would need to asses. Gut feel tells me it's unlikely the team accepts this approach. I'd say that the new publication model that we are chipping away with every release should handle this case in some way. For example, it should be easier and more lightweight to configure a publication with a single artifact (publications are detangled from configurations). I'm not deeply involved in new publication model currently but I'm positive that this case would be handled far more gracefully in future :) Hope that helps! -- Szczepan Faber Principal engineer@gradle; Founder@mockito Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA: http://www.gradlesummit.com
