Handling of optional maven dependencies?

[eapache]

cc @carsonb @boourns

I am trying to build a project that uses square's retrofit library. The first issue I ran into was #503 but that is easy to work around by specifying all recursive dependencies in the primary build.gradle file. My build.gradle now looks like:

  plugins {
      id 'java'
      id 'com.github.j2objccontrib.j2objcgradle' version '0.5.0-alpha'
  }

  dependencies {
      testCompile 'junit:junit:4.12'
      compile 'com.google.code.gson:gson:2.3.1'
      compile 'com.squareup.okhttp:okhttp:2.5.0'
      compile 'com.squareup.okio:okio:1.6.0'
      compile 'com.squareup.retrofit:retrofit:2.0.0-beta2'
      compile 'com.squareup.retrofit:converter-gson:2.0.0-beta2'
  }

  j2objcConfig {
      autoConfigureDeps true
      xcodeProjectDir '../iOS'
      xcodeTargetsIos 'Foo'
      finalConfigure()
  }

This almost works. However, retrofit has an optional dependency on the android libraries (see https://github.com/square/retrofit/blob/d26484c7a8fa5e648d9aa476b493c94f9c242bf7/retrofit/pom.xml#L22-L26) and so when I run the j2objc build process it fails with:

  error: retrofit/Platform.java:18: The import android.os.Build cannot be resolved
  error: retrofit/Platform.java:19: The import android.os.Handler cannot be resolved
  error: retrofit/Platform.java:20: The import android.os.Looper cannot be resolved

I find it odd that the code in question (https://github.com/square/retrofit/blob/d26484c7a8fa5e648d9aa476b493c94f9c242bf7/retrofit/src/main/java/retrofit/Platform.java#L18-L20) is doing an unguarded import of an optional dependency, but perhaps that is how maven does things? Is this something that needs to be supported by j2objc-gradle, or something I need to manually configure my way around?

Thanks,
Evan

[brunobowden]

@JakeWharton - we'd appreciate your help in supporting the Retrofit library on iOS. This is being done by using Google's J2ObjC tool for translating Java to Objective-C. @eapache is working on this. At issue is that the pom.xml has an optional dependency for using android.os.(Build|Handler|Helper):

<dependency>
  <groupId>com.google.android</groupId>
  <artifactId>android</artifactId>
  <optional>true</optional>
</dependency>

The question is how to build the library without Android? Furthemore what needs replacing if anything?

@eapache - have a look at sourcepath ordering: #340. That may well address this issue by allowing you to specify a class that replaces Platform.java, providing an alternative iOS specific implementation. @advayDev1 has used this feature, though I'm not sure what the state of the plugin it.

Other than that, enumerating the dependencies is a smart workaround for now. I also like the #L22-L26 trick for highlighting... that was new to me.

[brunobowden]

Once this is working, we'd like to support it in the continuous build: j2objc-contrib/j2objc-common-libs-e2e-test#7

[eapache]

I've been playing around with things in a simpler way by just temporarily vendoring and editing the retrofit source until it compiles. If I strip out the android and java-7/8 code in Platform.java (and make similar edits to Okio) then I can get it building, however I run into more complex issues with retrofit's use of reflection.

Specifically, https://github.com/square/retrofit/blob/62b2290fea162850942477638bd500b1db670e12/retrofit/src/main/java/retrofit/Utils.java#L184-L186 fails in objc (but not in java) because the Call<Foo> java type gets converted into a non-parametrized Call interface in objc. I suppose the thing to do would be to file a j2objc ticket against the reflection package?

[brunobowden]

Please go ahead and file the issue. Bonus points for a minimal test case. You'll find the J2ObjC team to be pretty responsive.

[ScottPierce]

Any updates on this? I see the issue filed with j2objc has been closed with a resolution. I'd be very interested in using retrofit with j2objc.

[eapache]

We changed directions and stopped working on this at our end, but as far as I know now that the j2objc ticket is fixed all you have to do for it to build is strip out the optional android/java-8 code in Platform.java.

[ScottPierce]

Out of curiosity, what was the reason you guys went a different direction?

[eapache]

The amount of code we actually ended up sharing between the two platforms ended up a lot smaller than we'd originally thought, so it was easier to just write it twice.