3.0.x Windows installers released

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

3.0.x Windows installers released

Merlin Beedell

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 <[hidden email]>
Sent: 23 July 2020 12:51 PM
To: [hidden email]; Paul King <[hidden email]>
Subject: Re: [ANNOUNCE] Groovy 2.4.20, 2.5.13, and 3.0.5 Windows installers released

 

Combo!

 

Reply | Threaded
Open this post in threaded view
|

Re: 3.0.x Windows installers released

keegan
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 <[hidden email]> 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 <[hidden email]>
Sent: 23 July 2020 12:51 PM
To: [hidden email]; Paul King <[hidden email]>
Subject: Re: [ANNOUNCE] Groovy 2.4.20, 2.5.13, and 3.0.5 Windows installers released

 

Combo!

 

Reply | Threaded
Open this post in threaded view
|

Re: 3.0.x Windows installers released

keegan
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
Sent: 23 July 2020 12:51 PM
To: [hidden email]; Paul King <[hidden email]>
Subject: Re: [ANNOUNCE] Groovy 2.4.20, 2.5.13, and 3.0.5 Windows installers released

 

Combo!

 

Reply | Threaded
Open this post in threaded view
|

RE: 3.0.x Windows installers released

Merlin Beedell
In reply to this post by keegan

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 <[hidden email]>
Sent: 29 September 2020 7:33 AM
To: [hidden email]
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 <[hidden email]> 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 <[hidden email]>
Sent: 23 July 2020 12:51 PM
To: [hidden email]; Paul King <[hidden email]>
Subject: Re: [ANNOUNCE] Groovy 2.4.20, 2.5.13, and 3.0.5 Windows installers released

 

Combo!

 

Reply | Threaded
Open this post in threaded view
|

Re: 3.0.x Windows installers released

paulk_asert
Administrator
In reply to this post by Merlin Beedell


On Tue, Sep 29, 2020 at 2:05 AM Merlin Beedell <[hidden email]> 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.
The official download page is:

https://groovy.apache.org/download.html

Which has the links. We didn't delete the old page yet though and I will merge Keegan's PR. We should probably just forward requests instead of having to update two pages all the time.

Cheers, Paul.

 
  1. 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.
  2. It does not supply separate 64-bit executables that can be exchanged with the 32-bit executables, which might relate to the next item…
  3. 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 <[hidden email]>
Sent: 23 July 2020 12:51 PM
To: [hidden email]; Paul King <[hidden email]>
Subject: Re: [ANNOUNCE] Groovy 2.4.20, 2.5.13, and 3.0.5 Windows installers released

 

Combo!

 


Virus-free. www.avast.com