I think we have reached consensus about moving these modules into a
separate repo.
I filed PHOENIX-5062 and PHOENIX-5063.
On Tue, Dec 4, 2018 at 5:20 PM Alex Araujo wrote:
> > If we really want, I bet we could get rid of most of the code we have
> for PQS already and just push it into Avatica
> If we really want, I bet we could get rid of most of the code we have
for PQS already and just push it into Avatica itself. Just a thought ;)
+1. Even willing to volunteer myself here.
On Tue, Dec 4, 2018 at 5:18 PM Josh Elser wrote:
> That makes the most sense to me.
>
> If we really want,
That makes the most sense to me.
If we really want, I bet we could get rid of most of the code we have
for PQS already and just push it into Avatica itself. Just a thought ;)
There are some other users of Avatica, but we are, far and away, the
most prevalent.
On 12/4/18 8:10 PM, Thomas
Should we have one repo for the connectors (phoenix-flume, phoenix-hive,
phoenix-kafka, phoenix-pig and phoenix-spark)
and a separate repo for the queryserver?
On Tue, Dec 4, 2018 at 3:58 PM Vincent Poon wrote:
> +1 to another repo for connectors
>
> On Mon, Dec 3, 2018 at 6:27 PM James Taylor
+1 to another repo for connectors
On Mon, Dec 3, 2018 at 6:27 PM James Taylor wrote:
> +1. Good idea, Thomas.
>
> On Mon, Dec 3, 2018 at 2:57 PM Thomas D'Silva
> wrote:
>
> > I believe we will be maintaining the 4.x branches which support HBase
> 1.2,
> > 1.3 and 1.4 for a while.
> > Should we
+1. Good idea, Thomas.
On Mon, Dec 3, 2018 at 2:57 PM Thomas D'Silva
wrote:
> I believe we will be maintaining the 4.x branches which support HBase 1.2,
> 1.3 and 1.4 for a while.
> Should we think about pulling out the connectors and queryserver into their
> own repo similar to
> what HBase
I believe we will be maintaining the 4.x branches which support HBase 1.2,
1.3 and 1.4 for a while.
Should we think about pulling out the connectors and queryserver into their
own repo similar to
what HBase did (see https://issues.apache.org/jira/browse/HBASE-20934).
They could then have
their own
Well I don't count with a lot more 4.x releases - maybe I'm wrong-headed .
For master branch and cdh6 we'd be looking at spark 2.x
Part of the success of a project is about version stability. Not a lot of
corporate projects can afford keep upgrading to the latest versions - think
about it, you're
+1
> 在 2018年12月1日，02:56，Thomas D'Silva 写道：
>
> We could allow individual submodules like the queryserver, or phoenix-spark
> to be built with their own compiler configuration (1.8+).
> This would allow these modules to use Java 1.8 features. I think this would
> be a good compromise given that
Spark 1.6 is really old and doesn't support the newer Datasource v2 api
that we have been looking at integrating with.
As Alex points out you will might end up having to revert a lot more
commits in the future.
Seems like the queryserver and phoenix-spark modules on the cdh branch
would end up
> Only a downgrade to spark 1.6 (
changes are only needed in a few IT, basically going back from Datasets to
Dataframes) and going back to Avatica 1.10 ( involving reverting
PHOENIX-4755, PHOENIX-4750 and PHOENIX-4805 ).
We're talking about the 4.x branches, right? Doesn't seem prudent to do it
Thinking about typical server installation in a corporate environment I'd
keep everything compatible with the same JVM version.
I've gone down the route for the cdh branch. Full JDK 7 compatibility
doesn't require changes in phoenix-core. Only a downgrade to spark 1.6 (
changes are only needed in
We could allow individual submodules like the queryserver, or phoenix-spark
to be built with their own compiler configuration (1.8+).
This would allow these modules to use Java 1.8 features. I think this would
be a good compromise given that they depend on
features that are provided by versions of
I'd vote for keep using java7 on 4.x branches. if upgrades to java8, it
will impact users who want to upgrade the latest 4.x branches. they must
consider using java8 in their running environments, maybe their libraries
do not support java8, then they have to give up to upgrade. So I think that
I'd vote for keep compiling 4.x branches in java7. It makes sense as it's
just a new minor release.
It's pretty easy reverting back to spark 1.6 and also avatica dependency
could be reverted to the previous version.
On 29 Nov 2018 21:41, "Thomas D'Silva" wrote:
We have traditionally followed
We have traditionally followed HBase's java support (see
https://hbase.apache.org/book.html#basic.prerequisites). The
phoenix-queryserver module has a dependency on Avatica which does not
support Java 1.7. The phoenix-spark module depends on spark 2.3.2 which
also does not support Java 1.7. Do
16 matches
Mail list logo
