Thanks, Joche. I am not sure (couldn't get an answer about that from devs), but I think the plugins are loaded before the script can run, that's precisely the problem. And also why editing their content would probably not work, as you say.
Initially I had a question about Groovy and Java, I thought it was a general question, now we're talking about OmegaT and I feel I should be discussing this in the OmegaT's mail list... :) Why not WebStart? The download page says it: The benefit: once launched, future updates of the Web Start version will be installed automatically on your computer. >> Not a benefit for me, I'd like to have control of what version our users have installed and of when we upgrade our users' installations, after we properly test new versions and make sure there aren't major bugs or broken dependencies or that our user guides won't become obsolete. Otherwise it can be a mess to provide support. The drawback: at present, this version cannot be used in conjunction with plug-ins, so not all functions are available. >> Which means the extended functionality I put in my users' machines by means of this script wouldn't be available, and we do rely on it. Thanks for your good help. Have a great evening. Cheers, Manuel Jochen Theodorou <blackd...@gmx.org> escreveu no dia segunda, 7/09/2020 à(s) 20:18: > On 07.09.20 19:23, Manuel Souto Pico wrote: > > Thanks, Jochen. > > > > I'll share this thread (and your comments) with the Java developers that > > work on OmegaT (the application). > > which seems to be open source and the code is available... I located the > plugin loading code, but I think I do not have the energy to go through > that today anymore. > > > To answer your question: the purpose is to update the jar files (if > > there is an update available) before the user actually works on the > > application. > > actually I did see the application support webstart... Why not stay with > that and use OpenWebstart. Disclaimer: my company is a driver behind > OpenWebstart, pleas do not read this as advertisement ;) > > > So the sequence is: > > 1) the user launches the application, > > 2) the script runs on startup (before the user can do anything else) and > > checks whether there's an update > > -- 2.1) if there is one it tries to download it and update the plugins > > 3) after updating the plugins (downloading the new, deleting the old), > > the application shuts down, so that it can pick and use the new version > > of the plugins when it restarts > > If 2 happens before any plugins are loaded it can work. I will have to > have a look at the source for that to know better > > > The update wouldn't really need to happen while the application is > > running, but since the script runs within the application and only the > > application knows where the plugins folder is, that's what happens. > > > > So the idea is to substitute the file (delete old version, put new > > version -- and overwritten the new version, in case the remote plugin > > has been updated but it's name hasn't changed). > > > > I guess in theory the script could also edit/update the content of the > > locale jar file and then rename the file... ? (so the deleting problem > > does not exist.. ) but I don't know how feasible that is tbh. > > it is just a zip file in the end. surely possible to do that. Just it > may not help if classes have been loaded already. Also the version > information must be stored somewhere. > > bye Jochen >
