Hey,
>task.dependsOn project.getConfigurations().getByName("default") // or
other if we use a different config
Above should work, e.g. every configuration is 'Buildable' and
task.dependsOn happily takes Buildables as parameters. If the artifact is
correctly declared in given configuration, it should work for you. What's
the failure/problem you observe with above?
Cheers!
On Sat, Apr 5, 2014 at 1:47 AM, Xavier Ducrohet <x...@google.com> wrote:
> Hello,
>
> I'm trying to optimize the pre-processing we do on the artifacts that
> Android projects use.
>
> Right now each module will pre-process the artifact it uses separately,
> and I'm trying to have all projects share the the result.
>
> During project configuration, we get the all resolved artifacts with
> configuration.resolvedConfiguration.resolvedArtifacts
>
> Then we look at
> configuration.incoming.resolutionResult.root.dependencies
>
> to get the actual dependency graph and map that to the ResolvedArtifact,
> and this allows us to build a tree of custom dependency artifact that we
> can then pre-process.
>
> However this does not really tells us what can build the artifact. Our
> need here is that we want to create a task that will be a requisite for our
> build, that itself will depend on building the artifact and the task action
> will process the artifact in something better for us.
>
> Through some hacks we can figure out what project output the artifact, but
> trying to do any of these fails:
> task.dependsOn project
> task.dependsOn project.getConfigurations().getByName("default") // or
> other if we use a different config
>
> In another area where we collect the local jar files, we look at the
> content of
> configuration.allDependencies
> and I guess I could look to see if they are of type ProjectDependency and
> match the output of resolve() to the file found in the ResolvedArtifact.
> This would allow me to find a matching ProjectDependency, but can I use
> this as a task dependency? (it's not implementing TaskDependency). This
> seems hacky anyway (as if everything we do in there isn't already hacky...)
>
> Am I missing something obvious?
> thanks.
>
--
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
