You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@metron.apache.org by Otto Fowler <ot...@gmail.com> on 2017/02/27 19:31:41 UTC
question about shading
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.
Re: question about shading
Posted by Otto Fowler <ot...@gmail.com>.
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 (cestella@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 <ot...@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.
>
Re: question about shading
Posted by Casey Stella <ce...@gmail.com>.
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 <ot...@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.
>