Re: Groovy file associations on Windows

[Keegan Witt]

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  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  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

Re: Groovy file associations on Windows

[Keegan Witt]

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  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
>

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

Re: Groovy file associations on Windows

[MG]

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  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 mailto:keeganw...@gmail.com>> 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

RE: Groovy file associations on Windows

[Merlin Beedell]

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('.')



<



/* 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 
Sent: 11 February 2019 2:24 AM
To: users@groovy.apache.org
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

Re: Groovy file associations on Windows

[Keegan Witt]

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  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  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
>>
>

Re: Groovy file associations on Windows

[Paul King]

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  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
>