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 <realblue...@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 >
