hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Dimiduk <ndimi...@gmail.com>
Subject Re: Is our maven build order correct? Do we have required jars in binary/source tar.gz?
Date Thu, 26 Oct 2017 03:17:03 GMT
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 <stack@duboce.net> wrote:

> On Wed, Oct 25, 2017 at 3:03 PM, Sean Busbey <busbey@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?
>
>
>
> > 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" <appy@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message