Hi,

I am not a Java programmer at all, but I hope we can do better than what
we currently do, regarding Groovy. The version in Debian is not good
enough to run Jenkins pipelines, which is pretty much the only use case
for Groovy that I am aware of, and has reached its end-of-life almost
four years ago. Therefore, I would like to try to package a newer
version or help with packaging, but I defninitely need some help with
that. What is your opinion on the matter?


Kind regards,
Toni

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

there's also a bug open: #951831 which is now four years old.

Kind regards,
Toni

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Pierre,

On Thu, Sep 26, 2024 at 09:22:56PM +0200, Pierre Gruet wrote:

I would wholeheartedly appreciate such an update!

thank you! So I'm not alone...

Approx. 2 years ago I tried to package Groovy 3 and ran into antlr4 issues. If we still have problems with it, then we will have to look for a solution. Anyway, I am willing to help you.

Quite a while back, I also tried to make a Groovy 3 update, but due to
my lack of Java skills, I didn't get far. Also, the existing Groovy
package appears to do a whole lot of things which are confusing to me,
so I am currently thinking along the lines of just trying to make a
bare-bones "groovy4" package, to keep things as simple as possible.

Looking at the roadmap and seeing Groovy 5 being already around the
corner, I don't see too much of a point in looking at Groovy 3 at the
moment, but maybe my judgement is just completely wrong, owing to my
lack of understanding of the Java world.

What do you think?


Kind regards,
Toni

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Pierre,

On Sat, Sep 28, 2024 at 11:30:34PM +0200, Pierre Gruet wrote:

I also think we should not target only Groovy 3; maybe 4, or even 5 if we
are not in a hurry. However, a quick glance at the sources shows that there are .groovy files to compile in the source of groovy, so jumping from the current 2.x to 5 (or even 4?) is certainly an important technical challenge.

I would aim at installing a new version of Groovy independently of the
existing Groovy 2.x package, so the user should be able to choose which
one the user wants and smoothly transition. In addition, there could be,
in analogy to the earlier situation in the Python area, a
"groovy-is-grovy2" or a "groovy-is-groovy4" package to configure a
system-wide preference.

How do you think we should start? Maybe creating a new branch in the Salsa repo of groovy?

I am inclined to try to start over because at least I could already not incorporate the changes required for Groovy3. I guess the changes
required for Groovy4 or -5 would be even bigger. As I said initially,
I'm not a Java developer at all, so I'll definitely need some help here.


Kind regards,
Toni

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Sat, Sep 28, 2024 at 11:30:34PM +0200, Pierre Gruet wrote:

Le 26/09/2024 à 22:15, Toni Mueller a écrit :

Looking at the roadmap and seeing Groovy 5 being already around the

at the moment, they might quite well be faster than I am. :(

How do you think we should start? Maybe creating a new branch in the Salsa repo of groovy?

It occurred to me that there might be one big problem with building
Groovy, which is our massively outdated Gradle. The Groovy source
code states that it requires Gradle 8.10 to build, but we have only
4.4. So the first step might be to build Gradle.

I haven't looked into your Salsa repo, yet, but probably should, as
building these behemoths is really a challenge for me.


Cheers,
Toni

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)