[
https://issues.apache.org/jira/browse/JAMES-3492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17281056#comment-17281056
]
Benoit Tellier edited comment on JAMES-3492 at 2/8/21, 1:37 PM:
----------------------------------------------------------------
> Maybe we could also try, in another JIRA, to test ES6 with the ES7 driver. If
> we can make it work quickly, it would allow to choose the ES version at
> runtime.
We for sure can try.
However I remember we had compatibility issues with a 6.x driver and a
different version (6.x too) of ElasticSearch server, so I am pessimistic with
the outcome.
> I'm not sure it's a good idea to drop es6 support as soon as we have es7
> support.
> I would really prefer having both implementations.
Sure, we can provide a (deprecated) backport for ES-6 as part of
james-project, and plan a removal one release after.
However, as always, I am concerned about the product cardinality growing
unbound.
We might end up with:
- cassandra-guice-esv6
- cassandra-guice-esv7 -> cassandra-guice
- cassandra-ldap-guice-esv6
- cassandra-ldap-guice-esv7 -> cassandra-ldap-guice
- cassandra-rabbitmq-esv6
- cassandra-rabbitmq-esv7 -> cassandra-rabbitmq-guice
- cassandra-rabbitmq-ldap-esv6
- cassandra-rabbitmq-ldap-esv7 -> cassandra-rabbitmq-ldap
Which do not sounds very viable to me.
I think merging some of these project together do make sense:
- We can provide module choosing to activate LDAP or not
- We can deprecate cassandra-guice without distributed support
Which would let us with these project only to maintain:
- cassandra-rabbitmq-esv6 - deprecated, to be dropped one release after.
- cassandra-rabbitmq-esv7 -> cassandra-rabbitmq-guice - current supproted
product.
> I agree with splitting guice modules some more (it's always a good
> refactoring).
We will start working on it shortly then. See
https://issues.apache.org/jira/browse/JAMES-3499
was (Author: btellier):
> Maybe we could also try, in another JIRA, to test ES6 with the ES7 driver. If
> we can make it work quickly, it would allow to choose the ES version at
> runtime.
We for sure can try.
However I remember we had compatibility issues with a 6.x driver and a
different version (6.x too) of ElasticSearch server, so I am pessimistic with
the outcome.
> I'm not sure it's a good idea to drop es6 support as soon as we have es7
> support.
> I would really prefer having both implementations.
Sure, we can provide a (deprecated) backport for ES-6 as part of
james-project, and plan a removal one release after.
However, as always, I am concerned about the product cardinality growing
unbound.
We might end up with:
- cassandra-guice-esv6
- cassandra-guice-esv7 -> cassandra-guice
- cassandra-ldap-guice-esv6
- cassandra-ldap-guice-esv7 -> cassandra-ldap-guice
- cassandra-rabbitmq-esv6
- cassandra-rabbitmq-esv7 -> cassandra-rabbitmq-guice
- cassandra-rabbitmq-ldap-esv6
- cassandra-rabbitmq-ldap-esv7 -> cassandra-rabbitmq-ldap
Which do not sounds very viable to me.
I think merging some of these project together do make sense:
- We can provide module choosing to activate LDAP or not
- We can deprecate cassandra-guice without distributed support
Which would let us with these project only to maintain:
- cassandra-rabbitmq-esv6 - deprecated, to be dropped one release after.
- cassandra-rabbitmq-esv7 -> cassandra-rabbitmq-guice - current supproted
product.
> I agree with splitting guice modules some more (it's always a good
> refactoring).
We will start working on it shortly then.
> Elasticsearch 6->7 upgrade for guice version
> --------------------------------------------
>
> Key: JAMES-3492
> URL: https://issues.apache.org/jira/browse/JAMES-3492
> Project: James Server
> Issue Type: Improvement
> Reporter: Juhan Aasaru
> Priority: Major
>
> Guice versions use Elasticsearch 6 that has reached end of life.
> We are thinking about starting to work on this issue but first we need to
> estimate the effort required. If anyone has any input on this please add a
> comment. Thanks!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
