feature: separate API to run & debug applications

[s1n7ax]

Parent issue: #13

[s1n7ax]

At the moment I'm not sure how to execute main methods in run mode. I have started a discussion in nvim-dap to figure this out
mfussenegger/nvim-dap#1094

[atm1020]

Hi there!

What do you think about getting these data from jdtlsclient:

• java executable
• classpath
• main class

and setting up a command from these?

I have tested this approach with both Maven and Gradle projects, and it works.

[s1n7ax]

@atm1020 you mean manually running the command through java cli?

[atm1020]

@s1n7ax I mean creating a command like this: java -cp classpath mainclass, and then executing it.

[atm1020]

To test out this idea, I have created this function ( in the nvim-core-java project.):

--- @param callback fun(cmd: string[])
function M:run_app(callback)
	local resolved_main_class_records = self.client:resolve_main_class()
	-- multiple main classes ?
	local main_class = resolved_main_class_records[1].mainClass
	local project_name = resolved_main_class_records[1].projectName
	local file_path = resolved_main_class_records[1].filePath
	log.debug('main class: ' .. main_class .. " project name: " .. project_name .. "  filePath: " .. file_path )

	local resolved_java_executable = self.client:resolve_java_executable(
		main_class,
		project_name
	)
	log.debug('java exec: ' .. resolved_java_executable)

	self.client:build_workspace(project_name,project_name, file_path, true)

	local classpath = table.concat(self.client:resolve_classpath(main_class,project_name)[2], ':')
	log.debug('classpath: ' .. classpath)

	local cmd = {
		resolved_java_executable,
		'-cp',
		classpath,
		main_class
	}

	callback(cmd)
end

with a callback function, the users can choose where they want to run a command. For example, in my case, i like to use toogleterm.

[s1n7ax]

@atm1020 Cool. I guess we could introduce this initially and intellij like features later on. Things like logs from previous executions, stop and re-run etc...

[atm1020]

@s1n7ax Yes, I agree. May I try implementing this feature?

[s1n7ax]

@atm1020 Sure. Ask me if you got any questions

[atm1020]

@s1n7ax I think about two ways to do this:

1. set up the run_app function in the nvim-java-core project.

   • create a new class called RunApi which extends just the JdtlsClient.
   • move the necessary functions from the debug-client to the jdtls-client. I think these functions belong to the jdtls-client instead of the debug-client.
   • functions:
     - resolve_main_class
     - resolve_java_executable
     - resolve_classpath
     - build_workspace
   • use this class in the core project.

2. set up the run_app function in the nvim-java project.

   • use the dap client, which has all the fuctions that i need.

(I think the first option is a better way to do this)

[s1n7ax]

@atm1020 client classes contains the commands defined by each component (naming could have been better)

• jdtls-client- commands defined by jdtls itself
• java-debug-client - commands defined by java-debug extension jar
• java-test-client - commands defined by java-test extension jar

So, moving them into jdtls-client is not suitable. It's likely that java-debug-client & java-test-client will be moved to respective projects in the future.

Can't think of a place to define it but either nvim-java-core/lua/api or nvim-java-dap/lua/api/runner would be fine i guess

[atm1020]

@s1n7ax I didn't realize that, my bad. Thank you for the help. I will implement this in the nvim-java-core project.

[atm1020]

@s1n7ax I found a small bug that needs to be fixed for this feature:

The JavaDebugResolveMainClassRecord class has the wrong property name, it should be filePath instead of fileName as shown in the log:

./lua/java-core/api/runner.lua:26: resolved main class records: { {
    filePath = "home/user/mock/Main.java",
    mainClass = "com.mock.Main",
    projectName = "mock"
  } }

Should I solve it within this feature or create a separate PR?

[s1n7ax]

No just go ahead and change in the same PR. Add two commits

[s1n7ax]

@atm1020 Hi. I'm sorry. I completely missed the fact that we already do something like this.

Using enrich config you can get the classpath for a given mainClass in a project.

https://github.com/nvim-java/nvim-java-dap/blob/603091d06f82db6f710865f71fdf7666299439c1/lua/java-dap/api/setup.lua?plain=1#L48-L79

So the changes you have made to nvim-java-core can be avoided. In the nvim-java project you can define the Lua API. When there are multiple main classes, you can use vim.ui.select function to prompt the user and get a value and the execute the command.

[atm1020]

@s1n7ax No problem! I have closed the PR, and i will try to implement that in the nvim-java project.