Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Java version can not be matched correctly #104

Closed
zhiyanliu opened this issue Mar 21, 2019 · 4 comments
Closed

Java version can not be matched correctly #104

zhiyanliu opened this issue Mar 21, 2019 · 4 comments

Comments

@zhiyanliu
Copy link
Contributor

Description:

sam build failed on Oracle java 12 environment (on mac).

Steps to reproduce the issue:

  1. Setup an Oracle java 12 development environment on mac. (maven and sam-cli were installed by brew)
  2. Execute sam build command in project directory.

Observed result:

$ sam build
2019-03-20 20:08:43 Building resource 'HelloWorldFunction'
Traceback (most recent call last):
File "/usr/local/bin/sam", line 11, in
load_entry_point('aws-sam-cli==0.13.0', 'console_scripts', 'sam')()
File "/usr/local/Cellar/aws-sam-cli/0.13.0/libexec/lib/python3.7/site-packages/click/core.py", line 722, in call
return self.main(*args, **kwargs)
File "/usr/local/Cellar/aws-sam-cli/0.13.0/libexec/lib/python3.7/site-packages/click/core.py", line 697, in main
rv = self.invoke(ctx)
File "/usr/local/Cellar/aws-sam-cli/0.13.0/libexec/lib/python3.7/site-packages/click/core.py", line 1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/local/Cellar/aws-sam-cli/0.13.0/libexec/lib/python3.7/site-packages/click/core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/local/Cellar/aws-sam-cli/0.13.0/libexec/lib/python3.7/site-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/usr/local/Cellar/aws-sam-cli/0.13.0/libexec/lib/python3.7/site-packages/click/decorators.py", line 64, in new_func
return ctx.invoke(f, obj, *args[1:], **kwargs)
File "/usr/local/Cellar/aws-sam-cli/0.13.0/libexec/lib/python3.7/site-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/usr/local/Cellar/aws-sam-cli/0.13.0/libexec/lib/python3.7/site-packages/samcli/commands/build/command.py", line 95, in cli
skip_pull_image, parameter_overrides) # pragma: no cover
File "/usr/local/Cellar/aws-sam-cli/0.13.0/libexec/lib/python3.7/site-packages/samcli/commands/build/command.py", line 133, in do_cli
artifacts = builder.build()
File "/usr/local/Cellar/aws-sam-cli/0.13.0/libexec/lib/python3.7/site-packages/samcli/lib/build/app_builder.py", line 99, in build
lambda_function.runtime)
File "/usr/local/Cellar/aws-sam-cli/0.13.0/libexec/lib/python3.7/site-packages/samcli/lib/build/app_builder.py", line 190, in _build_function
runtime)
File "/usr/local/Cellar/aws-sam-cli/0.13.0/libexec/lib/python3.7/site-packages/samcli/lib/build/app_builder.py", line 210, in _build_function_in_process
executable_search_paths=config.executable_search_paths)
File "/usr/local/Cellar/aws-sam-cli/0.13.0/libexec/lib/python3.7/site-packages/aws_lambda_builders/builder.py", line 110, in build
return workflow.run()
File "/usr/local/Cellar/aws-sam-cli/0.13.0/libexec/lib/python3.7/site-packages/aws_lambda_builders/workflow.py", line 46, in wrapper
valid_path = validator.validate(executable_path)
File "/usr/local/Cellar/aws-sam-cli/0.13.0/libexec/lib/python3.7/site-packages/aws_lambda_builders/workflows/java_maven/maven_validator.py", line 31, in validate
if int(jvm_mv) > 8:
ValueError: invalid literal for int() with base 10: '12, vendor: Oracle Corporation'

Expected result:

$ sam build
2019-03-21 09:03:18 Building resource 'HelloWorldFunction'
2019-03-21 09:03:19 /usr/local/bin/mvn is using a JVM with major version 12 which is newer than 8 that is supported by AWS Lambda. The compiled function code may not run in AWS Lambda unless the project has been configured to be compatible with Java 8 using 'maven.compiler.target' in Maven.
2019-03-21 09:03:19 Running JavaMavenWorkflow:CopySource
2019-03-21 09:03:19 Running JavaMavenWorkflow:MavenBuild
2019-03-21 09:07:01 Running JavaMavenWorkflow:MavenCopyDependency
2019-03-21 09:08:15 Running JavaMavenWorkflow:MavenCopyArtifacts

Build Succeeded

Built Artifacts : .aws-sam/build
Built Template : .aws-sam/build/template.yaml

Additional environment details

  1. Mac 10.14.3 (18D109)
  2. Oracle java version "12" 2019-03-19
    Java(TM) SE Runtime Environment (build 12+33)
    Java HotSpot(TM) 64-Bit Server VM (build 12+33, mixed mode, sharing)
  3. Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-25T02:41:47+08:00)
    Maven home: /usr/local/Cellar/maven/3.6.0/libexec
    Java version: 12, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk-12.jdk/Contents/Home
    Default locale: en_US, platform encoding: UTF-8
    OS name: "mac os x", version: "10.14.3", arch: "x86_64", family: "mac"

Reason

According to the code logic at [0], a regular expression is used to match the version string, it try to get out the java version number from the string after the prefix Java version:\s+, the expression assumes the version number follows the prefix and fill the rest of the string line, so in the code a * is used in the group (\d.*) which is a greedy match operator. However in my case, from my output of the mvn -version command executed by the logic at [1], you can see beside version number part vendor part is listed in the same line as well, and finally the int() call failed and ValueError exception raised up.

Solution proposal

My idea is simple, use non-greedy match in the regular expression, to replace char * by ? at [0], it works for me, the build succeeded after the hotfix in my local.

I'd like to commit the fix by a tiny PR if the solution works for you.

thanks,
zhiyan

Code link
[0] https:/awslabs/aws-lambda-builders/blob/v0.2.1/aws_lambda_builders/workflows/java_maven/maven_validator.py#L46
[1] https:/awslabs/aws-lambda-builders/blob/v0.2.1/aws_lambda_builders/workflows/java_maven/maven_validator.py#L55

@sriram-mv
Copy link
Contributor

This seems reasonable, please submit a Pr 👍

@zhiyanliu
Copy link
Contributor Author

pushed, @thesriram pls review when ok, thanks.

@lost-name
Copy link
Contributor

The same issue exists when using gradle instead of maven, and the same fix appears to work just as well.

@zhiyanliu
Copy link
Contributor Author

Nice. and close the issue due to all java related workflows have been fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants