The largest benefit: if repo.grails.org gets removed tomorrow, we know what will break and why. Today, that repo points to so many things that I don't think we have a good understanding of what's required for various grails applications.
The second benefit: I know of several old libraries that are accessible in that repo (ones that went through licensing changes that aren't on maven central, i.e. iText) and we need to make sure people aren't still resolving them as part of a plugin or a secondary dependency. Forcing a change to a new location forces people to update older libraries. Grails 7 seems to be the best time to do that. -James On Sat, May 3, 2025 at 5:58 PM Mattias Reichel <mattias.reic...@gmail.com> wrote: > We could do that, but I don't think I fully understand the benefit of doing > so. > What are the implications of old artifacts being resolvable? > I guess a fresh start for Grails 7+ artifacts would not hurt given the age > and state of that repository. > > Den lör 3 maj 2025 kl 14:47 skrev James Daugherty > <jdaughe...@jdresources.net.invalid>: > > > @Mattias, what are your thoughts about creating a new repository on > > repo.grails.org to isolate legacy artifacts? > > > > On Sat, May 3, 2025 at 7:52 AM Mattias Reichel < > mattias.reic...@gmail.com> > > wrote: > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
