Return-Path: X-Original-To: apmail-groovy-users-archive@minotaur.apache.org Delivered-To: apmail-groovy-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 732F918665 for ; Tue, 8 Mar 2016 17:39:32 +0000 (UTC) Received: (qmail 59514 invoked by uid 500); 8 Mar 2016 17:39:27 -0000 Delivered-To: apmail-groovy-users-archive@groovy.apache.org Received: (qmail 59486 invoked by uid 500); 8 Mar 2016 17:39:27 -0000 Mailing-List: contact users-help@groovy.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@groovy.apache.org Delivered-To: mailing list users@groovy.apache.org Received: (qmail 59476 invoked by uid 99); 8 Mar 2016 17:39:27 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Mar 2016 17:39:27 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id C3B9EC2EA5 for ; Tue, 8 Mar 2016 17:39:26 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.999 X-Spam-Level: ** X-Spam-Status: No, score=2.999 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, KAM_LAZY_DOMAIN_SECURITY=1, RP_MATCHES_RCVD=-0.001] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id DctYIpGEytAY for ; Tue, 8 Mar 2016 17:39:24 +0000 (UTC) Received: from ds2.netgate.net (ds2.netgate.net [205.214.170.150]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 71E325FBCD for ; Tue, 8 Mar 2016 17:39:24 +0000 (UTC) X-No-Relay: not in my network X-No-Relay: not in my network Received: from Henriks-MacBook-Pro.local (184-105-177-98.static.hilltopinternet.com [184.105.177.98]) by ds2.netgate.net (Postfix) with ESMTPSA id B04E73601F; Tue, 8 Mar 2016 09:39:16 -0800 (PST) Reply-To: henrik@netgate.net Subject: Re: building a jar from groovy script with gradle References: <56DEAD42.7060903@gmail.com> <5C676E6359909E478C7B811BDB48CA3545AFF7@CWWAPP478.windstream.com> <56DEE3C9.4070103@gmail.com> <56DF05F5.3010808@netgate.net> To: David Dawson , users@groovy.apache.org From: Henrik Martin Message-ID: <56DF0E44.9000408@netgate.net> Date: Tue, 8 Mar 2016 09:39:16 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------060404020903060108010500" This is a multi-part message in MIME format. --------------060404020903060108010500 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit That's good to know! I've only used the bootRepackage stuff for Spring Boot apps, so I've never really examined the bare dependencies of the uber jar without other Spring dependencies. The Spring Boot stuff in general is very nice, and I use it for everything from small IoT projects to Big Data deployments. Cheers, -H On 3/8/16 9:08 AM, David Dawson wrote: > good steer on shadowJar. > > I can confirm though that all you end up with is a couple of hundred > kb of spring boot launcher. Nothing else spring is pulled in. > > > On 8 March 2016 at 17:03, Henrik Martin > wrote: > > For "uber jars", I use both Spring Boot's bootRepackage, and > shadowJar, the Gradle port of Maven Shadow. Both work really well > and are easy to use from Gradle. The only thing about using Spring > Boot is that you probably end up with a bunch of transient > dependencies for Spring/Spring Boot that may bloat your runnable > jar file. From that perspective, I think the shadowJar solution > will result in fewer dependencies. Here's the link to shadowJar if > you want to check it out: > > https://github.com/johnrengelman/shadow > > Cheers, > > -H > > > On 3/8/16 6:40 AM, David Dawson wrote: >> I actually re-use the spring boot plugin. >> >> You don't have to use it to build a spring boot application, it >> can build vanilla apps too. >> >> add the spring boot plugin, set the mainClass attribute as in >> their examples and do a gradle bootRepackage. >> >> You'll end up with a single runnable jar file. >> >> You can even do that with no source, just jars in the deps list >> and reference a class in one of the dependencies. >> >> >> >> On 8 March 2016 at 14:38, Schalk Cronjé > > wrote: >> >> What's wrong with running a .bat file? >> >> >> On 08/03/2016 14:30, Gerald Wiltse wrote: >>> I have a similar situation I am about to tackle, building an >>> installer that executes Groovy code. This will be going to >>> clients and run on windows, so it really has to be an EXE. >>> >>> Anybody have good experience with JAR-to-EXE packers or >>> something? >>> >>> Gerald R. Wiltse >>> jerrywiltse@gmail.com >>> >>> >>> On Tue, Mar 8, 2016 at 8:42 AM, Winnebeck, Jason >>> >> > wrote: >>> >>> I've "deployed" some scripts to other users in my >>> organization where Java but not Groovy is installed >>> through the GroovyWrapper script. I got it from Codehaus >>> and I can't find the original copy anywhere but I found >>> a fork of it at >>> https://github.com/sdanzan/groovy-wrapper that appears >>> to have more features than the original. The original I >>> have basically just uses the Ant inside of the Groovy >>> distribution to compile a single Groovy file and merge >>> that file, embeddable groovy JAR and some of the Groovy >>> libs into a single jar you can run with java -jar. >>> >>> Looking at the code it appears the main difference in >>> that updated script is that it supports adding @Grab'd >>> dependencies into the single JAR, presumably to prevent >>> users from having to download them. >>> >>> Jason >>> >>> -----Original Message----- >>> From: Jim Northrop >>> [mailto:james.b.northrop@googlemail.com >>> ] >>> Sent: Tuesday, March 08, 2016 8:19 AM >>> To: users@groovy.apache.org >>> Subject: Re: building a jar from groovy script with gradle >>> >>> Out of interest, what is the typical deployment strategy >>> for a runnable Groovy class w/main method? I have been >>> trying to make a user executable jar but as 2 diff.jars. >>> One jar is only my code, no support jars and 2nd is >>> mystuff-all-v1.0.jar as a bundle w/all dependency jars >>> included hence runnable. End user can choose jar. >>> >>> Are there other strategies to package code 4 deployment? >>> Thx. >>> >>> Sent from my iPad >>> >>> > On 8 Mar 2016, at 11:45, Schalk Cronjé >>> > wrote: >>> > >>> > I can spot a number of issues in your Gradle script, >>> howver I need to understand context. >>> > >>> > [1] Are you trying to put a single Groovy script + >>> required Groovy JARs into a JAR? >>> > >>> > OR >>> > >>> > [2] Are you trying to build a proper Groovy >>> application consisting of a coouple of class files en >>> dependent JARs? >>> > >>> >> On 08/03/2016 10:33, Raphael Bauduin wrote: >>> >> >>> >> Hi, >>> >> >>> >> I'm trying to package a groovy script as a jar with >>> the help of >>> >> gradle, I use this gradle config: >>> http://pastebin.com/RFEhzMCp >>> >> >>> >> it builds fine, but when I try to run it with java >>> -jar path_to.jar I >>> >> get this error: >>> >> Error: A JNI error has occurred, please check your >>> installation and >>> >> try again Exception in thread "main" >>> java.lang.SecurityException: >>> >> Invalid signature file digest for Manifest main >>> attributes >>> >> >>> >> The only suggestions I found online applied when >>> people repackaged jars, which is not my case. >>> >> Any suggestion? >>> >> >>> >> Thanks >>> >> >>> >> Rb >>> > >>> > >>> > -- >>> > Schalk W. Cronjé >>> > Twitter / Ello / Toeter : @ysb33r >>> > >>> >>> ---------------------------------------------------------------------- >>> This email message and any attachments are for the sole >>> use of the intended recipient(s). Any unauthorized >>> review, use, disclosure or distribution is prohibited. >>> If you are not the intended recipient, please contact >>> the sender by reply email and destroy all copies of the >>> original message and any attachments. >>> >>> >> >> >> -- >> Schalk W. Cronjé >> Twitter / Ello / Toeter : @ysb33r >> >> >> >> >> -- >> >> >> David Dawson | CEO | Simplicity Itself >> >> Tel +44 7866 011 256 >> Skype: davidadawson >> david.dawson@simplicityitself.com >> >> http://www.simplicityitself.com > > > > > -- > > > David Dawson | CEO | Simplicity Itself > > Tel +44 7866 011 256 > Skype: davidadawson > david.dawson@simplicityitself.com > > http://www.simplicityitself.com --------------060404020903060108010500 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit That's good to know! I've only used the bootRepackage stuff for Spring Boot apps, so I've never really examined the bare dependencies of the uber jar without other Spring dependencies. The Spring Boot stuff in general is very nice, and I use it for everything from small IoT projects to Big Data deployments. Cheers,

-H

On 3/8/16 9:08 AM, David Dawson wrote:
good steer on shadowJar.

I can confirm though that all you end up with is a couple of hundred kb of spring boot launcher. Nothing else spring is pulled in.  


On 8 March 2016 at 17:03, Henrik Martin <henrik@netgate.net> wrote:
For "uber jars", I use both Spring Boot's bootRepackage, and shadowJar, the Gradle port of Maven Shadow. Both work really well and are easy to use from Gradle. The only thing about using Spring Boot is that you probably end up with a bunch of transient dependencies for Spring/Spring Boot that may bloat your runnable jar file. From that perspective, I think the shadowJar solution will result in fewer dependencies. Here's the link to shadowJar if you want to check it out:

https://github.com/johnrengelman/shadow

Cheers,

-H


On 3/8/16 6:40 AM, David Dawson wrote:
I actually re-use the spring boot plugin.

You don't have to use it to build a spring boot application, it can build vanilla apps too.

add the spring boot plugin, set the mainClass attribute as in their examples and do a gradle bootRepackage. 

You'll end up with a single runnable jar file. 

You can even do that with no source, just jars in the deps list and reference a class in one of the dependencies.



On 8 March 2016 at 14:38, Schalk Cronjé <ysb33r@gmail.com> wrote:
What's wrong with running a .bat file?


On 08/03/2016 14:30, Gerald Wiltse wrote:
I have a similar situation I am about to tackle, building an installer that executes Groovy code. This will be going to clients and run on windows, so it really has to be an EXE. 

Anybody have good experience with JAR-to-EXE packers or something?

Gerald R. Wiltse
jerrywiltse@gmail.com


On Tue, Mar 8, 2016 at 8:42 AM, Winnebeck, Jason <Jason.Winnebeck@windstream.com> wrote:
I've "deployed" some scripts to other users in my organization where Java but not Groovy is installed through the GroovyWrapper script. I got it from Codehaus and I can't find the original copy anywhere but I found a fork of it at https://github.com/sdanzan/groovy-wrapper that appears to have more features than the original. The original I have basically just uses the Ant inside of the Groovy distribution to compile a single Groovy file and merge that file, embeddable groovy JAR and some of the Groovy libs into a single jar you can run with java -jar.

Looking at the code it appears the main difference in that updated script is that it supports adding @Grab'd dependencies into the single JAR, presumably to prevent users from having to download them.

Jason

-----Original Message-----
From: Jim Northrop [mailto:james.b.northrop@googlemail.com]
Sent: Tuesday, March 08, 2016 8:19 AM
To: users@groovy.apache.org
Subject: Re: building a jar from groovy script with gradle

Out of interest, what is the typical deployment strategy for a runnable Groovy class w/main method? I have been trying to make a user executable jar but as 2 diff.jars. One jar is only my code, no support jars and 2nd is mystuff-all-v1.0.jar as a bundle w/all dependency jars included hence runnable. End user can choose jar.

 Are there other strategies to package code 4 deployment?
Thx.

Sent from my iPad

> On 8 Mar 2016, at 11:45, Schalk Cronjé <ysb33r@gmail.com> wrote:
>
> I can spot a number of issues in your Gradle script, howver I need to understand context.
>
> [1] Are you trying to put a single Groovy script + required Groovy JARs into a JAR?
>
> OR
>
> [2] Are you trying to build a proper Groovy application consisting of a coouple of class files en dependent JARs?
>
>> On 08/03/2016 10:33, Raphael Bauduin wrote:
>>
>> Hi,
>>
>> I'm trying to package a groovy script as a jar with the help of
>> gradle, I use this gradle config: http://pastebin.com/RFEhzMCp
>>
>> it builds fine, but when I try to run it with java -jar path_to.jar I
>> get this error:
>> Error: A JNI error has occurred, please check your installation and
>> try again Exception in thread "main" java.lang.SecurityException:
>> Invalid signature file digest for Manifest main attributes
>>
>> The only suggestions I found online applied when people repackaged jars, which is not my case.
>> Any suggestion?
>>
>> Thanks
>>
>> Rb
>
>
> --
> Schalk W. Cronjé
> Twitter / Ello / Toeter : @ysb33r
>

----------------------------------------------------------------------
This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.



-- 
Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r



--


David Dawson | CEO | Simplicity Itself

http://www.simplicityitself.com




--


David Dawson | CEO | Simplicity Itself

Tel +44 7866 011 256
Skype: davidadawson
david.dawson@simplicityitself.com
http://www.simplicityitself.com

--------------060404020903060108010500--