be
>> conventient at some point in the future in my work environment (also no
>> internet access)):
>>
>> This solution proposed by Keith does not work
>> https://github.com/gradle/gradle-groovy-all
>> ?
>>
>> Cheers,
>> mg
>>
>>
>
On Wed, 19 Dec 2018 at 22:46, MG wrote:
>
> Hi,
>
> out of curiosity (and because having a fat jar again might be
> conventient at some point in the future in my work environment (also no
> internet access)):
>
> This solution proposed by Keith does not work
> https://github.com/gradle/gradle-groo
On Wed, 19 Dec 2018 at 22:33, Paul Moore wrote:
> Something simple like
>
> task customFatJar(type: Jar) {
> dependsOn copyDeps
> baseName = 'all-in-one-jar'
> from "dest/lib"
> }
>
> gives me an "all-in-one-jar.jar" that cont
On Wed, 19 Dec 2018 at 21:23, James Kleeh wrote:
>
> Paul,
>
> The best solution is to use Maven or Gradle to create an all-in-one (fat) jar
> that you can ship and run with java -jar
>
> Gradle has a shadow plugin and Maven has a shade plugin to do just that.
Thanks. I'd come to the conclusion
On Wed, 19 Dec 2018 at 20:18, Søren Berg Glasius wrote:
>
> Hi Paul,
>
> This is where The @Grab anotation comes in handy:
> http://docs.groovy-lang.org/latest/html/documentation/grape.html
>
> It wil automatically download your dependencies and it works in Groovy
> scripts too.
Thanks - yes, I
On Wed, 19 Dec 2018 at 08:56, Paul Moore wrote:
>
> On Wed, 19 Dec 2018 at 00:03, Keith Suderman wrote:
> >
> > Option 4) Use the Maven Assembly plugin or the Shade plugin to build your
> > own groovy-all Jar file. Or just use
> > https://github.com/gradle/gra
On Wed, 19 Dec 2018 at 00:03, Keith Suderman wrote:
>
> Option 4) Use the Maven Assembly plugin or the Shade plugin to build your own
> groovy-all Jar file. Or just use https://github.com/gradle/gradle-groovy-all
Thanks. Are there any "beginner guide" style instructions on how to
use the Maven
I use Groovy as a scripting language for small tasks, running on
application servers that do not have very good scripting tools
available, and to which I only have limited access. Prior to Groovy
2.5, I've used the groovy-all jar as a low-impact, easy to deploy
scripting option. I run scripts as
Why do you need something "more concise"? It seems pretty OK to me...
On 18 July 2017 at 15:00, Guy Matz wrote:
> Right! This is what I'm trying to do, but in a more concise way . . . any
> thoughts anyone?
>
> On Mon, Jul 17, 2017 at 8:43 PM, J. David Beutel wrote:
>>
>> I guess OP wants to d
On 29 March 2017 at 20:54, Keith Suderman wrote:
> Two optimizations I have not seen mentioned so far; don't be so Groovy ;-)
:-) My background is Python, so I tend to think in terms of highly
dynamic code. That of course is why I like Groovy ;-)
> 1. Replace the the Map<> with an array of primi
On 29 March 2017 at 15:34, Paul Moore wrote:
> So the big difference is removing def from roll, with removing def
> from rng having a smaller but detectable effect.
I just tried to generalise the script, by making a simulate function
that takes the action as a closure. I won't post a
On 29 March 2017 at 14:56, Nelson, Erick wrote:
> I'm not sure using or not using def would cause performance differences.
There definitely *seems* to be a difference.
def rng = new MersenneTwister()
def roll = {
rng.nextInt(6) + rng.nextInt(6) + rng.nextInt(6) + 3
}
Both def: 0.4 to 0.5 s
On 28 March 2017 at 22:08, Nelson, Erick wrote:
> Try this...
Thanks for the suggestion - there were some nice improvements in here.
> def rng = new MersenneTwister()
>
> def roll = {
> rng.nextInt(6) + rng.nextInt(6) + rng.nextInt(6) + 3
> }
You changed my definitions to use "def" here
On 28 March 2017 at 22:41, John Wagenleitner
wrote:
> Hi Paul,
>
> The milliseconds to seconds conversion was off, so that puts the real time
> at ~0.5 seconds.
>
>>
>> println "Took ${time/100} sec"
*bangs head against desk*...
It's always the stupid mistakes that trip you up!
Regardless, thou
I'm very much a newbie with Groovy, so I apologise in advance if this
is not the right place for questions like this. I couldn't find
anywhere else that looked like a better option - if there is somewhere
I should have asked, feel free to redirect me.
I want to write a simulation script using Groo
On 27 March 2017 at 19:49, Keith Suderman wrote:
> +1 for changing Maven coordinates.
>
> -1 for changing package names. Sure, new code can use the new package
> names, but changing existing packages is just breaking changes for the sake
> of breaking things with no real benefit. I hope the Groo
16 matches
Mail list logo
