You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@groovy.apache.org by Keegan Witt <ke...@gmail.com> on 2019/02/11 02:24:16 UTC
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
<https://github.com/groovy/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
<https://sourceforge.net/p/launch4j/bugs/162/>. 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
Posted by Keegan Witt <ke...@gmail.com>.
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 <ke...@gmail.com> 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 <re...@hotmail.com> 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
Posted by Keegan Witt <ke...@gmail.com>.
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 <https://github.com/geb/geb>, Spock
<https://github.com/spockframework/spock>, groovy-wslite
<https://github.com/jwagenleitner/groovy-wslite>, http-builder-ng
<https://github.com/http-builder-ng/http-builder-ng>, Gru
<https://agorapulse.github.io/gru/>, gstorm
<https://github.com/kdabir/gstorm>, dru <https://github.com/agorapulse/dru>,
GroovyServ <https://kobo.github.io/groovyserv/>, Gaiden
<http://kobo.github.io/gaiden/>, shoogr
<https://github.com/aestasit/sshoogr>, 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 <re...@hotmail.com> 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
Posted by Daniel Sun <re...@hotmail.com>.
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
Posted by MG <mg...@arscreat.com>.
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 <paulk@asert.com.au
> <ma...@asert.com.au> 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 <keeganwitt@gmail.com
> <ma...@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
> <https://github.com/groovy/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
> <https://sourceforge.net/p/launch4j/bugs/162/>. 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
Posted by Keegan Witt <ke...@gmail.com>.
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 <paulk@asert.com.au 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 <ke...@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
>> <https://github.com/groovy/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
>> <https://sourceforge.net/p/launch4j/bugs/162/>. 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
Posted by Paul King <pa...@asert.com.au>.
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 <ke...@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
> <https://github.com/groovy/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
> <https://sourceforge.net/p/launch4j/bugs/162/>. 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
Posted by Merlin Beedell <MB...@cryoserver.com>.
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 <ke...@gmail.com>
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<https://github.com/groovy/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<https://sourceforge.net/p/launch4j/bugs/162/>. My question is, do many folks need this functionality? It's something I've never personally used. Please weigh in with your thoughts.
-Keegan