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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
