metron-api-0.3.1.jar, metron-common-0.3.1.jar, htrace-core-3.1.0-incubating.jar define 756 overlapping classes:
[WARNING] - org.apache.htrace.fasterxml.jackson.databind.introspect.BasicBeanDescription [WARNING] - org.apache.htrace.fasterxml.jackson.databind.KeyDeserializer$None [WARNING] - org.apache.htrace.fasterxml.jackson.databind.PropertyNamingStrategy$LowerCaseWithUnderscoresStrategy [WARNING] - org.apache.htrace.fasterxml.jackson.databind.deser.DataFormatReaders [WARNING] - org.apache.htrace.fasterxml.jackson.databind.deser.std.EnumDeserializer [WARNING] - org.apache.htrace.fasterxml.jackson.databind.node.NumericNode [WARNING] - org.apache.htrace.fasterxml.jackson.databind.deser.std.PrimitiveArrayDeserializers$ShortDeser [WARNING] - org.apache.htrace.fasterxml.jackson.core.JsonPointer [WARNING] - org.apache.htrace.TraceInfo [WARNING] - org.apache.htrace.fasterxml.jackson.databind.introspect.VisibilityChecker [WARNING] - 746 more... this stuff takes a lot of time during the build. and it is for every module. On February 27, 2017 at 14:38:53, Casey Stella (ceste...@gmail.com) wrote: Metron-common is shaded so that we can use a more recent version of guava which some of our functionality relies upon but does not play nice with the version brought in with HBase (by relocating gauva). I, personally, believe that we should - Reduce our dependence on guava until we no longer need it in commons - Distribute some of the functionality in comments to smaller, more targeted modules - Remove the shading and relocating from commons - Make the proper exclusions on the leaf projects so that we do not have overlaps in dependencies across jars. Casey On Mon, Feb 27, 2017 at 2:31 PM, Otto Fowler <ottobackwa...@gmail.com> wrote: > Is there a reason why we shade ALL of the jars? For example - > metron-common is shaded. But it is never ‘deployed’ to storm or yarn or mr > as a stand alone… > > I would think that only the ‘outward’ facing libs would be shaded. >
