Grails Engineering Meeting Notes (02 25 2021)

Date: 02/25/2021

Attendees

• Puneet Behl
• Bobby Warner
• James Kleeh

Agenda

• Migration of existing Grails Plugins artifacts
• Publish new artifacts
• Open Discussion
• Appreciations
• Plan next week

Migration of existing Grails Plugins artifacts

• Puneet: We migrated most of Grails plugins but I have not added the repository as a remote link, but once that is done, I think we should be good to go and I'll remove the remote link to Bintray.
• Puneet: However there are a few challenges because there are some old artifacts in Bintray which I'm not able to download either via Bintray UI, or the API. So I'm not sure how we would migrate those artifacts. Let me just share my screen quickly to show you what I mean?
• Puneet: Please let me know once you can see my screen.
• Bobby Warner: Yep, I see it.
• Puneet: So, this is bintray.com. Let's start with Grails Core. Package. There's a package called old-grails-release-packages. It has the old Grails version such as 3.0.1 , 3.0.2 etc. Although I can see the files and you know the JAR files as well. But I am unable to download them. The requested page was not found and that is the same case with the API.
• Bobby Warner: Oh weird.
• Puneet: I will probably send an email to the Bintray team, to see if they can help us with this. And there are some other artifacts like this. This is one example and similarly in the Profiles. We have a package grails-core. I don't know what this is, but we have this and then there are some specific versions such as three, you know, before 3.1.5, which is 3.1.4, 3.1.3, 3.1.2, and 3.1.1. So these are also not available. The same error. So, that is weird.
• Bobby Warner: Okay.
• Puneet: Yeah. and these are the repositories I created in the JFrog. These includes Grails releases, Plugins, and Profiles.
• Bobby Warner: Awesome.
• Puneet: We have a Grails application; sorry not a Grails but Groovy application which basically clone that artifacts from Bintray to JFrog Grails artifactory.
• Bobby Warner: Nice work.
• Puneet: Thanks!
• James Kleeh: I never followed up with you after we sort of pair programmed on the Bintray thing,
• James Kleeh: So, how long did it cut? The execution time?
• Puneet: It was 30 or maybe 40 minutes, something like that, from 8 hours.
• Bobby Warner: That's a big change.
• Puneet: Right, initially I was copying each file synchronously.
• Puneet: James, and I had a discussion where he suggested that we should move to multi-threading to leverage all the cores of the machine.

Publishing New Grails Artifacts

• Puneet: Last week, we released Grails 4.0.8. In that release, we published to Maven-Central using new publishing logic to use Maven Central instead of binaryUpload and bintrayPublish tasks.
• Puneet: We faced some challenges with 3.3.x, and I'm not sure when likely would be the next release. So, I'm planning that we get to that problem when we actually want to release something in 3.3.x.
• Bobby Warner: Okay.
• Puneet: Do you want to know how we are doing the release with Grails core?
• Bobby Warner: Sure.
• Puneet: We are using the Nexus published plugin, in addition to Maven publish
• Puneet: The Maven Publish plugin, which basically, publishes the artifacts to Maven.
• Puneet: In addition, there is Gradle signing plugin, which signs the artifacts using gpg?
• Puneet: At last, we also uses the Gradle Nexus publish plugin at the root project.
• Puneet: It creates a staging artifactory in the Maven Central before publishing, then it publishes all the artifacts to a staging OSS repository, verify the signature, perform other validations.
• Puneet: Once that is successful, it uploads, closes, and release the version of that artifacts and that basically goes to central.
• Puneet: Another thing with publishing, I am not sure if it is possible or Is there a way we could stop publishing to Bintray?
• James Kleeh: What do you mean?
• Puneet: I mean, like an option on Grails, binary accounts saying that do not allow you to publish new versions of the artifacts to be published on Bintray.
• James Kleeh: You can just like, You could kill the key that's being used.
• Puneet: No, I think you misunderstood the question. I mean that some plugin authors have included their packages. So they may be publishing new versions of them which might not include in the new repository we created under the Grails JFrog artifactory.
• James Kleeh: Well we Can't Stop other people from uploading new adventure but for our own stuff you could invalidate. The key I think that's being used.
• Bobby Warner: Are you talking about Grails core stuff? Are you talking about plugins?
• Puneet: I'm talking about the community plugins, The Grails core stuff is in our and we won't be publishing them to Bintray. And, I could take care of that but with the community plugin where users have requested to “Include my package” and Grails been great. You know, The Grails plugins Bintray they might be adding new versions to their packages and which would still show up and have not synced will not be sync to our local artifactory.
• James Kleeh: You can't prevent people from publishing packages to their own. Bintray. The only thing I would say is to run the sync like the week before Bintray shuts down.
• Bobby Warner: I mean, I guess, I agree with James, I don't even worry about that. People can publish whatever they want. I would just run it after they stop allowing publishing. So once they kill publishing, run your program one more time. Grab everything that's been new since you last run it and then you're good to go.
• Bobby Warner: Almost unless I'm missing something more complex than that.
• Puneet: No, no, my only concern. Yeah, I agree. My only concern was always trying to catch up with the artifacts which are missing, but yes I agree with James suggestion.
• James Kleeh: You don't always have to, you just do it one more time.

Open Discussions

Arango DB GORM Implementation

• Puneet: A person in this community suggested something like Arango DB, which seems to be a combination of MongoDB, and Neo4j. He was asking if we could implement it.
• Puneet: For now, I have responded that we don't have any plans for it because of the current priorities.
• James Kleeh: Is he talking about a GORM implementation?
• Puneet: Yes.
• James Kleeh: That's probably not going to happen.
• Puneet: Even if we found it interesting or something, maybe we could do it. But not in the short term. It may be something we would look at in the long term.
• Puneet: There are a lot of other items in the priority right now. I suggested to him if he need that, he could contribute and I would be happy to help.
• Puneet: Apart from this, there are a bunch of issues. I am not able to get a chance to look at it. If you have some time, and you think you could take a look. That would be great.

Triaging Issues

• Puneet: There are some issues where I receive email notifications and I'm not sure about it., It's about triaging or I'm not sure how to tackle those things like the issue is already closed. So for instance there is this. Great explore issue.
• Puneet: Let me share the link with you guys.
• Puneet: It's just so, which is already closed but I'm still receiving email notifications. Do I have to respond them immediately?
• James Kleeh: What are you asking? How to stop receiving email notifications?
• Puneet: No, my main concern is that do I have to reply to each one of them? Otherwise, I think after a certain period of time these things are lost.
• James Kleeh: You don't have to reply to anything. I mean, Like, there's no compulsory record.
• Bobby Warner: I tell you we talked about it one time and maybe I think this is maybe something Jason or James something you mentioned, you don't you guys have like, an auto responder on Micronaut issues. Where like, if if there's no discussion or something after a certain amount of time it closes it,
• James Kleeh: We did at one time and then we ended up not we ended up, stopped stopping using it because there were things that like didn't really require discussion, but You know where things that were on our Horizon to do but then it would close those issues, you know, I mean
• James Kleeh: So we didn't, we didn't we didn't really find it that useful but to answer your question Puneet. No there's no, you have no compulsory requirement, you know, nobody's gonna come to your house and arrest you if you don't respond to these issues. So it's not.
• Puneet: No, I didn't mean in that direction. I honestly meant it in a way that, you know, these things are lost and sometimes I don't get to them.
• Puneet: So, I was thinking maybe there is some strategy we could use to fix this. Otherwise, these things keep piling up, and hard to track.,
• James Kleeh: So, like You can't, you know, teach people how to use GitHub. Like that's just not within your scope of possibilities like. So if people are responding and replying to closed issues,
• James Kleeh: They should understand that. That's not the way to effectively communicate through that platform.
• James Kleeh: The only thing is so if somebody ever does that, like if somebody, if somebody does that in Micronaut, and I see it, like an amount like a physically looking at it. I'll just say, you know, create a new issue. I mean I won't like to take time to really dig into What they're saying?
• James Kleeh: Also like this this issue is closed, so it should be fixed. So if you're still seeing a problem, create another issue like and that's what I'll just say.
• Puneet: Yeah, I think that makes sense. I'll do the same going forward. Yeah. All right, that that's all from my side. You guys want to add anything?

Grails Engineering Meetings Agenda

• Puneet: In general about engineering meetings. Is it okay to just talk about what's going on? or do we want engineering me to be more kind of a discussion where we discuss? You know, something we want to include in Grails core or, you know, some new things, which one of you might be interested in or things like that.
• James Kleeh: I can include anything. I think anybody wants to discuss at that time.
• Puneet: Yeah. It's like if from my observation from past few meetings, we are just updating about what's going on, right? What am I doing and all that? and,
• James Kleeh: That's the main purpose of the meeting.
• Bobby Warner: Yeah, I guess I'm fine with just anything. If anybody has a topic they want to bring up. I don't think generis are not to talk about. Whether it's something new being worked on, or it's status of what the current progress is.
• Puneet: It's more like, you know, the roadmap items. So maybe one thing we could, you know, yeah, it would not be something to add to the roadmap in each meeting. But once in a while, something to discuss, you know, the future of Grails, and, any ideas around it? All the stuff. Yeah. All right. Thank you, everyone. I hope my transcripts capture all the meeting notes, otherwise, I'm in. I don't know. Trouble.
• James Kleeh: Once again, to meet, it's not, there's no laws being broken here, okay? Everything's gonna be fine.

Appreciations

• Bobby Warner: I'm just gonna say that you did a great job by taking care of the migration. Obviously that's a pretty pretty big change and pretty big Dramatics change from JFrog. So good job and getting that taken care of.
• Puneet: Yeah, it's a teamwork.. It's not just me, everybody's available, Jason James and, you know, Alvaro helping with migration, and publishing stuff. So yeah. Thanks. Oh yeah. Yeah.

Plan Next Week

• Puneet: Next week, starting tomorrow I'm going to migrate most of the Grails core projects to use the new publishing stuff and remove Bintray plugin.
• Puneet: We would probably have a blog post about how to publish Grails plugins going forward which describes all other options, and how?, the technicalities of how to publish the artifacts.
• Puneet: There's a recent blog post on InfoQ which is not specifically related to Grails, but Gradle and then they shared some options to move away from JCenter, Bintray.
• Bobby Warner: Sounds good.