Re: How to test and deploy without groovy-all?

[Corum, Michael]

I’ve noticed that there is a general sense that the majority of the users don’t 
need groovy-all.  How did that knowledge come about?  Was there a survey that I 
missed?  Is there a place I can go to see the survey results?  (By the way – we 
depend on it in our projects).

Michael Corum
VP, Technical Architecture Solutions

RGA Reinsurance Company
16600 Swingley Ridge Road
Chesterfield, Missouri 6301701706
T 636.736.7066
www.rgare.com



From: OCsite 
Reply-To: "users@groovy.apache.org" 
Date: Monday, May 18, 2020 at 11:47 AM
To: "users@groovy.apache.org" 
Subject: Re: How to test and deploy without groovy-all?

External e-mail. Use caution! / Courriel externe. Faites attention!


On 18 May 2020, at 18:12, Mauro Molinari 
mailto:mauro...@tiscali.it>> wrote:

Il 18/05/20 17:48, OCsite ha scritto:
(Actually I can't imagine the Maven/Gradle workflow to be considerably 
different: the principle of creating the application package and installing it 
plus all the JARs needed to the server and launching it there with proper 
classpath is completely independent on the toolchain, is is not?)
If I understand it well, the main difference is: Maven/Gradle also provide for 
dependency management.
I can't see how. Embedding all the dependencies is not reasonable: that way, 
your application gets monstrously big, and you either waste both the bandwidth 
installing and the space on all the servers, or you need to have a smart 
installation script, probably rsync-based. Still, even with this, you won't be 
able to easily keep old application versions (again, unless you make some smart 
tools based on hardlinks), etc.

Embedding makes sense where the thing does not change often. It very definitely 
makes an excellent sense to embed all the Groovy JARs into groovy-all, for 
there's a small number of separate Groovy versions to keep for a particular 
server. It would be completely absurd to embed groovy (and other libraries, 
which change even seldom than Groovy) into the application, whose new version 
is deployed pretty often.

Aside of that, there's sharing of resources: whilst we do need for application 
A to use Groovy 2.4.17 and B to use 3.0.3, there's also C, D and E, which all 
use 2.4.17, and F and G which both use 3.0.3. Aside of that, all the 
application share the WebObjects and WOnder libraries and a number of other 
JARs. Embedding them all into each the application would be a nonsense.
If your only dependency is Groovy, you're very lucky. Usually you'll depend on 
other modules, probably dozens of them: thinking of handling them manually as 
you do produces the so called "JAR hell".
Actually JAR hell is not caused by manual handling of libraries, but by the 
completely stupid Java JAR design. Given the Sun engineers already had had an 
experience with an infinitely better OpenStep, which they had co-designed with 
NeXT and whose frameworks do not sport this problem, it is very sad; and 
precisely the same applies to the language itself: how on earth can somebody 
who already experienced the elegance and power of Objective C invent an 
übercrap like Java?!? Anyway, I am digressing again, sorry for that :(

Anyway, with groovy-all there's no JAR-hell at least far as Groovy itself is 
concerned. Removing groovy-all brings it, or at the very least its potential, 
to Groovy itself too :(
To build project B to get an application B.woa with 3.0.3 groovyc, and to make 
sure at the deployment site that this application, when launched, gets all the 
proper groovy 3.0.3 libraries. This seems unnecessarily complicated compared 
with the above: either I am forced to create my own groovy-all-3.0.3-indy.jar 
myself (and then 3.0.4 again, etc. etc.), or I have to copy lots of JARs to the 
server and to the classpath separately. Ick.

What I am asking for is a reasonable way to do the B part, so that it is not 
unnecessarily much more complicated than A.
With Gradle, applying the "application plugin" will let you build a fat JAR or 
rather a ZIP file containing your application code and all of its dependency 
JARs
Which is precisely what you do not want to do, at least, not if you use a big 
number of big libraries, as detailed above.
plus the scripts needed to run your application under different operating 
systems. Substantially for free.
To write and maintain my own launch script takes about one thousandth time and 
effort as compared with learning a whole new ecosystem which I do not need at 
all (well, perhaps now for the first time and for the one and one sole thing, 
i.e., creating my own groovy-all, which should be part of the distro).

So you can easily copy your JAR or your ZIP file from one environment to the 
other and start your application, being sure it will run properly.-
Creating so either hundreds of copies of all the libraries on each the server, 
which would be patently absurd (not speaking of the bandwidth copying them 
again and again and again completely unnecessarily 

Re: Code coverage tools?

[Corum, Michael]

Actually in my case, @CompileStatic helped improve accuracy of coverage for 
Cobertura.  For Groovy/Dropwizard, I using this in my build.gradle:

Plugins {
 id "net.saliman.cobertura" version "2.5.4"
}

And then later in my build.gradle, I also include:


configurations.all {
resolutionStrategy {
forcedModules = ['org.ow2.asm:asm:5.0.3', 'org.ow2.asm:asm-tree:5.0.3', 
'org.ow2.asm:asm-commons:5.0.3', 'org.ow2.asm:asm-util:5.0.3', 
'org.ow2.asm:asm-analysis:5.0.3']
}
}

I probably need to update the versions on those but that helped the accuracy 
for Cobertura quite a bit.

Michael Corum
VP, Technical Architecture Solutions

RGA Reinsurance Company
16600 Swingley Ridge Road
Chesterfield, Missouri 6301701706
T 636.736.7066
www.rgare.com


From: Søren Berg Glasius 
Reply-To: "users@groovy.apache.org" 
Date: Friday, June 21, 2019 at 1:04 AM
To: "users@groovy.apache.org" , Scott Hickey 

Subject: Re: Code coverage tools?

External e-mail. Use caution! / Courriel externe. Faites attention!

@Scott Hickey but can you make it work with 
@CompileStatic and the Elvis operator? We are having big struggles to get that 
working. (In a Grails 3.3.x application)
Best regards / Med venlig hilsen,
Søren Berg Glasius

Hedevej 1, Gl. Rye, 8680 Ry, Denmark
Mobile: +45 40 44 91 88, Skype: sbglasius
--- Press ESC once to quit - twice to save the changes.


On Fri, 21 Jun 2019 at 00:31, Scott Hickey 
mailto:jscotthic...@gmail.com>> wrote:
We are using Clover - it is open source now. We have found it works much better 
for us at Mutual of Omaha than JaCoCo or Cobertura.

Scott Hickey
Mutual of Omaha

On Thu, Jun 20, 2019 at 12:02 PM Sean LeBlanc 
mailto:sean.lebl...@icd-tech.com>> wrote:
What are people using currently to get accurate code coverage from new(ish) 
versions of Groovy? We are on 2.4.10 and I see similar issues as what this 
thread is talking about:

https://github.com/cobertura/cobertura/issues/184



Does anyone have good experiences with getting more accurate code coverage 
numbers with Groovy > 2.0.8? And what route did you take?

Re: Code coverage tools?

[Corum, Michael]

Typically, if I have something (a microservice) that is 100% covered both for 
lines and branches, neither JaCoCo or Cobertura will show it properly unless I 
do some things.  Here are some examples of the type of things I have to do:

  *   Re-order methods in a class.  This can make as much as 15% or more 
difference in the overall code coverage.
  *   Change to static typing on some returns from methods (but not all).  This 
can make a large difference.
  *   Some refactors help coverage.  In particular, turning “if’s” into types 
can help since the coverage tools usually show way more branch options than the 
expressions would indicate.  For instance, if you had something like “if (x == 
y)” that might say there are something like 13 possible branch options due to 
odd generated code related to the “if.”

I have quite a few projects where I’ve gotten Cobertura to correctly show 100% 
line/branch coverage and many with it showing 99% so I set my build thresholds 
to around 97 or 98 to make sure I catch anything changing that but it takes 
some time to arrange things to be correctly measured.

Michael Corum
VP, Technical Architecture Solutions

RGA Reinsurance Company
16600 Swingley Ridge Road
Chesterfield, Missouri 6301701706
T 636.736.7066
www.rgare.com


From: Paul King 
Reply-To: "users@groovy.apache.org" , 
"pa...@asert.com.au" 
Date: Thursday, June 20, 2019 at 4:15 PM
To: "users@groovy.apache.org" 
Subject: Re: Code coverage tools?

External e-mail. Use caution! / Courriel externe. Faites attention!

Groovy has done a lot of work recently to mark generated methods with an 
@Generated annotation. We have other generated methods which are synthetic 
methods. I know JaCoCo has been making changes to ensure that such methods 
aren't included in coverage analysis. I am not sure whether Cobertura has done 
any updates along those lines. It did appear for a while that activity on 
Cobertura was decreasing but I notice there was some activity a few months ago. 
It is perhaps worth asking that community about whether they have or can 
consider making similar changes, otherwise perhaps switching to JaCoCo might be 
the way to go.

Cheers, Paul.

On Fri, Jun 21, 2019 at 3:02 AM Sean LeBlanc 
mailto:sean.lebl...@icd-tech.com>> wrote:
What are people using currently to get accurate code coverage from new(ish) 
versions of Groovy? We are on 2.4.10 and I see similar issues as what this 
thread is talking about:

https://github.com/cobertura/cobertura/issues/184



Does anyone have good experiences with getting more accurate code coverage 
numbers with Groovy > 2.0.8? And what route did you take?

Re: [DISCUSS] Groovy 2.6 potential retirement to focus on Groovy 3.0

[Corum, Michael]

If 3.0 will still support JDK8, I’d vote for option 3 as well.  If 3 will 
require 9, then maybe option 2.

Michael Corum
VP, Technical Architecture Solutions

RGA Reinsurance Company
16600 Swingley Ridge Road
Chesterfield, Missouri 6301701706
T 636.736.7066
www.rgare.com

From: Paul King 
Reply-To: "users@groovy.apache.org" , 
"pa...@asert.com.au" 
Date: Wednesday, June 13, 2018 at 2:06 AM
To: "users@groovy.apache.org" 
Subject: [DISCUSS] Groovy 2.6 potential retirement to focus on Groovy 3.0

External e-mail. Use caution! / Courriel externe. Faites attention!


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.

Re: Groovy Docker images

[Corum, Michael]

Not related to Groovy as much.  We’ve never been able to get OpenJDK (7 or 8) 
to work properly with Oracle JDBC drivers on Alpine.  Always have to use Oracle 
JDK and in the research we did, we found others with the same issues.

Michael Corum
VP, Technical Architecture Solutions

RGA Reinsurance Company
16600 Swingley Ridge Road
Chesterfield, Missouri 6301701706
T 636.736.7066
www.rgare.com


From: Guillaume Laforge <glafo...@gmail.com<mailto:glafo...@gmail.com>>
Reply-To: "users@groovy.apache.org<mailto:users@groovy.apache.org>" 
<users@groovy.apache.org<mailto:users@groovy.apache.org>>
Date: Friday, September 9, 2016 at 10:16 PM
To: "users@groovy.apache.org<mailto:users@groovy.apache.org>" 
<users@groovy.apache.org<mailto:users@groovy.apache.org>>
Subject: Re: Groovy Docker images

Out of curiosity, what's the problem with OpenJDK?
Is it related to Groovy or not at all?

On Sat, Sep 10, 2016 at 5:09 AM, Corum, Michael 
<mco...@rgare.com<mailto:mco...@rgare.com>> wrote:


  *   Either one
  *   Alpine – I suspect others will want other options though
  *   Would most definitely prefer Oracle but I assume other would want OpenJDK 
as well.  For my purposes OpenJDK just doesn’t work at all.
Michael Corum
VP, Technical Architecture Solutions

RGA Reinsurance Company
16600 Swingley Ridge Road
Chesterfield, Missouri 6301701706
T 636.736.7066
www.rgare.com<http://www.rgare.com>


From: Keegan Witt <keeganw...@gmail.com<mailto:keeganw...@gmail.com>>
Reply-To: "users@groovy.apache.org<mailto:users@groovy.apache.org>" 
<users@groovy.apache.org<mailto:users@groovy.apache.org>>
Date: Friday, September 9, 2016 at 9:48 PM
To: "users@groovy.apache.org<mailto:users@groovy.apache.org>" 
<users@groovy.apache.org<mailto:users@groovy.apache.org>>
Subject: Groovy Docker images

I was thinking of putting together some Docker images for Groovy, with the idea 
they might be useful to base Grails, Gradle, etc images on and wondered 
people's opinions on a few things.

  *   Should I install Groovy manually in somewhere like /opt?  Or use SDKMAN?
  *   Should I have images based on Alpine and Debian? Alpine only?
  *   I presume OpenJDK images are fine as bases?  Any reason we'd need an 
Oracle based image too?

Thoughts?

-Keegan



--
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>

Re: Groovy Docker images

[Corum, Michael]

  *   Either one
  *   Alpine – I suspect others will want other options though
  *   Would most definitely prefer Oracle but I assume other would want OpenJDK 
as well.  For my purposes OpenJDK just doesn’t work at all.
Michael Corum
VP, Technical Architecture Solutions

RGA Reinsurance Company
16600 Swingley Ridge Road
Chesterfield, Missouri 6301701706
T 636.736.7066
www.rgare.com


From: Keegan Witt >
Reply-To: "users@groovy.apache.org" 
>
Date: Friday, September 9, 2016 at 9:48 PM
To: "users@groovy.apache.org" 
>
Subject: Groovy Docker images

I was thinking of putting together some Docker images for Groovy, with the idea 
they might be useful to base Grails, Gradle, etc images on and wondered 
people's opinions on a few things.

  *   Should I install Groovy manually in somewhere like /opt?  Or use SDKMAN?
  *   Should I have images based on Alpine and Debian? Alpine only?
  *   I presume OpenJDK images are fine as bases?  Any reason we'd need an 
Oracle based image too?

Thoughts?

-Keegan