Automatic dependency resolution.

[advayDev1]

Dependency configuration happens in 2 phases:
- Dependency conversion:
  This converts your compile and testCompile dependencies into
  equivalent j2objcTranslate and j2objcLink dependencies.  Namely
  local jars are copied to j2objcTranslate, external Maven jars are
  converted into their 'sources' form and copied to j2objcTranslate,
  and projects are copied to j2objcLink (they don't need translation).

  This phase is optional and controlled by j2objcConfig.autoConfigureDeps

- Dependency resolution:
  This phase converts j2objcTranslate and j2objcLink deps into
  actual j2objc commands.  Any source jar on j2objcTranslate is
  added to translateSourcepaths with --build-closure.  Any project
  on j2objcLink is added to translateClasspaths and has its final
  j2objc static library linked in to this project's objective c code.

  This phase always runs.  If your dependencies are too complicated
  for the plugin to figure out in the first phase, keep autoConfigureDeps=false,
  and just add the appropriate projets, jars, and libraries here.

Also adds system tests for both project and external Maven dependencies.

#180; Fixes #41; Fixes #372

TESTED=yes

[advayDev1]

@brunobowden - please do #411 first; this relies heavily on it.

#180; Fixes #41; Fixes #372

@ph1lb4 @roisagiv - please take a look. this should automatically handle the simple kinds of dependencies you've pointed out.

While the system tests do exercise the functionality, unfortunately my own project has internal native code dependencies which I haven't automated yet (I assume I am in the minority), so I cannot test this on a complicated project. So any of you trying this out would be quite helpful.

If you add autoConfigureDeps = true to j2objcConfig in shared build.gradle, and remove the extra stuff you added manually, it should work. Please let me know if it does not.

The one thing I know this cannot handle yet is #419.

[advayDev1]

I will write a separate PR for updating all our docs. I think 1-hop dependencies on a third-party JAR is one of the last things we needed to simplify to get people working quickly out-of-the-box.

[advayDev1]

@brunobowden - ptal; remerged/rebased. Note that all the dependency tests are in multiProject as adding a full new system test for auto deps vs. manual deps costs us a lot in terms of runtime on Travis.

I think in the end we will have 3 system tests: simple, multiProject (for all kinds of dependencies), and exhaustive (which stresses every feature we have).

[brunobowden]

Should dependencies be split out to their own doc? It feels like that's becoming a substantial section unto itself.

[advayDev1]

in my next PR, i hope to make dependencies a much shorter doc :)
it should be much simpler once this goes in.

[advayDev1]

ptal @brunobowden - should be good to go

[advayDev1]

if you run ./gradlew extended:dependencies from multiProject1

j2objcLinkage - J2ObjC dependencies that need to be linked into the final library, and do not need translation
\--- project :base
     \--- com.google.guava:guava:17.0

j2objcTranslation - J2ObjC dependencies that need to be transitively translated via --build-closure
\--- com.google.code.gson:gson:2.3.1

[brunobowden]

Add note:

// These configurations are groups of artifacts and dependencies for the plugin build
// https://docs.gradle.org/current/dsl/org.gradle.api.artifacts.Configuration.html

[advayDev1]

done. i don't see the need to link to uniquely identifiable JavaDoc (or similar though). we could do that for any gradle api...

[brunobowden]

This is something more unusual and special. I'm thinking of my own ignorance as I was reading your code. If I need to look something up, then it's highly likely that someone else will need the same. If something seems straight forward to me, then I don't bother asking to add a reference. So it's a qualitative judgement that I agree should be limited.

[brunobowden]

Also, should this have a separate compile and testCompile configurations?

[advayDev1]

No, see my reply to you earlier. There is no way to distinguish right now.

[brunobowden]

LGTM - great work on this. Delighted to see this up and working.

[advayDev1]

Now I just want to see at least one person using it successfully ;)

[advayDev1]

Aside @brunobowden ;
if we solve #419 and #425, I think the vast majority of our users' use-cases will be automatically configured. #425 is easy. #419 requires writing a 2nd plugin (within our plugin bundle)