We don't do both at once because the maven assembly plugin isn't very good at making source tarballs. There's lots of ways for things to go wrong and give us bad artifacts. most recent example, our 2.0.0-alpha3 release is ~100MiB because it includes shaded jars because prior commands matter.
Personally, I'd rather update our release process to just use git archive to create source tarballs off of RC tags. For example, you can do this to make a source tarball from the 2.0.0-alpha-3 RC tag: git archive --format=tar.gz --output=/path/to/rc/artifacts/hbase-2.0.0-alpha-3.tar.gz --prefix=hbase-2.0.0-alpha-3/ 2.0.0-alpha-3RC0.2 nice and simple. doesn't need a assembly descriptor; says right in the command which tag the source will correspond to. In fact, I think I'll do this for the next 1.2 release. On Wed, Oct 25, 2017 at 6:27 PM, Apekshit Sharma <a...@cloudera.com> wrote: > Any reason why we don't build both together? > > On Wed, Oct 25, 2017 at 3:17 PM, Apekshit Sharma <a...@cloudera.com> wrote: > >> Thanks for the quick reply Busbey. Let me work on fixing the includes list >> (HBASE-19089 <https://issues.apache.org/jira/browse/HBASE-19089>). Will >> come back here if more questions arise. >> >> --Appy >> >> 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. >>> >>> 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. >>> >>> On Oct 25, 2017 4:57 PM, "Apekshit Sharma" <a...@cloudera.com> 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 >>> >> >> >> >> -- >> >> -- Appy >> > > > > -- > > -- Appy
