Edit on 6: I think I misread this originally. Actually the file association thing doesn't apply in this case, that's an issue with the shortcuts. The issue I think is that before we were including groovy.exe (the native binaries) and now we're not, we're just providing batch and VB script files. When executed from inside cmd.exe, invoking just "groovy" works fine, since the shell is able to do the interpretation from groovy to groovy.bat. But this doesn't work from inside Java because it doesn't have the shell to do any interpretation. While this is related to the file association issue (in that the issue exists because there are no binaries), it is a use case I had not considered. For what I tend to do, I just wanted to be able to click Groovy Console in the start menu and not have an annoying cmd.exe window pop open, so a VB script was sufficient for that. It's feeling like I'm going to have to re-introduce some kind of binary wrapper.
-Keegan On Tue, Sep 29, 2020 at 2:33 AM Keegan Witt <keeganw...@gmail.com> wrote: > 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> > 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’ 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> >> *Sent:* 23 July 2020 12:51 PM >> *To:* users@groovy.apache.org; Paul King <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> a écrit : >> >> Nice! >> >> >> >> On Thu, Jul 23, 2020 at 3:07 PM Keegan Witt <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 >> >>
