IMHO, you go to the bin.tgz for a runnable executable. Everything else (archetypes, client jars, sources) is pulled down from Maven Central through dev tooling. I don't see a strong need for ops to receive the latter in the bin.tgz. The only use I can think of is ignoring someone wants to automate a complex mirror situation based on the content of a single download. That's a bit of a stretch.
That said, maybe the Foundation mandates the completeness of a binary convenience release? On Wed, Oct 25, 2017 at 7:14 PM Stack <[email protected]> wrote: > On Wed, Oct 25, 2017 at 3:03 PM, Sean Busbey <[email protected]> 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? > > > > > The source tarball isn't made by a module, despite the descriptor living > in > > the hbase-assembly module. It could just as easily be in dev-support. The > > step of our release process that creates the source tarball does a manual > > invocation of the maven assembly plug-in and points at the source > > descriptor directly. > > > > > Our build could do w/ a revamp. It still has a form from when we used emit > multiple products, src and a bin tarball for hadoop1 and hadoop2. > > St.Ack > > > > > > On Oct 25, 2017 4:57 PM, "Apekshit Sharma" <[email protected]> wrote: > > > > Hi folks, > > > > Found some discrepancies in moduleSet <include> list in src.xml and > > hadoop-two-compat.xml. Got a crash course on hbase-assembly today by > stack. > > Throwing some larger questions here; > > > > 1. Do we want h-archetypes in binary tar? > > 2. Shouldn't we be building h-shaded, h-examples and h-archetypes before > > h-assembly so that the corresponding jars get included in source/binary > > tar? Here's the current build order : > > > > .... > > Apache HBase - Archetypes .......................... SUCCESS [ 0.006 s] > > Apache HBase - Assembly ............................ SUCCESS [ 0.281 s] > > Apache HBase - Shaded .............................. SUCCESS [ 0.006 s] > > Apache HBase - Shaded - Client ..................... SUCCESS [ 0.010 s] > > Apache HBase - Shaded - MapReduce .................. SUCCESS [ 0.011 s] > > Apache HBase Shaded Packaging Invariants ........... SUCCESS [ 0.007 s] > > Apache HBase - Exemplar for hbase-client archetype . SUCCESS [ 0.096 s] > > Apache HBase - Exemplar for hbase-shaded-client archetype SUCCESS [ > 0.095 > > s] > > Apache HBase - Archetype builder ................... SUCCESS [ 0.008 s] > > > > > > -- Appy > > >
