Groovy file associations on Windows

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

Groovy file associations on Windows

keeganwitt
In addition to removing projects that are no longer developed from the Groovy Windows installer (Gpars, Gaelyk, Scriptom, EasyB, Gant, GMock), I'm considering removing the exe files from groovy-native-launcher.  These haven't been compiled in quite a while and are just another thing to maintain.  As I see it, there are two primary benefits these provide.
  1. Provide a way to create file associations so you can double click a Groovy file, or run myFile.groovy instead of groovy myFile.groovy.
  2. Hide the command window when launching GroovyConsole.
For #2, I can work around this with a VBScript file (or NirCmd).  #1 doesn't have a good way to solve other than the current native binary solution since Launch4J doesn't support variable expansion.  My question is, do many folks need this functionality?  It's something I've never personally used.  Please weigh in with your thoughts.

-Keegan
Reply | Threaded
Open this post in threaded view
|

Re: Groovy file associations on Windows

paulk_asert
I'd be inclined to keep GPars in the mix for now. It isn't actively maintained but is still very useful in its current form and I hope to put some time into it at some stage.

Cheers, Paul.


On Mon, Feb 11, 2019 at 12:24 PM Keegan Witt <[hidden email]> wrote:
In addition to removing projects that are no longer developed from the Groovy Windows installer (Gpars, Gaelyk, Scriptom, EasyB, Gant, GMock), I'm considering removing the exe files from groovy-native-launcher.  These haven't been compiled in quite a while and are just another thing to maintain.  As I see it, there are two primary benefits these provide.
  1. Provide a way to create file associations so you can double click a Groovy file, or run myFile.groovy instead of groovy myFile.groovy.
  2. Hide the command window when launching GroovyConsole.
For #2, I can work around this with a VBScript file (or NirCmd).  #1 doesn't have a good way to solve other than the current native binary solution since Launch4J doesn't support variable expansion.  My question is, do many folks need this functionality?  It's something I've never personally used.  Please weigh in with your thoughts.

-Keegan
Reply | Threaded
Open this post in threaded view
|

Re: Groovy file associations on Windows

keeganwitt
Do folks using it really need it to be in the lib directory with all the other jars? Or could they just use Grapes/Grab?

If it's truly helpful, I can keep it.  I'm just wondering if it's overkill.

On Mon, Feb 11, 2019, 2:19 AM Paul King <[hidden email] wrote:
I'd be inclined to keep GPars in the mix for now. It isn't actively maintained but is still very useful in its current form and I hope to put some time into it at some stage.

Cheers, Paul.


On Mon, Feb 11, 2019 at 12:24 PM Keegan Witt <[hidden email]> wrote:
In addition to removing projects that are no longer developed from the Groovy Windows installer (Gpars, Gaelyk, Scriptom, EasyB, Gant, GMock), I'm considering removing the exe files from groovy-native-launcher.  These haven't been compiled in quite a while and are just another thing to maintain.  As I see it, there are two primary benefits these provide.
  1. Provide a way to create file associations so you can double click a Groovy file, or run myFile.groovy instead of groovy myFile.groovy.
  2. Hide the command window when launching GroovyConsole.
For #2, I can work around this with a VBScript file (or NirCmd).  #1 doesn't have a good way to solve other than the current native binary solution since Launch4J doesn't support variable expansion.  My question is, do many folks need this functionality?  It's something I've never personally used.  Please weigh in with your thoughts.

-Keegan
Reply | Threaded
Open this post in threaded view
|

RE: Groovy file associations on Windows

Merlin Beedell
In reply to this post by keeganwitt

I use Scriptom – for registering and managing Windows Services (mostly).  I believe that MS are moving away from the COM model – but I am sure it will be around for a while yet.  As such it will not change much – and hence the ScriptOM utility is unlikely to need changing either.

 

Here is an example:

 

org.codehaus.groovy.scriptom.Scriptom.inApartment {

    def locator = new org.codehaus.groovy.scriptom.ActiveXObject('WbemScripting.SWbemLocator')

    def services = locator.ConnectServer('.')

 

<<blaa blaa other stuff!!>

 

    /* a test to list all cryo services with their dependencies */

    if (testOnly) {

        for(process in services.ExecQuery("SELECT Name FROM Win32_Service where (displayname like 'cryo%') and StartMode != 'Disabled'", 'WQL', wbemFlagForwardOnly)) {

          println process.Name()

          for (depServ in services.ExecQuery("Associators of {Win32_Service.Name='" + process.Name() + "'} Where AssocClass=Win32_DependentService Role=Dependent")) {

                println  "\tDep: ${depServ.DisplayName} state: ${depServ.State}"

          }

          for (depServ in services.ExecQuery("Associators of {Win32_Service.Name='" + process.Name() + "'} Where AssocClass=Win32_DependentService Role=Antecedent")) {

                println  "\tAsc: ${depServ.DisplayName} state: ${depServ.State}"

          }

        }

    }

}

 

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: Keegan Witt <[hidden email]>
Sent: 11 February 2019 2:24 AM
To: [hidden email]
Subject: Groovy file associations on Windows

 

In addition to removing projects that are no longer developed from the Groovy Windows installer (Gpars, Gaelyk, Scriptom, EasyB, Gant, GMock), I'm considering removing the exe files from groovy-native-launcher.  These haven't been compiled in quite a while and are just another thing to maintain.  As I see it, there are two primary benefits these provide.

  1. Provide a way to create file associations so you can double click a Groovy file, or run myFile.groovy instead of groovy myFile.groovy.
  2. Hide the command window when launching GroovyConsole.

For #2, I can work around this with a VBScript file (or NirCmd).  #1 doesn't have a good way to solve other than the current native binary solution since Launch4J doesn't support variable expansion.  My question is, do many folks need this functionality?  It's something I've never personally used.  Please weigh in with your thoughts.

 

-Keegan

MG
Reply | Threaded
Open this post in threaded view
|

Re: Groovy file associations on Windows

MG
In reply to this post by keeganwitt
Just a general reminder: Not every company using Groovy has unrestricted internet access... :-)
Cheers,
mg

On 11/02/2019 14:11, Keegan Witt wrote:
Do folks using it really need it to be in the lib directory with all the other jars? Or could they just use Grapes/Grab?

If it's truly helpful, I can keep it.  I'm just wondering if it's overkill.

On Mon, Feb 11, 2019, 2:19 AM Paul King <[hidden email] wrote:
I'd be inclined to keep GPars in the mix for now. It isn't actively maintained but is still very useful in its current form and I hope to put some time into it at some stage.

Cheers, Paul.


On Mon, Feb 11, 2019 at 12:24 PM Keegan Witt <[hidden email]> wrote:
In addition to removing projects that are no longer developed from the Groovy Windows installer (Gpars, Gaelyk, Scriptom, EasyB, Gant, GMock), I'm considering removing the exe files from groovy-native-launcher.  These haven't been compiled in quite a while and are just another thing to maintain.  As I see it, there are two primary benefits these provide.
  1. Provide a way to create file associations so you can double click a Groovy file, or run myFile.groovy instead of groovy myFile.groovy.
  2. Hide the command window when launching GroovyConsole.
For #2, I can work around this with a VBScript file (or NirCmd).  #1 doesn't have a good way to solve other than the current native binary solution since Launch4J doesn't support variable expansion.  My question is, do many folks need this functionality?  It's something I've never personally used.  Please weigh in with your thoughts.

-Keegan

Reply | Threaded
Open this post in threaded view
|

Re: Groovy file associations on Windows

Daniel Sun
Yep. e.g. banks usually does not allow employees access Internet. Luckily
some of them will setup maven server.

Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
Reply | Threaded
Open this post in threaded view
|

Re: Groovy file associations on Windows

keeganwitt
I hear you.  But where do you draw the line?

There are a lot of popular libraries we also could include besides Gpars and Scriptom (e.g. Geb, Spock, groovy-wslite, http-builder-ng, Gru, gstorm, dru, GroovyServ, Gaiden, shoogr, etc) -- and those are just some ones with commits in the last year that aren't for building or hosting web stuff.  There are many more besides this.  And because it's just a bundle including whatever the latest versions were at the time of a Groovy release for a specific selection of projects (and not a project like sdkman), there's no way to mix & match versions or upgrade independent of a Groovy release.
Although I guess if we want the installer to include a bunch of different library options, maybe we could have the installer fetch the requested jars from the internet, I suppose.  Though I'm not sure how the file GUIDs would work if we did that.  MSIs I've seen that do that (like have .NET Framework as a dependency) usually invoke a separate MSI for each dependency.

-Keegan


On Tue, Feb 12, 2019 at 2:13 AM Daniel Sun <[hidden email]> wrote:
Yep. e.g. banks usually does not allow employees access Internet. Luckily
some of them will setup maven server.

Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
Reply | Threaded
Open this post in threaded view
|

Re: Groovy file associations on Windows

keeganwitt
Actually, for Gpars, that's in the Groovy binary zip, so that's
included already.

On Sun, Feb 17, 2019 at 6:42 PM Keegan Witt <[hidden email]> wrote:

>
> I hear you.  But where do you draw the line?
>
> There are a lot of popular libraries we also could include besides Gpars and Scriptom (e.g. Geb, Spock, groovy-wslite, http-builder-ng, Gru, gstorm, dru, GroovyServ, Gaiden, shoogr, etc) -- and those are just some ones with commits in the last year that aren't for building or hosting web stuff.  There are many more besides this.  And because it's just a bundle including whatever the latest versions were at the time of a Groovy release for a specific selection of projects (and not a project like sdkman), there's no way to mix & match versions or upgrade independent of a Groovy release.
> Although I guess if we want the installer to include a bunch of different library options, maybe we could have the installer fetch the requested jars from the internet, I suppose.  Though I'm not sure how the file GUIDs would work if we did that.  MSIs I've seen that do that (like have .NET Framework as a dependency) usually invoke a separate MSI for each dependency.
>
> -Keegan
>
>
> On Tue, Feb 12, 2019 at 2:13 AM Daniel Sun <[hidden email]> wrote:
>>
>> Yep. e.g. banks usually does not allow employees access Internet. Luckily
>> some of them will setup maven server.
>>
>> Cheers,
>> Daniel.Sun
>>
>>
>>
>>
>> --
>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html