incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Taylor <jamestay...@apache.org>
Subject Re: [VOTE] Release of Apache Phoenix 3.0.0 incubating RC1
Date Wed, 26 Mar 2014 00:45:15 GMT
On Tue, Mar 25, 2014 at 5:35 PM, Andrew Purtell <apurtell@apache.org> wrote:

> On Tue, Mar 25, 2014 at 4:25 PM, sebb <sebbaz@gmail.com> wrote:
>
> > > Yes, we bundle ANTLR in our binary distribution. Most of the other
> items
> > > are pulled in based on the transitive dependencies of other jars we've
> > > bundled in our binary distribution.
> >
> > I see now why I did not notice the 3rd party binaries.
> > They seem to have been merged into jars which look like phoenix code -
> > and indeed also contain phoenix code.
> >
> > That is a very non-standard way to do things, and I think could
> > mislead end-users as to the provenance of the code.
> >
> > It's OK to bundle separate jars in a binary release (assuming
> > licensing etc is OK), but I don't think it's OK to merge 3rd party
> > code with ASF code in a single jar.
> > Apart from anything, that will play havoc with Maven and possibly
> > other dependency management systems.
>
>
> I believe this is done because Phoenix is a JDBC client, and JDBC drivers
> are usually packaged as single JARs for convenience. James could confirm or
> refute. I concluded this is acceptable practice having seen it elsewhere at
> Apache, for example in Apache Pig, their convenience fatjar artifact.
>
> Yes, that's correct. It's because then a third-party tool (such as a SQL
client GUI) then only need to pull in a single jar to be able to connect
through the Phoenix JDBC driver to HBase. Our initial (pre-Apache) releases
didn't do this and it was almost impossible to get the classpath correct
for the "minimal" client-side dependencies.

So the remaining question: should we spin up a new RC for these changes and
if so, should we go through a vote again on our dev list as well?

Thanks again for all the help.

James

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