Github user pferrel commented on the issue:
https://github.com/apache/incubator-predictionio/pull/336
This may be ok to stage to the feature/es5 branch but IMO should not be
merged with master for release yet.
The technique of linking and creating an assembly with both es1 and es5 is
IMO not ideal. The reasoning is that ES refactored es-hadoop-mr and es-spark at
some time between the 2 so if you pull them into a Template (the UR does this)
you get duplicate classes. It is not clear yet how to solve this but it is
highly unlikely that if we had 2 PIO build profiles, one for ES1 and one for
ES5 as well as 2 for any template using the ES Spark integration, this would go
away and would be cleaner.
Another reason to do this is that the pio-env.sh would be simplified to
only configure ELASTICSEARCH, not different named stores.
Most of this is fine and though it would require a non-trivial change to
the UR, I think this is doable and would commit to supporting it if the above
issues can be solved. So to summarize I suggest we:
1) create the equivalent of a Maven build profile for ES5 and leave the
default ES1 for now with a warning that ES5 will be the default in some future
release.
2) leave pio-env.sh with only the ES config for whatever version is
installed with the name ELASTICSEARCH. If the scheme needs to be there for both
that's ok with me.
This will make any Template that uses ES directly just work with ES1 and
the default build and it will leave the Template work to move to ES5 using the
new build profile for PIO with ES5.
If this pushes the ES5 build profile to 0.12.0, I personally am ok with
that. I it delay 0.11.0 I'm also ok with that.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
