[macOS] Problem releasing designer on macOS

[davetcc]

Since the Notarization process for macOS has changed it the tcMenuDesigner package is not being accepted any longer due to a strange error, without enough details to help me determine what is wrong. Further, all their documentation (which I have now spent a day reading) is not helpful for this error.

I will have no choice to but raise a support case with Apple at our cost. I will update here as the ticket is created, and then picked up.

[davetcc]

Ticket raised with Apple.

[davetcc]

Chased Apple again as no response so far. I am not bumping the library versions yet to make 4.2 the latest.

[davetcc]

Apple has responded and is now looking into it.

[davetcc]

OK had a response from Apple and this is most likely a problem in jpackager - maybe it has always been there and Apple have hardend the notarization rules slightly, it seems jpackager rewrites some of the license files after the initial process has completed. There are two options here that I am thinking over for a few hours before moving forward:

1. just fix it for us, IE sign everything manually and submit, its quick and will get tcMenu moving again, but until someone fixes it, the process becomes very manual.
2. check out the jpackager code and debug it, maybe won't take too much longer, and then I can submit a bug request with a potential fix once I get a bit further along.

[davetcc]

The problem is now fully identified after a lot of work, no amount of additional signing can fix the issue without significant work. The issue is listed here: xerial/sqlite-jdbc#383 and doesn't look like there is any available fix. The problem started after we added SQLite, and this makes sense now.

Given we only store very limited state in the database, I think we'd be better off moving to a full Java-based database solution of which there are a few as, 1. they are much smaller at ~2 MB, 2. they will not hit this binary signing issue.

I'm now actively investigating HQLDB and Derby, I'll make a decision shortly on which is likely to work longer term and move to that. It does mean that everyone has a one-off transition cost but I think that is unavoidable right now.

[davetcc]

I now have a prototype running on HQLDB (pure Java and very small) without the SQLite native dependency. Also, I'm making the code rely on the database even less than before.

[davetcc]

See #450

[davetcc]

Problem solved, releasing soon.