Keegan, Thanks very much for that reply. I can’t really comment on the 32/64 bit debate. I just think that apps installed in ProgFiles32 are ‘old’ – which I am sure that Groovy would not wish to be thought to be. Just read your recent update: I now understand the “groovy …”.execute() thing better, I may evolve my scripts to use the Script Engine and move away from returning exit statuses. But nevertheless, there may be a case to include an ‘option’ in the installer for binary wrappers.
As for the scriptom thing – I guess it does not need to evolve as the Windows COM objects have equally not changed for many years. But COM enabled things very much still exist and will probably continue to do so for a good while longer – but a time appears to be coming when Windows becomes a side project to Linux (as seen from the WSL efforts). And I think that Office Automation tooling is shifting to newer APIs and web services (like OAuth and ‘Graph’). So if there was a simple way to download and install Jacob/scriptom as a separate thing, that might help for the few that still use it! Merlin Beedell From: Keegan Witt <keeganw...@gmail.com> Sent: 29 September 2020 7:33 AM To: users@groovy.apache.org Subject: Re: 3.0.x Windows installers released 1. That's correct. There were a few discussions about why I thought we should do this. Here's a short summary: Most of the modules included you can just use @grab for anyway, the few others where that wouldn't apply (GroovyServ, Grengine) seemed low usage. Scriptom was the only other one in this category that I've heard folks actually use. But multiple of the installed extras hadn't been updated in years (and some never will). It's been 10 1/2 years since the last Scriptom release. I know Scriptom is specific to Windows, but I also thought it'd be good to be somewhat consistent with the environment provided between platforms, which would help folks writing scripts targeting different platforms have some consistency. 2. I opened a PR to update the installer links (https://github.com/apache/groovy-website/pull/25). 3. Yes, as noted in the 3.0 announcement email, when the WiX version replaced the NSIS version (when 3.0 first released), the NSIS version should be uninstalled before installing the new version. 4. There are no native binaries included anymore, so there's nothing x86 or x64 specific about it. One of the things I didn't like about how the old installer worked is it would detect your current Java (from JAVA_HOME if I recall correctly) and those would be the binaries copied over. But this seemed a fragile way to do it to me, since you might have several JDKs installed, and on different architectures. There also wasn't really any reason to have 64 bit binaries in my view, since they're just wrappers for calling java.exe and will never need so much memory that they'd benefit from being 64 bit. 5. This kept the installer logic simple. I'm not sure the best practice about the installation directory when the thing being installed is platform independent. I think I should be able to use the variable for the 64 bit program files directory if available, if you think that'd be better. It seemed somewhat an arbitrary choice. 6. (the question about .bat) I think this is related to the known issue with needing vbs files to have the appropriate file association (https://github.com/groovy/groovy-wix/issues/2). I've been trying to find a better solution for this, without needing to have something as heavy-weight as the native binaries we used to use, which have logic about JAVA_HOME, etc. I haven't found a better solution yet, I may have to revive the native binaries (or do something similar). I've documented my investigations in that issue. I also mention there how you can check and fix your file associations there. 7. (the question about execute) I don't quite understand this question. The "execute" thing you're showing is a feature of the JDK. GroovyScriptEngine is included in Groovy and there's no reason you shouldn't be able to use this instead if you wish. A bit of a discussion for the dev mailing list I suppose, but what do we consider the official position on Scriptom? Should it be considered deprecated? We copied the stuff over from Codehaus after the shutdown, but it hasn't been touched since (and I think hadn't been touched in a while even before the move). If it's something we want to continue to support, I think we need to do some updates, like updating to the latest Jacob. Some questions I'd have if it were to be revived (bearing in mind I'm not really familiar with these features): 1. Should we drop the Office modules? Or if not, we might need to update for newer Office versions. 2. Should the IE6 module be dropped? IE6 is pretty dead at this point. I'm willing to reconsider the decision on including Scriptom, but not until we have a clear position on its maintenance status. I'd also want to clarify whether, given its age, there were any security concerns about including such old binaries (though probably we wouldn't want to just toss in the old binaries anyway). -Keegan On Mon, Sep 28, 2020 at 12:05 PM Merlin Beedell <mbeed...@cryoserver.com<mailto:mbeed...@cryoserver.com>> wrote: Hi Groovy magic workers, I notice that the Windows Installer has changed quite a lot recently. It is nice and quick and the UI is simple. However: things I note in this release: 1. The supplementary extras (e.g. Jacob / scriptom) are not included at all, not even as a custom install. Not sure how to include these separately, other than to copy-paste from an older release. [I use scriptom to query the Windows Services list to start/stop/query various services]. 2. The Windows 3.0.4 installer and 3.0.5 releases are not yet on the ‘groovy-lang.org<http://groovy-lang.org>’ download site. 3. My Environment PATH variable appears to have 2 entries pointing to the new groovy home. Perhaps it edits the previous entry and then adds the new one as well. 4. It does not supply separate 64-bit executables that can be exchanged with the 32-bit executables, which might relate to the next item… 5. It defaults the install under program files (x86) – suggesting a 32-bit implementation only. Only the ‘custom’ option allows it to be put somewhere else. I then noticed that if I execute this in groovysh or in the groovyConsole: “groovy -v”.execute().waitForProcessOutput(System.out, System.err) Exception thrown java.io.IOException: Cannot run program "groovy": CreateProcess error=2, The system cannot find the file specified at ConsoleScript5.run(ConsoleScript5:1) Caused by: java.io.IOException: CreateProcess error=2, The system cannot find the file specified But this works “groovy.bat -v”.execute().waitForProcessOutput(System.out, System.err) Groovy Version: 3.0.3 JVM: 1.8.0_162 Vendor: Oracle Corporation OS: Windows 10 Does this suggest that the installed groovy is 32-bit when my computer and JDK are both 64-bit? My older groovy installs (going back to 2.0.4) would all work. PS – Why call groovy using “execute” rather than GroovyScriptEngine? Well some of these called scripts use System.exit (error-number) and if I use the ScriptEngine or similar, it causes my script to exit as well! Merlin Beedell 0800 280 0525 / +44 (0)207 045 0520 DDI: +44 (0)207 045 0528 Mob: +44 (0)7876 226865 Cryoserver: A focused, flexible email archive delivered by experts From: Guillaume Laforge <glafo...@gmail.com<mailto:glafo...@gmail.com>> Sent: 23 July 2020 12:51 PM To: users@groovy.apache.org<mailto:users@groovy.apache.org>; Paul King <pa...@asert.com.au<mailto:pa...@asert.com.au>> Subject: Re: [ANNOUNCE] Groovy 2.4.20, 2.5.13, and 3.0.5 Windows installers released Combo! Le jeu. 23 juil. 2020 à 12:13, Paul King <pa...@asert.com.au<mailto:pa...@asert.com.au>> a écrit : Nice! On Thu, Jul 23, 2020 at 3:07 PM Keegan Witt <keeganw...@gmail.com<mailto:keeganw...@gmail.com>> wrote: 2.4.20: https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.4.20.msi 2.5.13: https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.5.13.msi 3.0.5: https://bintray.com/groovy/Distributions/download_file?file_path=groovy-3.0.5.msi -Keegan
