Describe the bug
When ever I try to run the sample Hello world application for java I get an error saying SAM build command failed
To reproduce

Enter configs as:

(Also tried to specify the docker network connected to java image explixitlly)

Errors out saying : Sam build command failed

Expected behavior
Function to run locally
Screenshots
Also when I right on the template.yml file and run it gives me some other error ,Exception in thread "main" java.lang.NoClassDefFoundError: org/testng/TestNG


Your Environment
Additional context
Interesting that the TestNG plugin says that the yaml is executable.
If you open the template, there are gutter icons next to the Lambda logical ID. Use that to execute instead of right clicking on the template file itself.
Interesting that the TestNG plugin says that the yaml is executable.
If you open the template, there are gutter icons next to the Lambda logical ID. Use that to execute instead of right clicking on the template file itself.
Tried that, it gives me the same: SAM build failed
Sorry, I got focused on the second half of your post.
If you click the icon above the pin (with the > on it) in the build window, you should see more info.
Sorry, I got focused on the second half of your post.
If you click the icon above the pin (with the > on it) in the build window, you should see more info.
I see, this is what I get :ValueError: path is on mount 'C:', start on mount 'D:'
Here is the complete trace :
"C:\Program Files\Amazon\AWSSAMCLI\bin\sam.cmd" build --template "D:\PersonalStuff\My Projects\tuts\bugReportTest\template.yaml" --build-dir C:\Users\sgg35\AppData\Local\Temp\lambdaBuild
2019-05-10 07:41:17 Building resource 'HelloWorldFunction'
2019-05-10 07:41:18 Running JavaMavenWorkflow:CopySource
2019-05-10 07:41:18 Running JavaMavenWorkflow:MavenBuild
2019-05-10 07:41:25 Running JavaMavenWorkflow:MavenCopyDependency
2019-05-10 07:41:28 Running JavaMavenWorkflow:MavenCopyArtifacts
Traceback (most recent call last):
File "runpy.py", line 193, in _run_module_as_main
File "runpy.py", line 85, in _run_code
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\samcli\__main__.py", line 12, in <module>
cli(prog_name="sam")
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\click\core.py", line 722, in __call__
return self.main(*args, **kwargs)
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\click\core.py", line 697, in main
rv = self.invoke(ctx)
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\click\core.py", line 1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\click\core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\click\core.py", line 535, in invoke
return callback(*args, **kwargs)
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\click\decorators.py", line 64, in new_func
return ctx.invoke(f, obj, *args[1:], **kwargs)
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\click\core.py", line 535, in invoke
return callback(*args, **kwargs)
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\samcli\commands\build\command.py", line 95, in cli
skip_pull_image, parameter_overrides) # pragma: no cover
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\samcli\commands\build\command.py", line 136, in do_cli
artifacts)
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\samcli\lib\build\app_builder.py", line 134, in update_template
artifact_relative_path = os.path.relpath(built_artifacts[logical_id], original_dir)
File "ntpath.py", line 584, in relpath
ValueError: path is on mount 'C:', start on mount 'D:'
Looks like samscli doesn't like the me have my intellij project on another drive
The template needs to swap in the code-uri to a relative path on your machine, since your build-dir and template file are on different drives (e.g. D: vs C:) that's why the SAM CLI is blowing up.
I'm a little bit confused as to why the build-dir is being passed as C:\Users.. when it seems like your workspace is on the D: drive.
The template needs to swap in the code-uri to a relative path on your machine, since your build-dir and template file are on different drives (e.g.
D:vsC:) that's why the SAM CLI is blowing up.I'm a little bit confused as to why the build-dir is being passed as
C:\Users..when it seems like your workspace is on the D: drive.
I think it builds the command by using the user's 'TEMP' environment variable , as I changed it to a proxy one in D and now it seems to work, although I am getting some other error now:
"C:\Program Files\Amazon\AWSSAMCLI\bin\sam.cmd" local invoke --template D:\Temp\lambdaBuild1\template.yaml --event "D:\Temp\[Local] HelloWorldFunction-event1.json" HelloWorldFunction
2019-05-11 09:29:44 Found credentials in environment variables.
2019-05-11 09:29:44 Invoking helloworld.App::handleRequest (java8)
Fetching lambci/lambda:java8 Docker container image......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
2019-05-11 09:31:19 Mounting D:\Temp\lambdaBuild1\HelloWorldFunction as /var/task:ro inside runtime container
START RequestId: 7f3dd81e-1176-4e30-9c2f-d717c9960576 Version: $LATEST
java.lang.ClassNotFoundException: helloworld.App
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
END RequestId: 7f3dd81e-1176-4e30-9c2f-d717c9960576
REPORT RequestId: 7f3dd81e-1176-4e30-9c2f-d717c9960576 Duration: 4.90 ms Billed Duration: 100 ms Memory Size: 128 MB Max Memory Used: 3 MB
Regardless, is there in way in the plugin where we can send the build dir explicitly , as doing it this way looks like a hack
We should probably update the toolkit so that it builds in a temporary location inside the workspace rather than the system's temp directory.
Unrelated , but if possible can someone point me to the right direction for the current error I am getting:
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
Looks like the container in docker that is pulled by aws tool kit doesn't seem to have the maven dependencies for some reason
What is in the folder " D:\Temp\lambdaBuild1\HelloWorldFunction"?
What is in the folder " D:\Temp\lambdaBuild1\HelloWorldFunction"?
It has:
HelloWorldFunction
->helloworld
->App.class
->GateResponse.class
->lib
->aws-lambda-java-core-1.2.0.jar
template.yaml
@zhangzhx Why is this still tagged response requested?
Out of curiosity, does it contain everything when you do sam build in terminal?
Out of curiosity, does it contain everything when you do
sam buildin terminal?
Yes, this is what it includes when I do that

Okay, so it is probably caused by the temp directory issues. We need to move the temp directory into the project.
@abrooksv Finally found what was causing this , I was using dockertoolbox as oppose to docker for windows.
After Following this thread for samcli :
https://github.com/awslabs/aws-sam-cli/issues/1126
I bought and upgraded to windows pro from home as docker doesn't run on windows home and then I installed docker(not toolbox).
When I ran it using docker(not toolbox) it gave me an warning that firewall was blocking docker from sharing my D drive. So I fixed that using the instructions here :
https://success.docker.com/article/error-a-firewall-is-blocking-file-sharing-between-windows-and-the-containers
Now the question is does dockertoolbox fails silently for aws sam cli incase of a firewall blocking a drive or it doesn't work at all is yet to be answered ..
For the record, the same bug also prevents the AWS Toolkit for PyCharm from working properly with projects on non-C: drives.
"C:\Program Files\Amazon\AWSSAMCLI\bin\sam.cmd" build --template D:\DEVEL\Personal\sam\test6tk\template.yaml --build-dir C:\Users\chris\AppData\Local\Temp\lambdaBuild
2019-06-24 11:43:12 Building resource 'HelloWorldFunction'
2019-06-24 11:43:13 Running PythonPipBuilder:ResolveDependencies
2019-06-24 11:43:16 Running PythonPipBuilder:CopySource
Traceback (most recent call last):
File "runpy.py", line 193, in _run_module_as_main
File "runpy.py", line 85, in _run_code
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\samcli\__main__.py", line 12, in <module>
cli(prog_name="sam")
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\click\core.py", line 722, in __call__
return self.main(*args, **kwargs)
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\click\core.py", line 697, in main
rv = self.invoke(ctx)
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\click\core.py", line 1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\click\core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\click\core.py", line 535, in invoke
return callback(*args, **kwargs)
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\click\decorators.py", line 64, in new_func
return ctx.invoke(f, obj, *args[1:], **kwargs)
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\click\core.py", line 535, in invoke
return callback(*args, **kwargs)
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\samcli\commands\build\command.py", line 103, in cli
skip_pull_image, parameter_overrides, mode) # pragma: no cover
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\samcli\commands\build\command.py", line 151, in do_cli
artifacts)
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\samcli\lib\build\app_builder.py", line 143, in update_template
artifact_relative_path = os.path.relpath(built_artifacts[logical_id], original_dir)
File "ntpath.py", line 584, in relpath
ValueError: path is on mount 'C:', start on mount 'D:'
The fix has been released in the 1.5 eap. Can you try that out? If you still see this problem, feel free to open another issue.
The issue still happens in IntelliJ. Same error! I have changed the Temp directory environmental variable to D: drive which didn't solve the issue.
````
"C:\Program Files\Amazon\AWSSAMCLI\bin\sam.cmd" build --template D:\Java\rms-serverless\template.yaml --build-dir D:\Java\rms-serverless\HelloWorldFunction.aws-sam\build --docker-network my-network-bridge HelloWorldFunction
2019-08-20 07:45:50 Building resource 'HelloWorldFunction'
2019-08-20 07:45:51 Running JavaMavenWorkflow:CopySource
2019-08-20 07:45:51 Running JavaMavenWorkflow:MavenBuild
2019-08-20 07:46:00 Running JavaMavenWorkflow:MavenCopyDependency
2019-08-20 07:46:03 Running JavaMavenWorkflow:MavenCopyArtifacts
Build Succeeded
Traceback (most recent call last):
File "runpy.py", line 193, in _run_module_as_main
File "runpy.py", line 85, in _run_code
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\samcli__main__.py", line 12, in
cli(prog_name="sam")
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\click\core.py", line 722, in __call__
return self.main(args, *kwargs)
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\click\core.py", line 697, in main
rv = self.invoke(ctx)
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\click\core.py", line 1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\click\core.py", line 895, in invoke
return ctx.invoke(self.callback, *ctx.params)
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\click\core.py", line 535, in invoke
return callback(args, *kwargs)
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\clickdecorators.py", line 64, in new_func
return ctx.invoke(f, obj, *args[1:], *kwargs)
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\click\core.py", line 535, in invoke
return callback(args, *kwargs)
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\samcli\lib\telemetry\metrics.py", line 94, in wrapped
raise exception # pylint: disable=raising-bad-type
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\samcli\lib\telemetry\metrics.py", line 65, in wrapped
return_value = func(args, *kwargs)
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\samcli\commands\build\command.py", line 105, in cli
skip_pull_image, parameter_overrides, mode) # pragma: no cover
File "C:\Program Files\Amazon\AWSSAMCLI\runtime\lib\site-packages\samcli\commands\build\command.py", line 161, in do_cli
msg = gen_success_msg(os.path.relpath(ctx.build_dir),
File "ntpath.py", line 584, in relpath
ValueError: path is on mount 'D:', start on mount 'C:'
Most helpful comment
Sorry, I got focused on the second half of your post.
If you click the icon above the pin (with the > on it) in the build window, you should see more info.