Issue #957: Updating docker Script to Use Latest Groovy5

[AmitKumarDeoghoria]

part of : #957

[romani]

Item

[romani]

Is this class part of groovy?
How system understand what jar to download to use this class?

We used Grape .

[AmitKumarDeoghoria]

I think we can use @grab, still testing some things, let me test and get back.

[AmitKumarDeoghoria]

reference : https://issues.apache.org/jira/browse/GROOVY-9432

[romani]

We should avoid grape if possible.

Did you run this groovy on your local?
I just need some proof that this import is available.

Can we apply this patch to run on groovy 4? If yes, let's migrate off Ant sooner, before migration to groovy 5

[AmitKumarDeoghoria]

No, If you remember from last time we were also in process of upgrading groovy, but we find out that below groovy 4 we have clibuilder() and antbuilder() included in groovy all jar but from 4+ these are excluded.

[AmitKumarDeoghoria]

In local they are available given If we use
@GrabConfig(systemClassLoader=true) @Grab('info.picocli:picocli:4.2.0')

so I researched how these grab mechanism work , It
automatically download and add a dependency (JAR) to the classpath when the script runs in real-time, without mentioning it in pom.xml or adding extra dependencies.
But I am interested in knowing why you want to avoid grab engine mechanism used in groovy? are we making tradeoffs here, Isn't is more resilient like BOM?

[romani]

back in time this still required some config file. But if all works without extra file , it is good.

[AmitKumarDeoghoria]

@romani Plz review:
details of changes :
-used static ref as was gettig this error:

Caught: groovy.lang.MissingMethodException: No signature of static method: getCliOptions for class: diff is applicable for argument types: ([Ljava.lang.String;) values: [[-l, projects-to-test-on.properties, -bc, my_check.xml, -pc, my_check.xml, -b, master, ...]]
Possible solutions: getCliOptions(java.lang.Object)
groovy.lang.MissingMethodException: No signature of static method: getCliOptions for class: diff is applicable for argument types: ([Ljava.lang.String;) values: [[-l, projects-to-test-on.properties, -bc, my_check.xml, -pc, my_check.xml, -b, master, ...]]
Possible solutions: getCliOptions(java.lang.Object)
        at diff.main(diff.groovy:11)

Exited with code exit status 1

• Used picoli as clibuilder was not part of groovy core and should be used via picoli
  was getting some error during the import used this for ref : https://issues.apache.org/jira/browse/GROOVY-9432
• Removed Ant builder and replaced it

[romani]

Can you describe a problem?
What classes need to be changed? I see you refactoring in ant , not sure why we dealing with CLI builder now.

[AmitKumarDeoghoria]

Hey @romani It's because cli builder class is not found as the import is no longer part of groovy all-jar, so we have to use picoli import if we want to use clibuilder for more refernce : https://stackoverflow.com/questions/73862425/groovy-clibuilder-class-not-exists

[romani]

based on stackoverflow , such CLI class is already in groovy4 , so we can migrate to it wihout migration to groovy 5.

as we already use groovy4 images in other places, lets migrate to "info.picocli:picocli" now, test that all works.
and separate PR upgrade only goovy version to 5, so we update all images in all repos just for version bump (no groovy code changes).

Does it sounds good to you ?

[AmitKumarDeoghoria]

Hey @romani as far as I have remember we are using 3.0.21 groovy Image in the docker file which is being used in majority of the CI's, this was precisely the reason we went for 3.0.21 ( missing cli builder) and not 4.0. I understand your view, just all CLI changes and next we can go for only version bump. Yeah I can do that, but for this picoli changes must be backward compatible, let me check.

[AmitKumarDeoghoria]

Ok It's not , info.picoli will be compatible with 4+ only, anyways we have to go for upgrading to 4.0 why not5.0 directly, or do u want to go step by step, first 4 and then 5. Let me know.

[AmitKumarDeoghoria]

this is the version we are using

[romani]

if smooth migration is not possible, ok, lets migrate to 5.0 directly. I just tried to make PRs smaller and easily to approve