hawq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ed Espino <esp...@apache.org>
Subject Re: Layout of LICENSE, NOTICE, and DISCLAIMER files for Apache HAWQ rpm binary release
Date Tue, 06 Jun 2017 07:21:47 GMT

If we cannot resolve the Ranger licensing issues in a reasonable timeframe,
do you feel it would be helpful to provide the HAWQ optional Ranger support
in a subsequent convenience binary release?  The project is learning a
considerable amount on the binary release process. To keep the project
momentum, I feel it will help to complete the HAWQ C/C++ and PXF components
at this point.


-=ed espino

On Mon, Jun 5, 2017 at 7:38 PM, Roman Shaposhnik <roman@shaposhnik.org>

> On Mon, Jun 5, 2017 at 7:48 AM, Ruilong Huo <rhuo@pivotal.io> wrote:
> > Hi Roman,
> >
> > Please let us know if you have a chance to review the java components for
> > pxf and ranger and share with your feedback. Thanks.
> Yes I have. Here's what I found out:
>    1. For PXF all you have to do at this point is to make sure that each
>        files that gets shipped has LICENSE, NOTICE and DISCLAIMER embedded
>        in its META-INF/ folder in the JAR itself. Given that PXF doesn't
> seem
>        to bundle any extra bits -- that should get you clear for JARs
>    2. For Ranger plugin it gets more complicated. I will start by
> making sure that all
>        the JAR/WAR files that are produced by HAWQ itself get the same
> treatment
>        as PXF does in #1. That still won't get you off the hook though
> for RPMs, because
>        it seems that RPMs re-ship a LOT of dependencies. For those
> dependencies I'd
>        recommend having a build script that extracts LICENSE, NOTICE
>        (if any) from all the bundled JARs/WARs (things under
> plugin-service/lib for example)
>        and places them in a special folder within the RPM itself.
> So as long as you do that and make sure that LICENSE, NOTICE and DISCLAIMER
> find their way into all of the RPMs (regardless of whether they
> contain C/C++ binaries
> of JARs/WARs) you should be good for your next release.
> Makes sense?
> Thanks,
> Roman.

*Ed Espino*

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