Well, basically, I edited
org.gradle.api.internal.project.TopLevelBuildServiceRegistry, and added my
dependency resolver to the set passed to DefaultDependencyFactory, created
in createDependencyFactory(). And then my resolver looks like this:

@Override
public <T extends Dependency> T createDependency(Class<T> type, Object
notation)
      throws IllegalDependencyNotation {
   if ((notation == null) || !(notation instanceof Map)) {
      throw new IllegalDependencyNotation("The XYZ dependency resolver
doesn't " +
                                          "know how to handle this notation:
" + notation);
   }
   return type.cast(createDependencyFromMap((Map&lt;String,
String&gt;)notation));
}

private AbstractModuleDependency createDependencyFromMap(Map&lt;String,
String&gt; notation) {
   if (needToExtractArtifactFromRepository(notation)) {
      String group = OUR_INTERNAL_GROUP_NAME;
      String name = getName(notation);
      String version = getVersion(notation);
      return new DefaultExternalModuleDependency(group, name, version);
   } else {
      // do something specific to our use case
   }
}


By the way, ModuleDependencyFactory needs to be fixed. At the moment, if I
have a "non-standard" dependency declaration like:

  compile param1: 'A', param2: 'B'

and if DefaultDependencyFactory happens to call ModuleDependencyFactory
before it calls my custom dependency resolver (the resolvers are stored in a
hash set, so the iteration order is undefined), then ModuleDependencyFactory
will try to create a DefaultExternalModuleDependency with a null name and
that will throw an exception. Instead, it should check if it has all
parameters it needs, and if it doesn't, it should throw a
InvalidDependencyNotation exception, to allow other resolvers to try to
parse the notation.


--
View this message in context: 
http://gradle.1045684.n5.nabble.com/Multi-project-build-dynamically-add-subprojects-dependencies-tp4824341p4830972.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


Reply via email to