I think we should keep using repo.grails.org for now (below the other repos, in the repositories block), and await JFrogs answer, if we can keep using it.
/Mattias Den lör 3 maj 2025 kl 10:42 skrev Gianluca Sartori <g.sart...@gmail.com>: > Hi James & James, > > I agree we should move to repo.gradle.org/gradle/libs-releases, for all > the > technical reasons you've provided, but also to make Grails more future > proof and communicate it as more "integrated" with relevant technologies > (if that makes any sense, it does in my mind). > > Gianluca Sartori > -- > https://dueuno.com > > > On Sat, 3 May 2025 at 01:23, James Daugherty > <jdaughe...@jdresources.net.invalid> wrote: > > > I would like to see us try to exclude repo.grails.org/grails/core from > our > > default applications if at all possible. > > > > There are several reasons: > > > > 1. The age of that repo: it has so many dependencies in it. > > 2. It has both snapshot & release artifacts (I realize that the snapshot > > versions aren't supposed to be chosen, but people make mistakes and it > > happens). > > 3. We're relying on Cloudflare to continue to give us "free" services for > > CDN / certificate management. By adopting more public repos, we can > lessen > > this burden in case it's switched off. (I believe it's traffic sits > around > > 1.5TB/month currently). > > 4. It's an external resource from Apache. > > > > I realize this goal is easier said than done, but I know this repo is > also > > currently required for: > > > > 1. grails-plugins github org > > 2. gradle tooling api > > 3. gpc github org > > 4. legacy artifacts - some of which have since had a license change to > what > > some consider unacceptable (so this is the only source) > > > > I believe all of these can be worked around. Here are my thoughts on > each: > > 1. I'm happy to do the work to start publishing to central. > > 2. You have given us 2 possible solutions. I lean towards just adding > the > > repo.gradle.org/gradle/libs-releases location. Alternatively, we can > > create a dedicated repo on repo.grails.org so that it doesn't include > the > > legacy artifacts. I'm less a fan of Netbeans since they're repackaging > it > > and it could technically be different. We also have to wait for them to > > upgrade gradle (possibly). > > 3. Like #1, I can get GPC publishing to central snapshots or we can > publish > > them to their github repos and people can add as they need. > > 4. This is really my #1 concern, but given that 7 has upgraded just about > > every version, I don't see a need for this. If people are still using > > legacy artifacts, we need to know. This is more of a reason to not use > it. > > > > It would be nice to also include snapshot repos only on snapshot builds, > > while using release only repos for official releases. Especially now > that > > we've gotten rid of the pre-release workflow. > > > > -James > > > > > > > > On Fri, May 2, 2025 at 12:54 PM James Fredley <jamesfred...@apache.org> > > wrote: > > > > > Previously we solved for the org.gradle:gradle-tooling-api dependency > by > > > adding a remote repo on repo.grails.org so that it is available via > > > https://repo.grails.org/ui/native/core/org/gradle/gradle-tooling-api/ > > > > > > org.gradle:gradle-tooling-api is currently a dependency on > > > grails-shell-cli only > > > > > > As we move the main projects away from repo.grails.org, I think we > will > > > want to solve this another way. This might be more of a Grails 7.1.0 > or > > > 8.0.0 decision. > > > > > > 1. Add an additional repository to the grails-core projects and end > > > generated projects > > > https://repo.gradle.org/gradle/libs-releases/ > > > > > > 2. Use the republished versions from NetBeans > > > > > > > > > https://central.sonatype.com/artifact/org.netbeans.external/gradle-tooling-api/versions > > > > > > > > > > > > > > > > > >
