Hi folks 🙂 I've been adding

implements GormEntity

to domain classes and

implements Controller

on controllers to have the IDE auto-completion/identification of methods (IDEA CE). How bad is it? Cause I am in the position of teaching my dueuno:elements framework and I got feedbacks about the "non existing grayed out" methods that generates anxiety to youger people and "why the IDE is not helping here" from more experienced people. Yes I know we could buy IDEA Ultimate which comes with the Grails plugin but the effort of implementing the traits is a lot less costly 🙂 What's your take on this? @Groovy Duke @puneetbehl

Is this Grails IDE plugin open source, if so can some of us take it over to maintain it? It is now just barely usable. In addition, I would like to see if anybody can start to develop a extension for vs code. If some one can start it, i would like to contribute.

Nope, it's a JetBrains product, closed source. I may be wrong but I don't think the Grails plugin is in their priority anymore. On the other side, I think Grails should not require specific features from an IDE to work at its best. This will restrict the adoption and if the "cost" would be just to inherit from a class it could be simply a matter of documenting such behaviour.

If this is not their interests anymore why dont they open source it? Maybe @Groovy Duke @puneetbehl can contact them to find this out. So some of us can take care the maintance.

I understand what you're saying about the cost and what you can say is that it is supported if you get Idea Ultimate and if you don't do that you have the workaround of adding the trait manually. For IntelliJ, I have a personal license which is not that expensive as compared to the business license. Personally, if a company I'm working for isn't willing to buy a license of Intellij for me, then they can't afford to have me as an employee and I would look elsewhere. I know not everyone has that luxury. Also, my opinion is that the main selling point of Grails is the convention over configuration, and having to add traits that are added by default kind of defeats that purpose. The Grails plugin for IntelliJ has always been part of their Ultimate package, so closed source and you have to pay to get it. Unfortunately, there is no better alternative to IntelliJ. You can use Eclipse and the Groovy plugin, but I've always found that lacking, when it came to Grails support. In other words, everything lights up like a Christmas tree with red lights. I don't have any contacts at IntelliJ to ask about it. Still, my feeling is that Idea doesn't really care about Groovy and Grails as the communities are not big enough, or loud enough. They know we don't have a better alternative, so there is no incentive for them to open-source Grails support or support it better. Over the years it seems like new features for Groovy/Grails in Intellij has completely stagnated to the point where I don't think they have anyone dedicated to working on it. It would be nice if there was more competition, but that would take a lot of work and people who have the time to get it done. The other alternative is to get the community to be more annoying to Intellij and constantly create bugs, comment on them, and upvote them. That would take time effort and organization. https://youtrack.jetbrains.com/issues/IDEA?q=groovy https://youtrack.jetbrains.com/issues/IDEA?q=grails

I was thinking more about the adoption of the framework more than the cost by itself. The dependency on another software (an IDE plugin) is nontheless a dependency. And it's not open source, and even if it was opensourced, the plugin works only on the specific non open source IDE. So Grails is technically open source but it depends on NON open source software to be used at its best. The whole idea of Maven/Gradle and the like is not to depend on an IDE to configure the project.

From an adoption viewpoint if you don't have good IDE support that will hurt you. From what I understand IntelliJ has the greatest market share, followed by Eclipse and VSCode. People do use other editors, but they represent a smaller portion of the market and are usually diehard fans of whatever editor they use. Gradle/Maven will get you building and running, but it alone won't give you syntax highlighting, or auto-completion. That's where IDE and Editor support comes in. You can write your own support/plugins to augment and add on support, however, to do so you have to understand how plugins in whatever IDE/editor you want to support work. Most usually have at least something to help with syntax, but your mileage may vary on that. "It would be nice not to depend on an IDE to develop the software as well" Good luck with that. Leveraging language support will only get you so far, and will limit what's possible with your framework. Although that may be fine and if we're still just talking about adding the trait to the controllers, that might be fixed with documentation. Getting adoption for a framework is hard, you have to offer people something that they can't get anywhere else, and make it easier than staying with what they have always done. Couple that with the fact that your framework requires Groovy and Grails, so you are going for a niche market to start. Experienced Grails users probably won't use it because they already know Grails and you can get frontend developers to do a frontend. Groovy while an awesome powerhouse language, it is really bad at marketing. People use Groovy to get stuff done, and don't really talk about it. Also, Java is getting "better" with watered-down versions of features Groovy has had for years, so trying to pull Java devs will get harder. All that said I don't want to diswade or discourage you, just give you an idea of what you are up against.

I agree on everything you said. Except when I said "framework" I was referring to Grails not Dueuno 🙂 Not having to realy upon an IDE plugin to have the autocompletion of the Grails API may benefit the adoptions of Grails

Fair enough. While it may be nice to not rely on the IDE for auto complete and highlighting, I don't know of another option that works and gives that to you. Especially considering Groovys dynamic nature at runtime and compile time, regardless of if you are using static compilation.