Check in protobuf java code and generate lite jar.

third_party/protobuf/README.chromium

Index: third_party/protobuf/README.chromium
diff --git a/third_party/protobuf/README.chromium b/third_party/protobuf/README.chromium
index 3b861c86c59302ffc69b7925eb789a87e0524e9e..3987736a4e28cf5c4e13c1fe3530e7483d6fa563 100644
--- a/third_party/protobuf/README.chromium
+++ b/third_party/protobuf/README.chromium
@@ -12,6 +12,12 @@ README.chromium
 config.h
 descriptor2_pb.py
 
+The Java lite version of the library has been checked in directly under
+javalib/protobuf-java-2.4.1-lite.jar. It should be updated whenever a
+new version of protobuf is rolled. It can be built by following the
+instructions in svn/trunk/java/README.txt.
+Note: Remember to use the lite profile with "mvn install -P lite".

[Nico, 2012/10/30 04:26:55]

This makes it a lot harder to roll protobuf.

[nyquist, 2012/10/30 04:50:32]

Agreed. Sadly, the protobuf library has external dependencies such as JUnit and
EasyMock. Those are test-tools though, so we might be able to do without them.

If we check in the Java source we would have to keep the gyp/ant version of the
build up to date based on updates from the maven pom.xml.

[Philippe, 2012/10/30 08:59:28]

I'm also concerned about making Protobuf rolls harder.

I think we could only have the JAR files of the dependencies  which should not
change too often (junit, easymock and others if needed) and trigger the Maven
build of the Protobuf Java sources (using these JARs) from protobuf.gyp. In
protobuf.gyp we would have a first step doing a 'mvn install' for each
dependency JAR.

On the downside, this means that Maven would be required for a Chromium for
Android build (I think that's reasonable).
We might want to check it into the tree too or better pull it through DEPS (on
Android only) if possible.

What do you think?

+
 A protobuf.gyp file has been added for building with Chromium.
 
 This code has been patched to support unknown field retention in protobuf-lite.