Alternative emoji set support

[julman99]

What

Adds support to have alternative emoji sets. The set must be selected when starting up the app via a system property. Two system properties are supported:

com.vdurmont.emoji.EmojiManager.SET

Defines which emoji set should be loaded. This is an enum that accepts any of the following values:

• EMOJI_JAVA: the default emoji set
• UNICODEY: the emoji set from https://unicodey.com/emoji-data/table.htm
• CUSTOM: a custom emoji set that will be passed in a file

com.vdurmont.emoji.EmojiManager.PATH

A string containing the path of the cutom emoji set.

In addition, a script was added to import the json from unicodey and convert it to the same format as emoji-java, so the EmojiLoader remains unchanged

Why

Many projects (including Slack) use the data from unicodey and this change allows to interop propertly with emoji-java

[coveralls]

Coverage decreased (-0.8%) to 92.442% when pulling ae71e61af670a58dfd93a5d012ce893b8242b28e on julman99:unicodey into 8cf5fbe0d7c1020b926791f2b342a263ed07bb0f on vdurmont:master.

[coveralls]

Coverage decreased (-0.8%) to 92.442% when pulling ae71e61af670a58dfd93a5d012ce893b8242b28e on julman99:unicodey into 8cf5fbe0d7c1020b926791f2b342a263ed07bb0f on vdurmont:master.

[vdurmont]

Looks great! I think it's interesting to import different emoji sets.

I have some questions:

• Do you know what's the difference between our current DB and the unicodey one? Maybe we can just update ours to match unicodey's.
• The PATH and SET variables are a good way to define custom databases. I'm wondering if we should have several emoji-java artefacts, one for each set. It's less efficient but much easier for the end user. emoji-java-common could have all the common stuff, emoji-java-unicodey could require the common artefact and add the unicodey DB, ... What do you think?

[julman99]

• I don't know all the differences, but I do know about some ambiguities, for example :hug: is :hugging_face: in Slack, and :thinking: is :thinking_face: So the real issue is not that this library is missing emojis, is that there are conflicts between the emoji aliases: we could encode :hug: when the decoder is expecting :hugging_face:. Maybe one option is to always support decoding from all emoji sets but have the developer pick one of the sets as the preferred encoding?

• I like the artifact approach, I agree is a much more intuitive way of using the right emoji set, as well as extensible. I will do the change tomorrow to "see how it feels", ok?

[julman99]

Hi @vdurmont, just pushed a set of commits to split the project into a multi-module structure. There is still some cleanup that needs to be done, but I wanted to get your early feedback. From a third party developer point of view, there are two artifacts they can use: emoji-java and emoji-java-unicodey. The only thing those modules do is to include a different emojis.json as resource

The table generator now accepts a maven property at execution time called emoji-java-artifact that allows to switch the included module for emoji-java

My personal opinion is that it feels better for a developer to use the library. To make the releases easier I suggest we include the maven-release-plugin since it helps maintaining the version numbers across all modules

[coveralls]

Coverage decreased (-0.8%) to 92.442% when pulling d8c5f626ee5ed32cd9090a27ca1fc58d5cdd3b4e on julman99:unicodey into 8cf5fbe0d7c1020b926791f2b342a263ed07bb0f on vdurmont:master.

[julman99]

Hi @vdurmont , just checking if you had time to review the approach I committed. I still need to cleanup many things from the first implementation but I want to get your feedback before I keep working on the PR

Thanks

[ethansinjin]

Hey, I'm very interested in getting support for Slack emoji done. My team is using this library on Android but a different one on iOS, which is leading to discrepancies between emoji parsing across platforms 🙁

Please let me know if there's anything I can help out with on this or #41!

[vdurmont]

Hey I'm sorry I didn't take the time to look into this before. I didn't look into the DB from unicodey but is it possible to update the DB we already have to also support unicodey's aliases instead of selecting a different set?