Closed terjedahl closed 7 years ago
We have discussed this and find it problematic to add a dependency on JUnique. We also have different views on whether the launcher should be in charge of the app mutex, or if this is an application issue.
I'm leaning towards including app mutex functionality in the launcher, but it has to be a clean room implementation, based on sockets. Would you be willing to investigate the possibility to write something like this from scratch?
I agree that it would be cleaner to have a built-inn solution, rather than one based on JUnique. Yes, I would like to write a clean room socket-based implementation from scratch. No problem. Looking forwards to it. Will start next week.
Perfect! Thank you Terje, this will be a very nice addition to the launcher!
As we have agreed that @terjedahl will make a built in solution not based on JUnique, I am closing this PR
I apologize for notifying you sooner: I have not yet had a chance to do this. It would certainly be fun to do, but as my current solution is working satisfactorily for me, it has not been a priority. I dare not give an estimate of when I will have a new solution in place.
No rush Terje :) Thanks for getting back to us :)
Added new parameter 'mutex' - both in manifest and as adhoc (which overrides manifest). By specifying a mutex-parameter (string), a per-user single-instance lock is acquired, ensuring only a single instance is run (per user). An empty string is synonymous with no-mutex, allowing for override adhoc ('--mutex='). Functionality is implemented with JUnique. JUnique is (at present) served from GitHub. JUnique is packaged into the JAR. pom.xml has been updated accordingly. Code is commented. Readme is updated.