-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Bug: Sam Build fails when specifying Jar location for Java Function CodeUri #4575
Comments
Looks like a workaround for now would be to use a makefile BuildMethod, like this: template.yaml
Makefile
This looks to work, though unfortunately it looks like each build happens in it's own directory, so the gradle build step is duplicated. This is seen once for each Lambda:
I could see that the make commands run out of a different directory for each Lambda:
To prevent the redundant |
This is somewhat related to #3227, as allowing developers to specify a pre-built artifact would enable whatever gradle configuration they prefer. Their CI pipeline would just need to run the appropriate gradle build steps prior to calling I feel that the current Java (gradle and maven) and even Node build processes within |
Thanks for reporting this issue @cortexcompiler , We are working on build-in-source feature, which will let customers to run their builds inside build directory, with that improvement, We also have another improvement, where you can skip to build certain functions. Which will be useful if you want to build some of the functions manually, and let others to be build by SAM CLI. For instance, if you want to build
I believe this Please let us know if you have questions. Thanks! |
Thanks for the response @mndeveci , I am not sure how "Build in source directory" would help remove the need for the
I will try out |
@mndeveci with the Java/Gradle project
This is essentially what I am looking for with the Java project. I have pre-built a minimized "Uber-Jar" and I would like it (or more specifically, the contents) put into the I have this working using the following generic Makefile and a pattern:
|
@cortexcompiler from what I understand you want to use an uber-jar plugin and want to opt out of regular
First of all, if you build all of your functions with a external tool (maven in this case), then you don't need to run But if you still want to run
This would work but as you mentioned in your 2nd comment, but this will duplicate the build by the amount of functions that you have in your template. And each build will happen in a scratch temporary directory, so any caching (or incremental build) of the underlying tool might not work. This should be fixed once we support Build in Source for Java functions (which will run For your last comment about NodeJS feature, it is only applicable for interpreted languages (NodeJS and Python) since they don't require compiling of the source code. If they define their lambda function without any dependency, then they don't need to add |
Thanks @mndeveci. I don't think Using Perhaps I could use the |
OK I think I get what you are trying to do now. For your use case, you can either use Makefile approach (which won't be super performant until build in source is completed) or you can do something like this;
Let me know if this doesn't work for your use case. |
@cortexcompiler we have also published a blog-post about how to build Serverless Java Applications using SAM CLI with different ways. I would recommend giving it a read: https://aws.amazon.com/blogs/compute/building-serverless-java-applications-with-the-aws-sam-cli/ I will be resolving this issue for now, please let us know if you have other questions. |
|
@mndeveci In what version is SkipBuild support added? I'm using 1.121, but running AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: An AWS Serverless Application Model template describing your function.
Resources:
lambda:
Type: AWS::Serverless::Function
Metadata:
SkipBuild: True
Properties:
FunctionName: "foo"
CodeUri: ./build/libs/lambda.zip
Description: lambda with zip containing libraries as dedicated jars
MemorySize: 2048
Timeout: 600
Handler: foo.Main::handleRequest
Runtime: java21
Architectures:
- x86_64
EphemeralStorage:
Size: 1024
EventInvokeConfig:
MaximumEventAgeInSeconds: 21600
MaximumRetryAttempts: 2
DestinationConfig: {}
PackageType: Zip
SnapStart:
ApplyOn: None
RuntimeManagementConfig:
UpdateRuntimeOn: Auto
VpcConfig:
SecurityGroupIds:
- sg-1
SubnetIds:
- subnet-1
- subnet-2
Ipv6AllowedForDualStack: false The SAM cli tool picks up that i'm using gradle, but fails to find a gradle build file in Even with the makefile build overtaking the actual build, deployment fails, because SAM expects that the resulting binary is a jar instead of a zip that you would deploy to actual lambda. Only the unzipping the contents into |
@cj-mantas-gridinas what happens if you run |
Yeah, that works. Problem is that it's not how the intellij plugin works. As a result, it's a nonsolution. |
Description:
I am using gradle to create an "Uber Jar" file per Lambda Function leveraging a single
gradle.build
file in the root of my project (this is similar to managing my own esbuild or webpack for node, and that does work). I am trying to point to the already created jar file similar to what I have seen in various samples, such as:https://github.com/aws-samples/aws-sam-java-rest/blob/master/template.yaml#L22
Mine looks like:
Running The aws-sample above results in this error (a Maven project):
My project results in a similar error (a Gradle project):
Steps to reproduce:
CodeUri
for anAWS::Serverless::Function
that usesRuntime: java11
.sam build
This can be done using the aws sample: https://github.com/aws-samples/aws-sam-java-rest
Observed result:
Relevant deug output:
Expected result:
The specified Jar file is moved into the
.aws-sam/build/FunctionName
directory without attempting to run a gradle buildAdditional environment details (Ex: Windows, Mac, Amazon Linux etc)
sam --version
: SAM CLI, version 1.61.0The text was updated successfully, but these errors were encountered: