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

Support annotations to specify function metadata #113

Open
wants to merge 1 commit into
base: 2.3.4-SNAPSHOT
Choose a base branch
from

Conversation

jdimeo
Copy link
Contributor

@jdimeo jdimeo commented Apr 1, 2021

Hello,
I've extended this plugin to support annotations to declare some function metadata on the function itself. If you think this is scope creep or don't prefer the approach/added dependency, no problem at all, but I thought I would share in case this is something that others would find useful.

The idea is that you could use a @Doc annotation (from our OSS https://github.com/ElderResearch/commons-jvm) like so:

@Doc(name = "load-data",
     value = "Loads data according to the config passed as the event")
public class LoadDataLambda implements RequestHandler<Config, String>, IsDocumented {
	@Override
	public String handleRequest(Config input, Context context) {
		...
		return "Data load complete";
	}
}

and then you don't need to specify that metadata in your POM (though you do have to declare the project as a dependency to the plugin so it can introspect the handler:

<plugin>
	<groupId>com.github.seanroy</groupId>
	<artifactId>lambda-maven-plugin</artifactId>
	<executions>
		<execution>
			<configuration>
				...
				<lambdaFunctions>
					<lambdaFunction>
						<handler>com.elderresearch.LoadDataLambda</handler>
						<lambdaRoleArn>${lambda.arn}</lambdaRoleArn>
					</lambdaFunction>
				</lambdaFunctions>
			</configuration>
		</execution>
	</executions>
	<dependencies>
		<dependency>
			<groupId>${project.groupId}</groupId>
			<artifactId>${project.artifactId}</artifactId>
			<version>${project.version}</version>
		</dependency>
	</dependencies>
</plugin>

Additionally, if the version is not specified, it will use the package's implementation version (though specifying version via ${project.version} as is possible today is just as good).

The other benefit is that one handler can introspect another (by instantiating and calling getDocumentation) to get its function name at runtime for functions that call other functions.

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

Successfully merging this pull request may close these issues.

1 participant