[Issue 75] Solve commons-codec conflict on Android

Android runtime includes Apache Commons Codec version 1.3, but we need features from version 1.6.  When methods from 1.6 are invoked that are not available in 1.3, you get NoSuchMethodError's at runtime.

To avoid the conflict on Android, we use jarjar to include private of Apache Commons Codec.  We now provide a proxy classes com.google.api.client.util.Base64 and StringUtils to invoke the private version of Base64 and StringUtils from commons-codec version 1.6.

[aiuto, 2012-03-19 02:28:28]

do you need this for appengine too? We should only include the repacked when we
absolutely have to, so people can link against things they can control

http://codereview.appspot.com/5844050/diff/1/google-http-client-android2/pom.xml
File google-http-client-android2/pom.xml (right):

http://codereview.appspot.com/5844050/diff/1/google-http-client-android2/pom....
google-http-client-android2/pom.xml:52:
<pattern>org.apache.commons.codec.**</pattern>
This seems double wasteful. It would be good if we could reused the repackged
copy from http-client. That way we'll only end up with 2 copies of the codec lib
rather than 3. I stil like the idea of encapsulating the few rtoutines you need
as some utility methods in http-client and letting everyone else get at them
through those methods.

http://codereview.appspot.com/5844050/diff/1/google-http-client/pom.xml
File google-http-client/pom.xml (right):

http://codereview.appspot.com/5844050/diff/1/google-http-client/pom.xml#newco...
google-http-client/pom.xml:84: <groupId>org.sonatype.plugins</groupId>
since this stuff is magic, maybe some comments in the pom file explaining why we
do this are needed.

In any event we need to explain this sort of thing in the top level readme, so
that someone building with things other than maven understands the android
problem.

[yanivi, 2012-03-20 15:01:04]

http://codereview.appspot.com/5844050/diff/1/google-http-client-android2/pom.xml
File google-http-client-android2/pom.xml (right):

http://codereview.appspot.com/5844050/diff/1/google-http-client-android2/pom....
google-http-client-android2/pom.xml:52:
<pattern>org.apache.commons.codec.**</pattern>
On 2012/03/19 02:28:28, aiuto wrote:
> This seems double wasteful. It would be good if we could reused the repackged
> copy from http-client. That way we'll only end up with 2 copies of the codec
lib
> rather than 3. I stil like the idea of encapsulating the few rtoutines you
need
> as some utility methods in http-client and letting everyone else get at them
> through those methods.

Done.

http://codereview.appspot.com/5844050/diff/1/google-http-client/pom.xml
File google-http-client/pom.xml (right):

http://codereview.appspot.com/5844050/diff/1/google-http-client/pom.xml#newco...
google-http-client/pom.xml:84: <groupId>org.sonatype.plugins</groupId>
On 2012/03/19 02:28:28, aiuto wrote:
> since this stuff is magic, maybe some comments in the pom file explaining why
we
> do this are needed.
> 
> In any event we need to explain this sort of thing in the top level readme, so
> that someone building with things other than maven understands the android
> problem.

Done.

[aiuto, 2012-03-20 16:15:15]

http://codereview.appspot.com/5844050/diff/13/google-http-client/src/main/jav...
File
google-http-client/src/main/java/com/google/api/client/util/Base64Codec.java
(right):

http://codereview.appspot.com/5844050/diff/13/google-http-client/src/main/jav...
google-http-client/src/main/java/com/google/api/client/util/Base64Codec.java:32:
public class Base64Codec {
Could this have been named Base64 rather than Base64Codec.
That would have minimized the changes to the rest of the source tree.
Same for StringUtil -> Strings.

[yanivi, 2012-03-20 16:53:36]

http://codereview.appspot.com/5844050/diff/13/google-http-client/src/main/jav...
File
google-http-client/src/main/java/com/google/api/client/util/Base64Codec.java
(right):

http://codereview.appspot.com/5844050/diff/13/google-http-client/src/main/jav...
google-http-client/src/main/java/com/google/api/client/util/Base64Codec.java:32:
public class Base64Codec {
On 2012/03/20 16:15:15, aiuto wrote:
> Could this have been named Base64 rather than Base64Codec.
> That would have minimized the changes to the rest of the source tree.
> Same for StringUtil -> Strings.

Done.

[aiuto, 2012-03-20 18:17:06]

lgtm

[yanivi, 2012-03-20 18:57:02]

On 2012/03/20 18:17:06, aiuto wrote:
> lgtm

Thanks for the feedback Tony!  I will submit this as soon as the other two
interdependent changesets are lgtm'ed:
http://codereview.appspot.com/5846074/
http://codereview.appspot.com/5848069/