'Gauge init java_maven' project does not work in VSCode

[PiotrNestor]

Describe the bug

'Gauge init java_maven' project does not create pom.xml that works correctly in VSCode

To Reproduce

1. Create a initial Java + Maven (pom.xml) Gauge test project

gauge init java_maven

2. Open the project in VSCode

3. Spec is not executed when 'Run' in spec but the command runs indefinitely. The project needs to be reloaded.

pom.xml contains old versions for:

• maven-compiler-plugin
• gauge-maven-plugin
• gauge-java

Logs
Problems:
Build path specifies execution environment JavaSE-11. There are no JREs installed in the workspace that are strictly compatible with this environment.
The compiler compliance specified is 11 but a JRE 17 is used

Run in spec:
Running tool: -q clean compile test-compile gauge:execute -Dflags=--hide-suggestion,--simple-console -DspecsDir=specs\example.spec:21

Notifications
Error calculating project classpath. ,,'undefined' is not recognized as an internal or external command, operable program or batch file.

Additional context
gauge --version

Gauge version: 1.6.13
Commit Hash: 706e32a

Plugins

dotnet (0.7.4)
html-report (4.3.1)
java (0.11.2)
python (0.4.6)
reportportal (1.17.0)
screenshot (0.3.0)
xml-report (0.5.1)

VSCode
Version: 1.97.2
Commit: e54c774e0add60467559eb0d1e229c6452cf8447
Date: 2025-02-12T23:20:35.343Z
Electron: 32.2.7
ElectronBuildId: 10982180
Chromium: 128.0.6613.186
Node.js: 20.18.1
V8: 12.8.374.38-electron.0
OS: Windows_NT x64 10.0.19045

'Extension Pack for Java'
Identifier
vscjava.vscode-java-pack
Version
0.29.0
Last Updated
2025-02-17, 10:22:21

[chadlwilson]

This issue should be at https://github.com/getgauge/template-java-maven or the vscode plugin.

All of the examples are outdated - simply too many to maintain. However the POM is a completely valid POM, so it's something else specific to your environment or VSCode.

What did you do to make it work?

[PiotrNestor]

@chadlwilson
I suspect that the only significant problem is:
Running tool: -q clean compile test-compile gauge:execute -Dflags=--hide-suggestion,--simple-console -DspecsDir=specs\example.spec:21

There is no 'mvn' in the above command string. But I have no idea where this could be defined.

Regarding the pom.xml. I've just updated version for the different Java components:

        <dependency>
            <groupId>com.thoughtworks.gauge</groupId>
            <artifactId>gauge-java</artifactId>
            <version>0.11.2</version>
            <scope>test</scope>
        </dependency>

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>17</source>
                    <target>17</target>
                </configuration>
            </plugin>
            <plugin>
                <groupId>com.thoughtworks.gauge.maven</groupId>
                <artifactId>gauge-maven-plugin</artifactId>
                <version>1.6.3</version>
                <executions>
                    <execution>
                        <phase>test</phase>
                        <configuration>
                            <specsDir>specs</specsDir>
                        </configuration>
                        <goals>
                            <goal>execute</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

From the the terminal it works:

mvn gauge:execute -DspecsDir=specs

[chadlwilson]

Are you familiar with Maven/java projects?

Java 17 can run and target Java 11 compiled code, so not sure why VSCode is complaining about that. That's a VSCode problem.

Running tool: -q clean compile test-compile gauge:execute -Dflags=--hide-suggestion,--simple-console -DspecsDir=specs\example.spec:21

There is no 'mvn' in the above command string. But I have no idea where this could be defined.

VSCode is simply supplying those args to Maven, similar to how the CLI does it.

Regarding the pom.xml. I've just updated version for the different Java components:

And did it work via VSCode when you made any of these changes?

[PiotrNestor]

@chadlwilson
The 'Run' from a spec file just hangs forever with no output in logs
'Debug' does not start anything ...

[chadlwilson]

If you would like help, can you please take the time to respond to the specific questions I asked rather than making other random observations?

[PiotrNestor]

@chadlwilson
In VSCode, in a spec file:

• Run Scenario | Debug Scenario - these are available which indicated that the java language plugin works and it has validated the spec-file

• 'Run Scenario' produces Output: Running tool: -q clean compile test-compile gauge:execute -Dflags=--hide-suggestion,--simple-console -DspecsDir=specs\example.spec:21
  But there is nothing executed. There are no logs updates either
  The command cannot be stopped. Trying again results: A Specification or Scenario is still running!
  The project needs to be reload to clear this.

Conclusion: I does not work to Run or Debug in VSCode
The specification code and tools are fine because it works to run correctly the project specifications from the terminal.

[jensakejohansson]

Yes, I suspect VSCode extension, although I don't think it's due to a change in the extension itself (very few updates during the past years), but maybe a change in VSCode that affects how the extension works.

Background: I had a gauge java_maven project that has worked fine previously, but has not been executed since late 2023. Tried to open it now and execute a test, but it won't work. Then I tried to create a new "blank" project, same problem. Reverted to runner/plugin to the one used last time it worked, no difference.

When running it looks like this and hangs forever:

Shouldn't the 'mvn'-command be before that launch string? Maybe the question is why it's missing?

Then the error to the right seems to be same as discussed here: #613 although I don't know how to mitigate that.

I guess we'll have to dig in here. I work with dotnet on a daily basis, so understanding a Java project more in depth will be an up-hill-battle.

@chadlwilson @sriv If any of you have a Java env. locally, feel free to try to init a java_maven project just to make sure it's not an environment issue on our part.

[chadlwilson]

I have many Java envs but I don't use either Maven or VScode day-to-day so don't really have the inclination to dive into yet another likely breaking change of some sort from VSCode. 😓

[sriv]

gauge init java_maven and subsequently running gauge run specs works from CLI.

When initializing a project using vscode's command pallette, the project gets initialized properly, I was able to run the project fine both using the vscode's "Run Spec" action and the cli.

I am on below java version:

openjdk version "22.0.2" 2024-07-16
OpenJDK Runtime Environment Corretto-22.0.2.9.1 (build 22.0.2+9-FR)
OpenJDK 64-Bit Server VM Corretto-22.0.2.9.1 (build 22.0.2+9-FR, mixed mode, sharing)

[jensakejohansson]

@sriv Thanks! CLI works for us too, only VSCode that won't launch the scenario. Then this indicates that it's not a Gauge/runner/extension issue, but some sort of Java/VSCode configuration on our side. That helps alot......

[chadlwilson]

So initiate project via gauge CLI but then try and use/run the project via VScode?

[jensakejohansson]

@chadlwilson Yes.
@sriv What platform are you running? MacOS/Linux/Windows? We're running on Windows...

I'm struggling with the extension. I cannot get breakpoints working, it just says they are 'unbound', and trying to debug without being able to step through the code is quite hopeless. However, my conclusion is that the extension does not find the mvn-command. It seems it's getting 'undefined' back from the method trying to locate the command and this is not handled/caught by the extension(!) and therefore it's trying to launch the spec with an invalid command (blank launch command - it just provides the arguments).

I'm guessing the problem is around this method: (I don't know why it doesn't find maven - the command is in my path of course - but it seems the method returns undefined.)

[chadlwilson]

Perhaps at root it's the same problem as #989 / #990

[sriv]

I tried this on a macbook @jensakejohansson - I don't have a windows machine handy right now, will try to borrow one and check.

[jensakejohansson]

@chadlwilson Thanks, yes those are definitely related.

It's a breaking change in Node that introduced this problem. I've fixed the getCommand-method. Basically .cmd/.bat files has to spawned in a shell (makes sense). On Windows Maven is launched with a .cmd-file. So now the extension seems to build a valid command.

However, still struggling with the actual execution. Tried the same there, trying to launch with shell: true in execute-method (gaugeExecutor.ts) - but but no execution happens. Small steps forward at least...

[PiotrNestor]

@sriv @chadlwilson @jensakejohansson
Together with Jens we've verified that 'shell' is needed in the spawnXXX methods on Windows in the gauge-vscode plugin
The following preliminary changes fixes the issue where 'mvn' exists as mvn.cmd and needs to be executed via a shell.

cli.ts

    private static getCommand(command: string): string {
        let validExecExt = [""];
        if (platform() === 'win32') validExecExt.push(".bat", ".exe", ".cmd");
        for (const ext of validExecExt) {
            let executable = `${command}${ext}`;
            const options = platform() === 'win32' ? { shell: true } : {};
            if (!spawnSync(executable, options).error) return executable;
        }
        return ""; // Explicit return to satisfy return type.
    }

gaugeExecutor.ts

...
                    let options = { cwd: config.getProject().root(), env: env , detached: false, shell: true};
                    if (platform() !== 'win32') {
                        options.detached = true;
                        options.shell = false;
                    }
                    this.childProcess = spawn(cmd, args, options);
...

I suppose we'll propose an update to the gauge-vscode

[sriv]

thanks for the analysis and the troubleshoot @PiotrNestor and @jensakejohansson - Could you try the changes from the #990 and see if that helps? In which case we can merge that PR and profit.

Else I guess we need the changes you've uncovered here.

[chadlwilson]

Very likely to be that if it goes through the plugin's launching mechanism, as Maven ships with a mvn.cmd on Windows, being a Java application that needs a JVM invocation and relevant args.

Earlier I thought that logic was only really used for launching Gauge itself, and since the problems were not widespread most people's environments were locating gauge.exe directly, which should be the preferred behaviour. So it was limited to npm-based installations.

But yeah, if this mechanism is used for launching arbitrary tools, many will have cmd or bats on Windows and thus need to enable the shell option on modern NodeJS/Electron/VSCode.

[PiotrNestor]

@sriv @chadlwilson
The other updates in #990 are for the gauge command which if executed using gauge.exe should not need the 'shell' to execute.
These additional changes might be needed if nodejs is used to run gauge.
In that case I'd suggest a different PR

[chadlwilson]

@PiotrNestor Sorry, not sure what you are talking about - that's not what the PR does. The PR fixes issues with launching .bat/.cmd on NodeJS 20+ on Windows. VSCode is built on Electron, which bundles an opinionated, tested version of NodeJS. Thus extensions need to run correctly on the NodeJS versions VSCode includes.

The same code is used for launching Gauge itself and (apparently also) certain Maven commands.

gauge-vscode/src/cli.ts

Lines 27 to 28 in 15ec34e

	const gaugeCommand = this.getCommand(GaugeCommands.Gauge);
	let mvnCommand = this.getCommand(MAVEN_COMMAND);

The detail is not really of relevance to you, but whether it fixes your problem is. So can you please try testing it to see if it fixes your problem?

[chadlwilson]

You can try with the below unofficial test build (or build yourself if you are most paranoid about security).

gauge-0.1.10-dev.vsix.zip

[jensakejohansson]

@chadlwilson Yes, that seemed to solve it.
Also this that we did which is a smaller change: #1049
That solves our problem at least, maybe #990 solves more things. Don't care which one is merged as long as its fixed.

[chadlwilson]

Both changes would be better with an automated test that fails on windows without the change, and is made to pass with the change and thus helps us validate on older versions of VSCode which are still supported.

Neither proposed change is currently tested. Relying on maintainers to manually test across Windows and VSCode versions rather than using the automation in place is what delays getting such things fixed 😅