Re: building a jar from groovy script with gradle
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 > jerrywil...@gmail.com > > > On Tue, Mar 8, 2016 at 8:42 AM, Winnebeck, Jason < > jason.winneb...@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.north...@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é < >> ysb...@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> >> 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.daw...@simplicityitself.com http://www.simplicityitself.com
Re: building a jar from groovy script with gradle
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 >> jerrywil...@gmail.com >> >> >> On Tue, Mar 8, 2016 at 8:42 AM, Winnebeck, Jason < >> jason.winneb...@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> >>> 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.north...@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: >>&g
Re: "Not handled exceptions" inspection?
To take a different point of view. The debate was had, checked exceptions *lost*. Every language designed since Java was released and this was seen as a problem has explicitly removed checked exceptions. Go event went to the point of removing exceptions altogether. Checked exceptions mixed the problems of *documenting failure conditions* and *recovery. *These aren't the same thing, and what happened in java is that unrecoverable problems (network failures, io problems) are thrown as exceptions, alongside the recoverable ones. This debased the potential value of checked exceptions. Java got it wrong, and is stuck with the legacy of that decision. Witness the ugliness of lambda streams and IO. Yuck. I loved it when spring allowed my to generically handle exceptions through it's runtime exception based wrappers. They still put them on the method sigs, so you get documentation. Groovy took that to the next level, implementing that across the entire runtime. This was a *good decision* To the original point. I think it might be informative to understand what the use case is. A redesign of the components will probably mean you can get the benefit you want without bringing checked exceptions back into Groovy. On 24 March 2016 at 14:01, Schalk Cronjé wrote: > Checked exceptions remain a debatable point. Some people like them, some > don't. A lot of viewpoints depends on the background of the specific > people. There is no correct answer, however. > > > On 24/03/2016 13:32, Jochen Theodorou wrote: > >> >> >> On 23.03.2016 22:37, Libor Jelinek wrote: >> >>> Hello Groovy community! >>> Is there some tool like groovyc warning / IDEA inspections / CodeNarc >>> that will report situation when some method declares exception but you >>> (a method user) don't re-declare nor catch it. >>> >>> I find it extremely useful. Because if for Groovy are exceptions are >>> unchecked, it effectively negates all benefits of have exceptions. To be >>> honest exceptions are the only part of Java that I really miss in Groovy. >>> >> >> The benefit of exceptions is not, that you are then reminded of having to >> catch them, but that they allow you to jump out of faulty code to error >> handling places. But anyway.. no, the compiler does not check that. I guess >> you could write a transform or an extension to the type checker to add such >> a check. But there are no plans for anything like that atm >> >> bye Jochen >> > > > -- > Schalk W. Cronjé > Twitter / Ello / Toeter : @ysb33r > > -- David Dawson | CEO | Simplicity Itself Tel +44 7866 011 256 Skype: davidadawson david.daw...@simplicityitself.com http://www.simplicityitself.com
Re: About Gradle, Kotlin and Inner Fear
if I can suggest, this will take in the order of months of dedicated effort from a small team to get running smoothly. The core groovy team don't have the ability (ie, time) to organise this, which is why it's gone by the wayside. My suggestion is that those who are asking how to help should look to self organise. Set up a mailing list and dedicated slack channel, get all those who are involved in there and start to grind through setting up the environment, making small fixes etc. Bring in the core team when you can't progress. it's going to be a chunk of work. The eclipse api and how to integrate with it will be te rub. Groovy eclipse has a bunch of patches that dig into the compiler to catch errors, handle failures and present that into the UI, so you'll need to start understanding the groovy compiler, and also the eclipse api. I'd say, get the code and start beating the crap out of it over a weekend with anyone else that shows an interest, see where you get? David. On 25 May 2016 at 18:22, Balachandran Sivakumar wrote: > Hi, > > On Mon, May 23, 2016 at 10:02 PM, Balachandran Sivakumar < > benignb...@gmail.com> wrote: > >> Hi Cedric, >> >> On Mon, May 23, 2016 at 5:27 PM, Cédric Champeau < >> cedric.champ...@gmail.com> wrote: >> >>> there's absolutely no need for an external DSL descriptor: all the >>>> constructs of the language, like extension methods or static builders are >>>> first class language features. The issue is, IDE support for Groovy is >>>> lacking (Groovy Eclipse is dead, IntelliJ needs to know specifics of static >>>> Gradle/Groovy scripts, ...) >>> >>> >> If we have to resurrect it, what would it take ? I mean, what skill >> set/knowledge should someone have to work on it and resurrect it ? Also, >> can someone here help with that effort ? Thanks >> >> > Can someone please help with this ? What would it take for someone > with reasonable Groovy/Java knowledge to pick up Goovy Eclipse and maintain > it ? Thanks > > -- > Thank you > Balachandran Sivakumar > > -- David Dawson | CEO | Simplicity Itself Tel +44 7866 011 256 Skype: davidadawson david.daw...@simplicityitself.com http://www.simplicityitself.com
Re: [VOTE] new operator ?=
+1 On 23 November 2016 at 16:01, Guillaume Laforge wrote: > There's more context in that thread here: > http://www.groovy-lang.org/mailing-lists.html > > On Wed, Nov 23, 2016 at 5:00 PM, Abhinav Sharma > wrote: > >> Well, you need to give more use cases for this one >> On Nov 23, 2016 9:29 PM, "Daniel Sun" wrote: >> >>> Hi all, >>> >>> If the new operator ?= (e.g. a ?= 'foo' is equivalent of a = a ?: >>> 'foo') were to be added to Groovy programming language, do you like it? >>> (Yes: +1; No: -1; Not bad: 0) >>> >>> Cheers, >>> Daniel.Sun >>> >>> >>> >>> -- >>> View this message in context: http://groovy.329449.n5.nabble >>> .com/VOTE-new-operator-tp5736931.html >>> Sent from the Groovy Users mailing list archive at Nabble.com. >>> >> > > > -- > Guillaume Laforge > Apache Groovy committer & PMC Vice-President > Developer Advocate @ Google Cloud Platform > > Blog: http://glaforge.appspot.com/ > Social: @glaforge <http://twitter.com/glaforge> / Google+ > <https://plus.google.com/u/0/114130972232398734985/posts> > -- David Dawson | CEO | Simplicity Itself Tel +44 7866 011 256 Skype: davidadawson david.daw...@simplicityitself.com http://www.simplicityitself.com
Re: What's the status of the Gpars library ?
Hi, I recently went through the process of artifact deploy/ promotion to maven central using a self hosted OSS artifactory and bintray. Its a process with a few manual steps, which could be automated (except for the last promotion to central I think) but it seems low impact enough not to bother. I'd be happy to replicate that for gpars if that would be helpful? David On 14 October 2017 at 08:54, Russel Winder wrote: > On Fri, 2017-10-13 at 21:07 +0200, Christian Sperandio wrote: > > Hi, > > > > I want to learn more about concurrency programming in Groovy and I’ve > found > > the Gpars library. > > But in the maven repository, the last version dates on 2014. > > Is this project live anymore ? Or this library is so stable and it > doesn’t > > need more changes. > > GPars project is far from dead. However it is suffering from a lack of > programmers and documentors actively working on it. > > The GPars 1.X series is basically done and in "not really being maintained" > mode, though a last release is required. This version of GPars pre-dates > JDK8, > uses tools and techniques of implementation that are now out of date, and > so > has no future as an implementation of concurrency. > > The GPars 2.X series will rely on JDK8 or later. However, I have not been > able > to get it ready for release (long, probably boring, story) and no-one else > seems interested enough in GPars getting a new release to join in and > help. I > am hoping to be able to get back to this is 2018, making a JDK8 and JDK9 > compatible version, i.e. plan on GPars being a module. > > A core question is how to get a release onto Maven Central, possibly via > Bintray. The observant will notice there hasn't been a GPars release since > the > demise of Cohehaus – the single biggest reason being no-one associated with > GPars has had the time/inclination to find out how to get it done. > > Schalk Cronjé and myself have had a couple of goes at this, but run out of > time, and Bintray has moved on since then. So if someone can step up to > help > with the release process, a final 1.X release can be made and the first 2.0 > one as well. > > Help with the documentation as well as the implementation and release would > also be welcome, the 1.X → 2.X change will need quite a lot of work to get > the > documentation up to scratch. There is nothing worse than a great library > with > crap documentation. > > In the end GPars is a volunteer project with no paid support, the people > who > like and/or use it are most welcome to give back by helping out. > > -- > Russel. > == > Dr Russel Winder t: +44 20 7585 2200 > 41 Buckmaster Roadm: +44 7770 465 077 > London SW11 1EN, UK w: www.russel.org.uk >
Re: What's the status of the Gpars library ?
Sounds like you have a volunteer Russel ;-) Original Message From: msz...@wp.pl Sent: 14 October 2017 20:15 To: users@groovy.apache.org Reply to: users@groovy.apache.org Subject: Re: What's the status of the Gpars library ? On 2017-10-14 13:31, David Dawson wrote: > Hi, > > I recently went through the process of artifact deploy/ promotion to maven > central using a self hosted OSS artifactory and bintray. Its a process > with a few manual steps, which could be automated (except for the last > promotion to central I think) but it seems low impact enough not to bother. > > I'd be happy to replicate that for gpars if that would be helpful? It sounds good, however, there is also a way to completely automatically release to Maven Central directly from Travis with Git commit messages such as "[#DO_RELEASE]" or "[#DO_RELEASE][#2.0.0]". I've been using it to release my projects in the Continuous Delivery process for a year or so (and in general it works :) ). Sample configuration: https://github.com/szpak/mockito-java8/blob/master/gradle/cdeliveryboy-release.gradle (in fact just a few lines are required for the release process, others are to satisfy Maven Central requirements, e.g. generated pom.xml elements). I could also provide the release support as a backup plan. Nevertheless, those are not the only possible way in the Gradle universe. Marcin > On 14 October 2017 at 08:54, Russel Winder wrote: > >> On Fri, 2017-10-13 at 21:07 +0200, Christian Sperandio wrote: >>> Hi, >>> >>> I want to learn more about concurrency programming in Groovy and I’ve >> found >>> the Gpars library. >>> But in the maven repository, the last version dates on 2014. >>> Is this project live anymore ? Or this library is so stable and it >> doesn’t >>> need more changes. >> >> GPars project is far from dead. However it is suffering from a lack of >> programmers and documentors actively working on it. >> >> The GPars 1.X series is basically done and in "not really being maintained" >> mode, though a last release is required. This version of GPars pre-dates >> JDK8, >> uses tools and techniques of implementation that are now out of date, and >> so >> has no future as an implementation of concurrency. >> >> The GPars 2.X series will rely on JDK8 or later. However, I have not been >> able >> to get it ready for release (long, probably boring, story) and no-one else >> seems interested enough in GPars getting a new release to join in and >> help. I >> am hoping to be able to get back to this is 2018, making a JDK8 and JDK9 >> compatible version, i.e. plan on GPars being a module. >> >> A core question is how to get a release onto Maven Central, possibly via >> Bintray. The observant will notice there hasn't been a GPars release since >> the >> demise of Cohehaus – the single biggest reason being no-one associated with >> GPars has had the time/inclination to find out how to get it done. >> >> Schalk Cronjé and myself have had a couple of goes at this, but run out of >> time, and Bintray has moved on since then. So if someone can step up to >> help >> with the release process, a final 1.X release can be made and the first 2.0 >> one as well. >> >> Help with the documentation as well as the implementation and release would >> also be welcome, the 1.X → 2.X change will need quite a lot of work to get >> the >> documentation up to scratch. There is nothing worse than a great library >> with >> crap documentation. >> >> In the end GPars is a volunteer project with no paid support, the people >> who >> like and/or use it are most welcome to give back by helping out. >> >> -- >> Russel. >> == >> Dr Russel Winder t: +44 20 7585 2200 >> 41 Buckmaster Road m: +44 7770 465 077 >> London SW11 1EN, UK w: www.russel.org.uk >> > -- http://blog.solidsoft.info/ - Working code is not enough
Re: [DISCUSS] Groovy 2.6 potential retirement to focus on Groovy 3.0
I would vote 2.Actually, i would vote 3) abandon 2.6 immediately.No projects I have any knowledge of still use jdk 7. From: pa...@asert.com.auSent: 13 June 2018 08:06To: users@groovy.apache.orgReply to: users@groovy.apache.orgSubject: [DISCUSS] Groovy 2.6 potential retirement to focus on Groovy 3.0 Hi everyone,There was some discussion at gr8conf about how to speed up delivery of Groovy 3.0. Some of that discussion was around the scope of what we want to include and have yet to complete in 3.0 but I won't discuss that right now.One of the other discussion points was Groovy around 2.6. As many of you know, we have released alpha versions of Groovy 2.6. That version is a backport of most but not all of Groovy 3.0 to JDK7 including the Parrot parser (though it isn't enabled by default). The purpose of this version has always been to assist people/projects wanting to use the Parrot parser but who might be stuck on JDK7. So in some sense it is an intermediate version to assist with porting towards Groovy 3.0. While that is still a noble goal in theory, in practice, many of our users are already on JDK8 and we have limited resources to work on many potential areas.With that in mind, we'd like to understand the preferences in our user base for the following two options:Option 1: please continue releasing the best possible 2.6 even if that slows down the final release of Groovy 3.0 and delays further work on better support for JDK9+.Option 2: please release one more alpha of 2.6 over the next month or so which will become the best version to use to assist porting for users stuck on JDK7 and then focus on 3.0. The 2.6 branch will essentially be retired though we will consider PRs from the community for critical fixes.Feedback welcome.Cheers, Paul.
