On Wed, Oct 25, 2017 at 9:14 PM, Stack <st...@duboce.net> wrote: > On Wed, Oct 25, 2017 at 3:03 PM, Sean Busbey <bus...@apache.org> wrote: > >> Thus far, the shaded jars and the archetypes have only been aimed at >> consumption during downstream build processes. Namely folks using maven to >> build an app. >> >> For those users, only being published in the Apache Nexus repo matters, so >> we deployed there (via the deploy step of our release process with release >> and apache-release maven profiles). We have not, thus far, included those >> jars in our binary tarball. Thus they aren't listed as dependencies of the >> assembly module and get built after it. >> >> Adding them would nearly double our binary tarball size, so I'm inclined to >> not include them without a compelling use case. >> >> > Interesting. I'd have said our bin should have all our built product but > yeah, as you say, archetypes depends on maven context and would make no > sense in bin tgz. > > If we want to evangelize shaded client as primary access point, would that > be justification bundling it in bin tgz? > >
okay so here's a use case. our return from `hbase classpath` is a nightmare. if you're a downstream user that just wants "hey hbase give me jars I need to run against you right now." it's garbage. we could include the shaded jars and return the shaded client for something like `hbase classpath-client`. Same with replacing `hbase mapredcp` current output with the shaded mapreduce jar.
