Author Topic: Better gradle support  (Read 1441 times)


  • Senior Community Member
  • Posts: 232
  • Hero Points: 26
Better gradle support
« on: March 10, 2018, 10:06:13 pm »
My Java improvement series.

It is fair to say that SE doesn't deal well with gradle projects. This is pity because any moderately complex Java project with jar dependencies is using either maven or gradle. I am attaching a sample gradle project to help illustrate some of the stuff that doesn't work.
  • Something easy, the .gradle file extension should be separate from Groovy. I always need to adapt the word definition for the Gradle DSL, as well as clear the auto close options
  • There is no subproject support. If you generate SE in a subproject, SE has no inkling what is going on around it. No visibility to dependent peer projects, no tagging support. Try the Application1 SE project and see if you can resolve the Helper class. SE needs to learn how to climb up to the root and learn about subprojects.
  • SE doesn't try to learn the classpath configurations from gradle.  As a result, it cannot resolve external references. See what silly things it comes up with when you try to find the definition for LogManager.  The gradle cache contains the source jars for almost anything it pulls from the repo on behalf of your application.  What a great opportunity for SE to find definitions!, it should take advantage of it.
  • Debugging doesn't work
  • Unit Test Debugging is not supported

For me, the heaviest missing feature is #3. The lack of symbol resolution is a huge productivity killer as it forces me to switch to other tools to compensate.


  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 5174
  • Hero Points: 427
Re: Better gradle support
« Reply #1 on: May 11, 2018, 08:02:37 pm »
Excellent suggestions