-
Notifications
You must be signed in to change notification settings - Fork 0
Microsoft Azure Java Function Packaging Deploy Notes
It appears that this boils down to creation of a zip file of a similar format to (and deployed via the methods specified) here
The files (host and function.json) have references in this area of documentation: https://docs.microsoft.com/en-us/azure/azure-functions/functions-host-json
It appears the zip is an empty host.json at the top (along with project jar dependencies - external dependencies may go in a lib
folder), and a folder for each function name containing a function.json file describing it (pending verification via maven example, as package at least appears to work)
General doc about that can be found here: https://docs.microsoft.com/en-us/azure/azure-functions/functions-reference-java
Notes on an attempt to reverse engineer the build-system agnostic steps necessary to build and deploy a Java function to Azure. I started from the current maven plug-ins
The current maven plug-ins first use reflection to find annotated function entry points and parse a configuration from them. After that, they assemble some JSON files and classes into a staging directory as part of the package
step. All noted locations are relative to the specific build sub-directory created by the plug-ins for staging.
Stored in a map, keyed with a detected function's FunctionName
annotation value
entryPoint: canonical-class-name
.method-name
TODO Bindings
There are a WHOLE bunch of binding annotations it detects and creates slightly-customized JSON for the parameters
Parameter bindings: com.microsoft.azure.maven.function.bindings.BindingFactory
Same for return type bindings, but if it finds an HttpTrigger param annotation on a non-void return and no other method-level bindings, it adds an HttpBinding
Finally, if there is a StorageAccount
method binding, it applies its values as the connection for any StorageBaseBinding instances with a blank connection
Written as an empty json file
{}
Describes a single function, and written from the reflection-based data read earlier in the packaging process
TODO structure
All jars in the build directory appear to copied to the root of the staging directory
Deployment type: zip
TODO