Split errors jar into client and server jars #122

Activity

1. iamdanfox commented on Sep 12, 2018

   

   iamdanfox

   on Sep 12, 2018

   Contributor

   More actions

   This seems nice from a conceptual perspective, but for the http-remoting -> conjure-java-runtime migration, I don't think it's quite sufficient as the unwanted jars could end up on your compile classpath transitively from a variety of different places.

   The current least-worst option I can think of is to add a gradle/ban-remoting-api.gradle file, with the following contents:

   // Apply this snippet to all your java projects to ensure you don't have redundant 'catch' blocks
   // for the old `com.palantir.remoting.api.errors.RemoteException` class.
   // Old remoting-api jars are still allowed at runtime.
   
   configurations.compileClasspath {
       resolutionStrategy.eachDependency { DependencyResolveDetails details ->
           if (details.requested.group == 'com.palantir.remoting-api' && details.requested.name == 'errors') {
               details.useTarget group: 'com.palantir.conjure.java.api', name: 'errors', version: dependencyRecommendations.getRecommendedVersion('com.palantir.conjure.java.api', 'errors')
               details.because 'Should not compile against RemoteExceptions from both http-remoting-api and conjure-java-runtime-api.'
           }
       }
   }

   This ensures that when you're migrating from http-remoting-api to conjure-java-runtime, your codebase is guaranteed not to catch the old exception anymore (com.palantir.remoting.api.errors.RemoteException), but the jars will still be present at runtime (which is important for other users)