On Sep 21, 2010, at 10:07 AM, Doug Cutting wrote: > On 09/20/2010 08:53 PM, Scott Carey wrote: >> For avro-core, the libraries of interest are Paranamer and Jackson. >> Paranamer only adds up to 35K; Jackson is a bit larger at 500K but is >> absolutely critical for Avro. Jackson-core is only 150K however -- >> it might be possible to drop jackson-mapper. > > That's an interesting feature and could be useful. > > I think it only works when we don't expose shaded classes as a part of > our public APIs. We currently do expose Jackson in a few places: > Schema#Field has a constructor that accepts a JsonNode as a > representation of the default value; and JsonEncoder has a constructor > that accepts a JsonGenerator as output. The former could probably be > easily fixed, but the latter might be harder to replace without losing > potentially useful end-user functionality.
Good point, we definitely have to entirely encapsulate such a dependency. This might be possible with Jackson with some work or some wrappers. There are two kinds of shading -- one that remaps the packages so that collisions won't happen, and another that just makes uber-jars and encapsulates. The latter can be used if we expose features in our API, at the risk of colliding. Thats probably not worth it though; the benefit to us is encapsulation and preventing collisions. > > I'd be much more comfortable with shading if we had automated tests that > checked that shaded classes are not referenced in our public APIs. > Hmm, I wonder if there is a good tool for that out there. Something that shows the packages that your public facing APIs expose. The shade plugin has another interesting feature: multiple artifacts. We could have avro-core.jar and avro-core-shaded.jar. The > Tatu (Jackson's primary developer) has expressed remorse that 1.0.1 has > incompatibilities with subsequent 1.x releases. So, instead of > defensive, we could be optimistic, and hope that that this won't occur > again in any Jackson 1.x releases. > > Paranamer is only required for reflection-based RPC. It's classes do > not appear in any public Avro APIs. The paranamer jar itself is small, > but its transitive dependencies are large, I think. > Paranamer has no transitive dependencies. Paranamer-ant does, but I think that is a false runtime dependency of ours. In my maven-build experiment I removed it and all tests pass. The build uses the Paranamer Maven plugin to decorate test classes just like the ant tasks in the build. The code only has Paranamer in its classpath and not paranamer-ant and works. I don't fully understand the RPC use case however -- when at runtime does it have access to parameter names (source code) to decorate the classes? >> Paranamer is BSD, and Jackson is Apache. I'm not sure of the >> implications of repackaging these into Avro. > > We could include these in Avro without legal issues. > > Doug Thats good to hear.
