Revert "Add back logic for groovy snapshot support"

[codeconsole]

Reverts #1844

[codeconsole]

@matrei is there a need to have conditional logic that will most likely never be needed again?

Why is joint validation resolving the snapshot?

[matrei]

is there a need to have conditional logic that will most likely never be needed again?

Really handy locally for ./gradlew build -PgroovyVersion=4.0.25-SNAPSHOT

Why is joint validation resolving the snapshot?

grails/grails-core#13699

[codeconsole]

is there a need to have conditional logic that will most likely never be needed again?

Really handy locally for ./gradlew build -PgroovyVersion=4.0.25-SNAPSHOT

Why is joint validation resolving the snapshot?

grails/grails-core#13699

@matrei
I don't see that as beneficial UNLESS we are going to stop checking out groovy and building groovy every time for the joint workflow. Is that the plan?

If that is the case, I like it better that cloning the repo every time. If not, I don't like the added logic everywhere.

[jamesfredley]

https://github.com/grails/grails-core/blob/7.0.x/.github/workflows/groovy-joint-workflow.yml#L49 - we currently checkout the major Groovy branch to determine the Groovy Snapshot Version. Then build and publish to mavenLocal() https://github.com/grails/grails-core/blob/7.0.x/.github/workflows/groovy-joint-workflow.yml#L107. We could use the Groovy SNAPSHOT version from the Apache snapshot repo, which should be identical, if desired.

I think there is a high chance we will use a Groovy 4.0.x snapshot again before we complete the Grails 7.0.0 release, especially during milestones, given we have recently requested 4 changes from Groovy, including some major blockers. When we start on Grails 8, if that aligns with the Groovy 5 timeline, as it appears it will, we will most likely need to use Groovy SNAPSHOTs during development prior to Grails 8.0.0 release. Grails is a huge test case for Groovy.

As we move away from repo.grails.org for Grails project SNAPSHOTS and external SNAPSHOT proxying, we will need to include a list of SNAPSHOT (+ milestone for spring) repositories, efficiently, in these Grails projects.

Snapshot and milestone versions of grails-forge generated apps will also need the same list of SNAPSHOT repositories. Release versions of grails-forge will generated apps using only mavenCental() and gradlePluginPortal().

With that we will not need to keep revisiting this, except for a rare occasion where something is not published to the common locations.

[codeconsole]

I still don't see then how having the repository defined is necessary if we are pulling from mavenLocal. This just seems like more over configuration. I am an occam's razor kind of guy and we have a lot of legacy code that we inherited.

We need to simplify and innovate.

[matrei]

I still don't see then how having the repository defined is necessary if we are pulling from mavenLocal

This repo is not pulling the groovy snapshot from mavenLocal at the moment. It has a flaw in the groovy-joint-workflow that makes it not use the built groovy snapshot. It uses the published snapshot from https://repository.apache.org/content/repositories/snapshots. We either have to restore the repository or update the workflow to get the build turn green.

I think @jamesfredley made a pretty good case for keeping the groovy snapshot repo in, regardless of groovy-joint-workflow.

[codeconsole]

@matrei I don't understand what that case is? I spent a lot of time fixing the downstream issues from the snapshot introduction and there still are outstanding issues. I don't think we should be playing around with snapshots. Having logic like this in various repositories will encourage these issues to repeat themselves. All it takes is a 1 snapshot with a newer version resolving in one repository for it to break every other repository and every app that is being run off snapshots.

We still currently have 2 repos failing because of groovy snapshots.

https://github.com/grails/grails-data-mapping/actions/runs/11785022058/job/32895697455
https://github.com/grails/gorm-hibernate6/actions/runs/11807488486/job/32894291338

Even this revert is broken because of groovy snapshots.

[matrei]

We still currently have 2 repos failing because of groovy snapshots

It looks like the repo was down when those actions ran.

Connect to repository.apache.org:443 [repository.apache.org/65.109.119.155] failed: Connect timed out

I don't think we should be playing around with snapshots

The sole purpose of groovy-joint-workflow is to test the project against the Groovy snapshots. This does not affect the other build actions, and does not produce any artifacts. It just gives an assurance that we are still compatible with the latest development of Groovy.

[jamesfredley]

Replaced by #1849