Notifications

[kelaompachai]

Update client notifications to pull from github Release API

• Added library java-semver-0.10.2.jar for version parsing and comparison.
• Refactored to use streams and added tests
• No longer calls a self-hosted service, so active extensions are no
  longer provided as part of the request.

[jonbartels]

Add .vscode and .project to .gitignore

Thank you for the PR!

[rogin]

I've cleaned up the code and added tests. I've drafted a PR to @kelaompachai 's main.

[kelaompachai]

I rebased to get rid of the out-of-scope commits that had to do with .project, .vscode, .gitignore.

[jonbartels]

Several Java 8 compatibility issues.

[rogin]

I'm out of gas trying to merge correctly. I have java 8 compatible code sitting on this commit. I'd appreciate help, otherwise it's dead on the vine.

[kelaompachai]

I got rogin's java 8 compatible code working on my machine and pushed it up into this pr.

[kelaompachai]

I did have to manually edit the server/.classpath file to get it to work.

[jonbartels]

I did some testing on Saturday.

---

Built from keloampachi main branch. Did not mess with versions or any defaults
No notifications shown; no errors

Correction needed - there are no notifications to show, then do not show the notification popup.

---

---

Manually forcing the version to 3.11 shows

Links are clickable

This test case passed this is the main workflow. GJ!

Improvement requested:
I think the PR should show more data like we see from https://github.com/nextgenhealthcare/connect/releases/tag/4.4.2

Mirth Connect 4.4.2 is a patch release that includes bug fixes and an improvement to exporting messages.
Then the whats new, upgrade, and release links.

Is that data included in the payload returned from git or would it require a second fetch?

---

[kelaompachai]

The most recent commit should address the requested more data improvement.

[jonbartels]

I pushed changes to not show the dialog when there are no notifications

[rogin]

Brainstorming idea on a commit.

Maybe it's over designing, but I noticed the branding branch and refactored the release URL to BrandingConstants which they created. From there, it makes sense for getNotifications to be an interface so others can read versions from a file or other source. So I wrote a default implementation that will process a Github project URL declared at BrandingConstants.RELEASES_URL, and those that read from a file can specify a different class that implements the interface. Since changing the "Accept" header didn't return the crisp data we were hoping for, I omitted it.

[tonygermano]

Brainstorming idea on a commit.

Maybe it's over designing, but I noticed the branding branch and refactored the release URL to BrandingConstants which they created. From there, it makes sense for getNotifications to be an interface so others can read versions from a file or other source. So I wrote a default implementation that will process a Github project URL declared at BrandingConstants.RELEASES_URL, and those that read from a file can specify a different class that implements the interface. Since changing the "Accept" header didn't return the crisp data we were hoping for, I omitted it.

I figured it was out of scope for this PR, but at some point I'd like to make a plugin interface for notification suppliers, and this could become a reference implementation. I know there have been requests in the past for people to be able to create their own notifications to send to their users and may prefer a notification source other than github releases. I didn't want those ideas to slow progress on this PR, which I think does a fine job of filling a short-term need.

[kpalang]

The implementation looks quite impressive and massive kudos to @kelaompachai for building it! But there's one but I'm having a hard time overlooking.
The current approach is very GitHub API-centric. So-much-so that any other server would require substantial rewrite. I feel bad bringing this out at such a late stage of the PR, but there were mentions under #24 of serving notifications via RSS or Atom, which in my opinion would be a more flexible approach to delivering notifications. This way any downstreams would simply have to provide a feed url rather than rewrite the fetching and rendering logic.

Another thing I see little value in is having the notifications version-specific. In my opinion we don't really have that much notifications and info specific to a single version that this more useful than it is complex.

[tonygermano]

I rebased this PR, made some changes, and then squashed it.

• Before rebase: ea04b1e...184e36b
• After rebase with additional commit (resulting changes should be identical to this PR): ea04b1e...8091954
• Just my changes: 8091954

[gibson9583]

LGTM