spring-io / start.spring.io

https://start.spring.io

start.spring.io

This repository configures a Spring Initializr instance with a custom UI running at https://start.spring.io. The following modules are available:

• start-client: client-side assets

• start-site: server infrastructure and metadata configuration

• start-site-verification: tests to verify the validity of the metadata

Using

There is a dedicated page that describes how you can interact with the service.

Building from Source

You need Java 17 and a bash-like shell.

Building

Invoke the build at the root of the project

$ ./mvnw clean install

The project also includes a number of longer-running verification tests. They can be built and run using the verification profile:

$ ./mvnw -Pverification clean install

The project’s other tests are not included in the verification profile. All of the project’s tests can be run using the full profile:

$ ./mvnw -Pfull clean install

If building start-client fails, you may have an outdated cache that can be deleted as follows:

$ cd start-client
$ rm -rf .cache node_modules

Running the app locally

As long as you’ve built the project beforehand (in particular start-client), you can easily start the app as any other Spring Boot app:

$ cd start-site
$ ../mvnw spring-boot:run

Running the app in an IDE

You should be able to import the project into your IDE with no problems. Once there you can run the StartApplication from its main method and debug it. If you also need to work on the library, adding the initializr project in your workspace would make sure to reload the app whenever you make any change.

This is the recommended way to operate while you are developing the application, especially the UI.

Reusing the Web UI

This instance has a thin layer with our opinions about getting started with Spring Boot. You can reuse them but please keep in mind that this is not supported with the same level as the Spring Initializr library. The Web UI, in particular, is for our own purpose and is not particularly engineered to be easily extended.

Deploying to Cloud Foundry

If you are on a Mac and using homebrew, install the Cloud Foundry CLI:

$ brew install cloudfoundry-cli

Alternatively, download a suitable binary for your platform from Pivotal Web Services.

You should ensure that the application name and URL (name and host values) are suitable for your environment before running cf push.

First, make sure that you have built the application, then make sure first that the jar has been created:

$ cd start-site
$ ../mvnw package

The project creates a regular library jar and a repackaged archive that can be used to start the application with the exec classifier. Once the build as completed, you can push the application:

$ cf push your-start -p target/start-site-exec.jar

License

The start.spring.io website is Open Source software released under the Apache 2.0 license.

start.spring.io's Issues

Upgrade to Kotlin 1.2.71

Considering the upgrade in the upcoming 2.0.7, let's align our version strategy here as well.

Enhance CI pipeline

• Build Pull Requests
• Add slack notifications
• Trigger true based on changes to git-repo

Upgrade to Spring Cloud Open Service Broker 2.1.1

A generated project from start.spring.io that has a single dependency to Open Service Broker does not compile

Reproduce

Create a new spring boot application with the following settings:
Project: Gradle
Language: Java
Spring Boot: 2.1.3
Packaging: Jar
Java Version: 11
Dependencies: Open Service Broker

Expected behavior:

A generated project that compiles when running ./gradlew clean build

Actual behavior

error: package org.springframework.boot does not exist
import org.springframework.boot.SpringApplication

Why?

The dependency implementation 'org.springframework.boot:spring-boot-starter' is missing from the generated build.gradle file

Generated build.gradle from the above steps:

dependencies {
	implementation 'org.springframework.cloud:spring-cloud-starter-open-service-broker-webmvc:2.1.0.RELEASE'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

Generated build.gradle when creating a project without any dependencies:

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

When implementation 'org.springframework.boot:spring-boot-starter' has been added manually to build.gradle everything compiles as expected.

Update the name of the "Spring Cloud GCP" dependency group to be consistent with other IaaS providers

Currently, in the dependency listings there are no other groups that contain the "Spring" name, except for Spring Cloud GCP. To be consistent with the other groups and other listed IaaS providers, change the "Spring Cloud GCP" to Google Cloud Platform". This group should also be found by the searcher when only searching "GCP" as well.

Add stub class extending Azure adapter AzureSpringBootRequestHandler when both Cloud Function and Azure Support added

The dependencies to look for during the automated verification could be: Azure Support + Spring Cloud Function starter. In this case a class stub extending org.springframework.cloud.function.adapter.azure.AzureSpringBootRequestHandler could be added. Working stub available here.

It could also contain a stub of an execute(...) method as in the example with the annotations, like below, but this might be too much auto-generated code, so should probably be discussed by the teams:

@FunctionName("uppercase")
	public Bar execute(
			@HttpTrigger(name = "req", methods = { HttpMethod.GET,
					HttpMethod.POST }, authLevel = AuthorizationLevel.ANONYMOUS) Foo foo,
			ExecutionContext context) {
		return handleRequest(foo, context);
	}

Upgrade to Azure Spring 2.1.2 and 2.0.10

See microsoft/azure-spring-boot#534

Set spring.application.name in application.properties

Use Gradle 5 with projects that use Java 11

Officially, it's only Gradle 5 that will support Java 11. When it's released (and when we know Boot's plugin and the dependency management plugin are compatible with it), we should use Gradle 5 with Java 11-based projects.

Update tests following switch to ext { in library

Related to this issue.

Review entries metadata

To provide a consistent experience in the UI, a review of the current entries is in order. A large number of entries do not have links at the moment and we could improve the developer experience with them via HELP.md.

Fix description of Open Service Broker

It says "Open Server Broker" rather than "Open Service Broker"

Spring Cloud Function not importing BOM correctly

The BOM is there now, but the spring-cloud.version property is missing, so the dependency management isn't working.

Add a dependency on spring-restdocs-webtestclient rather than spring-restdocs-mockmvc when using WebFlux or Jersey

When creating a project with webflux and restdocs, I expect a dependency to spring-restdocs-webtestclient to be added to the project. But instead, a dependency to spring-restdocs-mockmvc is added.

Remove Keycloak from starters

The Keycloak starter is not getting enough attention; compatibility issues are very much present on current Spring Boot versions, while they're about to be EOL'd in favor of newer 2.x releases.
Also, start.spring.io is not receiving timely updates for new releases, which makes it hard for developers to create projects with up-to-date dependencies.

After discussing this, the team decided to remove this entry from the starters list, as we don't feel this starter is a safe choice to create maintainable Spring Boot applications.

Fix lombok setup

Now that we can use annotationProcessor(spring-io/initializr#848) we should switch to that and fix Lombok's special case, see the documentation.

See also #4

Enable concourse build

Upgrade to Spring Cloud Open Service Broker 2.1.0

Add support for RESTEasy

I'd like the RESTEasy starter (https://github.com/resteasy/resteasy-spring-boot) to be integrated in start.spring.io; the project was initially created at PayPal (https://github.com/paypal/resteasy-spring-boot) and then donated to Red Hat, where it's currently maintained by the same team (currently reporting to me) of the RESTEasy core.
The most recent release of the starter pulls Spring Boot 2.0.3.RELEASE and RESTEasy 3.6.0.Final (released on June 29th); on master we're already pulling the latest SpringBoot (2.0.4) and RESTEasy core (3.6.1.Final, released yesterday) and we definitely want to stay in synch in the future.
Please tell which additional information / action from our side you need. Thanks.

UI dark mode support

Is this anyway to enable 2nd new UI as dark mode

Update the "Cloud AWS" group listing to Amazon Web Services

To create consistency with the other IaaS groups, change the "Cloud AWS" group to Amazon Web Services". This group should additionally be found by the searcher when if the user types "AWS".

Add platform section to HELP.md if cloud-function selected

Update devtools with gradle to use a custom configuration

See spring-projects/spring-boot#14451 for details.

Restore parallel execution of integration tests

We can't run them in parallel at the moment as there is a concurrent request to download the wrapper and that leads to corrupted zip file.

There might be a way to prepare the right wrapper version so that they aren't downloaded on CI.

Keycloak does not work out of the box with Boot 2.1 and requires bean definition overriding to be enabled

We should consider disabling Keycloak as an option when using Boot 2.1 until https://issues.jboss.org/browse/KEYCLOAK-8725 has been fixed.

Add support for Spring Cloud Function with AWS

The dependencies to look for during the automated verification could be: spring-cloud-function-adapter-aws + a Spring Cloud Function starter. In this case AWS-specific setup for Function could be added to build files.

For pom.xml entries in dependencies:

<dependencies>
	<dependency>
		<groupId>org.springframework.cloud</groupId>
		<artifactId>spring-cloud-function-adapter-aws</artifactId>
	</dependency>
	<dependency>
		<groupId>com.amazonaws</groupId>
		<artifactId>aws-lambda-java-events</artifactId>
		<version>${aws-lambda-events.version}</version>
		<scope>provided</scope>
	</dependency>
	<dependency>
		<groupId>com.amazonaws</groupId>
		<artifactId>aws-lambda-java-core</artifactId>
		<version>1.1.0</version>
		<scope>provided</scope>
	</dependency>
</dependencies>

<dependencyManagement>
	<dependencies>
		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-function-dependencies</artifactId>
			<version>${spring-cloud-function.version}</version>
			<type>pom</type>
			<scope>import</scope>
		</dependency>
	</dependencies>
</dependencyManagement>

• I understand we will have to provide a better versioning mechanism here (a bom?), but I would wait with working out the details of that till and if it's agreed that this new functionality will be added at all. If the user is going to use functions on AWS, they will most likely require these dependencies to create a sensible project.

and plugin changes:

<build>
	<plugins>
		<plugin>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-maven-plugin</artifactId>
			<dependencies>
				<dependency>
					<groupId>org.springframework.boot.experimental</groupId>
					<artifactId>spring-boot-thin-layout</artifactId>
					<version>${wrapper.version}</version>
				</dependency>
			</dependencies>
		</plugin>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-shade-plugin</artifactId>
			<configuration>
				<createDependencyReducedPom>false</createDependencyReducedPom>
				<shadedArtifactAttached>true</shadedArtifactAttached>
				<shadedClassifierName>aws</shadedClassifierName>
			</configuration>
		</plugin>
	</plugins>
</build>

This is to ensure that we don't generate and send over to Lambda the typical SpringBoot fatjars, but much ligher jars, appropriate for the serverless approach.

For gradle, we would also have additional dependencies:

compile("org.springframework.cloud:spring-cloud-function-adapter-aws:${springCloudFunctionVersion}")
compileOnly("com.amazonaws:aws-lambda-java-events:${awsLambdaEventsVersion}")
compileOnly("com.amazonaws:aws-lambda-java-core:${awsLambdaCoreVersion}")

and plugin setup:

buildscript {
    dependencies {
        classpath "com.github.jengelman.gradle.plugins:shadow:${shadowVersion}"
		classpath("org.springframework.boot.experimental:spring-boot-thin-gradle-plugin:${wrapperVersion}")
	}
}

apply plugin: 'com.github.johnrengelman.shadow'
apply plugin: 'org.springframework.boot.experimental.thin-launcher'

shadowJar {
  classifier = 'aws'
  dependencies {
    exclude(dependency("org.springframework.cloud:spring-cloud-function-web:${springCloudFunctionVersion}"))
  }
  // Required for Spring
  mergeServiceFiles()
  append 'META-INF/spring.handlers'
  append 'META-INF/spring.schemas'
  append 'META-INF/spring.tooling'
  transform(PropertiesFileTransformer) {
    paths = ['META-INF/spring.factories' ]
    mergeStrategy = "append"
  }
}

This is to ensure that we don't generate and send over to Lambda the typical SpringBoot fatjars, but much ligher jars, appropriate for the serverless approach.

• again, approach to versioning to be proposed once a decision is taken if we are going to work on it or not.
  Handling it for the regular dependencies shouldn't be a problem, however, we would have to think how we could handle it for the gradle plugins, since the buildscript dependencies will probably not work with dependency management.

Full setup here.

Add stub class extending AWS adapter SpringBootRequestHandler when both Cloud Function and Cloud AWS added

The dependencies to look for during the automated verification could be: spring-cloud-function-adapter-aws + spring-cloud-starter-function-webflux. In this case a class stub extending org.springframework.cloud.function.adapter.aws.SpringBootRequestHandler could be added. Working stub available here.

Add Spring Java Format to the build

Incorrect version of Spring Cloud GCP for Spring Boot 2.1

Ever since Greenwich.M1 Spring Cloud GCP is part of the Spring Cloud BOM, and doesn't need its own BOM to be included in dependency management. In addition, there's a problem with the generated pom.xml currently, where 1.0.0.RELEASE is always selected for spring-cloud-gcp.

If I select Spring Boot 2.1, I get

<spring-cloud-gcp.version>1.0.0.RELEASE</spring-cloud-gcp.version>
<spring-cloud.version>Greenwich.M1</spring-cloud.version>

which is clearly wrong because, the only version of Spring Cloud GCP that is compatible with SB 2.1 is 1.1.0.M2.

If someone is using SB 2.0, however, the current behavior is fine.

cc: @saturnism @snicoll

Gradle project for Spring Boot 1.5.x with Lombok defines dependency twice

curl start.spring.io/build.gradle -d dependencies=lombok -d bootVersion=1.5.19.RELEASE

results in:

...
dependencies {
	compile 'org.springframework.boot:spring-boot-starter'
	compileOnly 'org.projectlombok:lombok'
	compileOnly 'org.projectlombok:lombok'
	testCompile 'org.springframework.boot:spring-boot-starter-test'
}

Remove Java 10 entry as it has been superseded

Java 10 has been superseded by Java 11 so we shouldn't offer an entry for it.

Upgrade Spring Boot 2.2+ to Kotlin 1.3

Improve search so that matching tokens in the name take precedence over matching in the group

We use the name of the group as a search token. Let's assume that you have a group named Foo and an entry (anywhere) named My FooLib.

Right now if I type foo, My FooLib isn't first because all entries of the Foo group matched and the result list depends on the order of declaration.

We should put MyFooLib at the top here since it's a better match for such query.

Use new `annotationProcessor` scope

Our service has two AP: Lombok and the configuration processor. Rather than compileOnly we should use the new annotationProcessor scope (see #653)

Before we do, we should check that Gradle-friendly IDEs do detect such setup. A quick check with IntelliJ IDEA seems to indicate it doesn't.

Add support for Spring Rest Docs build configuration

I've been creating a multitude of small Spring Boot microservices lately, and every time when I start from a Spring Initializr project, I miss the Maven/Gradle build configuration for Spring Rest Docs. It would be very handy to have this already included in the POM (or Gradle build file), as described here: http://docs.spring.io/autorepo/docs/spring-restdocs/1.0.0.RC1/reference/html5/#getting-started-build-configuration-maven-packaging

Warn when mixing milestone and GA releases

Originally raised at spring-projects/spring-boot#12651

---

On start.spring.io, if I ask to create a project using Spring Boot 2.0.0, I have the option of adding the Gateway dependency (part of Cloud Routing). The generated pom has the version set (via the spring-cloud.version property) to Finchley.M9.

I was under the impression that by asking for a starter project based off of an official release, I would only get officially released versions. It was only after I started digging into an issue that I realized I had been given a pom with milestone dependencies in it.

I would suggest some sort of indication on the page when a non-GA version dependency is selected while creating a project based off of a GA of spring-boot.

Revisit dependency categories

The current metadata for available starters lists many dependencies, each containing a list of starters.

The current list of dependency groups is not well balanced and too large (20 groups):

• Core
• Web
• Template Engines
• SQL
• NoSQL
• Messaging
• Cloud Core
• Cloud Config
• Cloud Discovery
• Cloud Routing
• Cloud Circuit Breaker
• Cloud Tracing
• Cloud Messaging
• Cloud AWS
• Cloud Contract
• Pivotal Cloud Foundry
• Azure
• Social
• I/O
• Ops

We could add a new metadata layer to regroup related dependencies under "profiles/categories". For example, Spring Cloud related deps, Cloud platforms deps, could be regrouped under their own category/profile. Currently it's rather easy to mix those when they're not addressing the same use cases.

This could help drive improvements in the UI and new features, as the current structure is rather flat and forces the user to consider all these at the same level.

Note that a new level in the metadata is not strictly required, we could derive those categories from tags added to each dependency list.

Upgrade to spring-javaformat 0.0.9

Remove dedicated version management for Spring Cloud Task

This project is part of the release train so we shouldn't need a dedicated version management for it.

Remove Legacy STS support

We can remove this once this is done.

Upgrade to Vaadin 11.0.2

This version is compatible with Spring Boot 2.1

Display generated build file (pom.xml / gradle.build)

It will be good if u will provide an ability to download only pom.xml (or just render it) without generating all files

Upgrade to Azure Spring 2.0.8

I just generated a Spring Boot 2.1.1 project with the Azure starter in Maven. However, the version for the Azure starter that was used was 2.0.5 (via the azure.version property):

<azure.version>2.0.5</azure.version>

However, the correct version should be 2.1.0 (and soon 2.1.1). And it looks like for Spring Boot 2.0, the latest Azure version is 2.0.8.

How do Azure folks, et al, communicate their new releases?

Add Spring Cloud Alibaba

Well-established project with a vibrant community

The git repo is at : https://github.com/spring-cloud-incubator/spring-cloud-alibaba
currently there are 776 forks and 3469 stars. We have several active maintainers addressing the issues raised by the community.

Licence

Apache 2.0

Issue Tracker URL

https://github.com/spring-cloud-incubator/spring-cloud-alibaba/issues

Continuous integration

https://circleci.com/gh/spring-cloud-incubator/spring-cloud-alibaba/tree/master

Maven Central

spring-cloud-starter-alibaba-nacos-config

spring-cloud-starter-alibaba-nacos-config-server

spring-cloud-starter-alibaba-nacos-discovery

spring-cloud-starter-alibaba-sentinel

spring-cloud-starter-stream-rocketmq
spring-cloud-starter-bus-rocketmq

spring-cloud-starter-alicloud-oss

spring-cloud-starter-alicloud-acm

spring-cloud-starter-alicloud-ans

spring-cloud-starter-alicloud-schedulerx

spring-cloud-starter-alicloud-sms

Configuration metadata

via maven dependency spring-boot-configuration-processor and file additional-spring-configuration-metadata.json

Version mappings

version 0.2.1.RELEASE is compatible with the Spring Cloud Finchley, that is to say,compatible with Spring Boot 2.0.x.

Version 0.1.1.RELEASE is compatible with the Spring Cloud Edgware, that is to say, compatible with Spring Boot 1.5.x.

Links to additional resources

Sentinel: https://github.com/alibaba/sentinel
Nacos: https://github.com/alibaba/nacos
RocketMQ: https://github.com/apache/rocketmq
Alibaba Cloud: https://www.alibabacloud.com

Add OAuth2 client and resource server starters

Please add

• https://github.com/spring-projects/spring-boot/tree/v2.1.0.RELEASE/spring-boot-project/spring-boot-starters/spring-boot-starter-oauth2-client
• https://github.com/spring-projects/spring-boot/tree/v2.1.0.RELEASE/spring-boot-project/spring-boot-starters/spring-boot-starter-oauth2-resource-server

Generate "src/main/resources/db/migration" structure for Flyway projects

Out-of-the-box, the ApplicationTests.contextLoads() test will fail with a generated project that uses Flyway because there's no default migration file.

Adding an empty V1__init.sql file into the resources/db/migration directory would make that test pass and be a nicer experience.

Add Okta OAuth 2/OIDC wrapper

NOTE: This library wraps the existing Spring Security/Boot OAuth lib and the following:

• Simplified configuration by using okta.oauth2.issuer, okta.oauth2.client-id and okta.oauth2.client-secret (which are remapped to the Spring Security equivalent)
• Improved access token JWT validation (Okta specific)
• Allows for mapping of an access token groups claim to Authorities

Requirements

To ensure the ongoing health of the Spring Boot community, a starter that is included on
start.spring.io must meet the following requirements.

Code of Conduct

This project adheres to the Contributor Covenant code of conduct. By participating, you
are expected to uphold this code.

👍 Do we need to include a copy in our repo?

Well-established project with a vibrant community

To avoid overwhelming users with too much choice, we aim for each starter to be of
interest to a broad range of start.spring.io's users. One way to ensure this is for each
starter to represent a well-established project with a vibrant community.

Please provide some links that provide some evidence for this. We're looking for
things like GitHub stars, multiple contributors, ongoing maintenance, Stack Overflow
questions, etc.

• https://github.com/okta/okta-spring-boot/graphs/contributors
• https://stackoverflow.com/search?tab=newest&q=okta%20spring

Licence

Please provide details of your project's licence. If you starter pulls in any
dependencies with a different license to the starter's own licence, please provide
details of those dependencies' licences as well.

This lib is Apache 2.0, for non direct Spring dependencies we use slf4j (MIT), and we have an optional dependency on Okta's management SDK, which contains Apache 2.0 compatible dependencies: https://github.com/okta/okta-sdk-java/blob/master/THIRD-PARTY-NOTICES

Issue Tracker URL

To allow users of your starter to contribute and provide feedback, please provide
the URL of its issue tracker.

• https://github.com/okta/okta-spring-boot/issues

Continuous integration

To help to ensure the ongoing compatibility of your starter with Spring Boot, please
provide a link to the CI jobs that verify its compatibility. Compatibility should
be achieved using Spring Boot's dependency management without overriding.

Project CI:

• https://travis-ci.org/okta/okta-spring-boot

Samples CI (Spring BOM based):

• https://travis-ci.org/okta/samples-java-spring

Maven Central

Third-party starters that are included on start.spring.io must be available on Maven
Central.

• Starter and all of its dependencies are available on Maven Central.

https://search.maven.org/artifact/com.okta.spring/okta-spring-boot-starter/1.0.0/jar

Configuration metadata

If you starter provides @ConfigurationProperties it should provide metadata for those
properties to enable auto-completion in the IDE. Metadata can be provided by adding
field level documentation on each of the properties and adding the
spring-boot-configuration-processor to your build.

• Starter provides metadata, including documentation, for all its configuration
  properties.

Version mappings

Spring Initializr allows different versions of a starter to be used with different
versions of Spring Boot. For example, if a project is being generated with Spring
Boot version W you may want to use Starter version X and if a project is being
generated with Spring Boot version Y you may want to use Starter version Z.

Please provide the details of any mappings between particular version of Spring
Boot and particular versions of your starter.

Currently just supporting Spring Boot 2.1+ (we had previous versions that used the older spring oauth lib, but adding that would likely cause confusion)

Links to additional resources

Each entry can be associated with one or several links. Please provide at least a link to
a sample and the reference documentation:

• Reference documentation: https://github.com/okta/okta-spring-boot/blob/master/README.md
• Sample:
  • Standard OAuth 2 Redirect
  • OAuth 2 login with custom login page
  • OAuth 2 Resource Server

Override outdated Spring Kafka version with Spring Boot 1.5.x

Spring Boot 1.5.x pulls in spring-kafka 1.1.x which is no longer supported; the preferred version for Boot 1.5.x is spring-kafka 1.3.x (currently 1.3.8).

See the project page.

It would be preferable if initializr could override the version rather than each user having to do it manually.

Mark Spring Cloud Netflix projects as maintenance mode

Information about the tools being in maintenance mode should be added to the help.md file.

Add Spring Cloud Contract Verifier Plugin when the user has added Cloud Contract Verifier

Spring Cloud Contract Verifier Plugin should be automatically added to the build setup whenever user has selected Spring Cloud Contrac Verifier.

For pom.xml:

<plugin>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-contract-maven-plugin</artifactId>
	<version>${spring-cloud-contract.version}</version>
	<extensions>true</extensions>
</plugin>

For build.gradle:

buildscript {
	dependencies {
		classpath "org.springframework.cloud:spring-cloud-contract-gradle-plugin:${verifier_version}"
	}
}

apply plugin: 'spring-cloud-contract'

This might require keeping information on the verifier version somewhere apart (maybe here), since the dependencies within buildscript probably will not work with dependencyManagement.

Change build setup when both Cloud Function and Azure added

The dependencies to look for during the automated verification could be: spring-cloud-function-adapter-azure + a Spring Cloud Function starter. In this case, Azure-specific setup for Function could be added to build file.

For pom.xml, we would need this dependency:

<dependencies>
	<dependency>
		<groupId>org.springframework.cloud</groupId>
		<artifactId>spring-cloud-function-adapter-azure</artifactId>
	</dependency>
</dependencies>

<dependencyManagement>
<dependencies>
	<dependency>
		<groupId>org.springframework.cloud</groupId>
		<artifactId>spring-cloud-function-dependencies</artifactId>
		<version>2.0.0.BUILD-SNAPSHOT</version>
		<type>pom</type>
		<scope>import</scope>
	</dependency>
</dependencies>
</dependencyManagement>

We would also need specific setup for the following plugins: maven-clean-plugin, maven-resources-plugin, azure-functions-maven-plugin, maven-deploy-plugin, maven-dependency-plugin:

<build>
		<pluginManagement>
			<plugins>
				<plugin>
					<groupId>org.apache.maven.plugins</groupId>
					<artifactId>maven-clean-plugin</artifactId>
					<configuration>
						<filesets>
							<fileset>
								<directory>${basedir}</directory>
								<includes>
									<include>obj/**</include>
								</includes>
							</fileset>
							<fileset>
								<directory>${basedir}</directory>
								<includes>
									<include>extensions.csproj</include>
								</includes>
							</fileset>
						</filesets>
					</configuration>
				</plugin>
				<plugin>
					<artifactId>maven-resources-plugin</artifactId>
					<version>3.0.2</version>
				</plugin>
				<plugin>
					<groupId>com.microsoft.azure</groupId>
					<artifactId>azure-functions-maven-plugin</artifactId>
					<version>1.0.0-beta-7</version>
					<dependencies>
						    <dependency>
								<groupId>javax.xml.bind</groupId>
								<artifactId>jaxb-api</artifactId>
								<version>2.3.1</version>
							</dependency>
					</dependencies>
				</plugin>
			</plugins>
</pluginManagement>

Add necessary jaxb-api dependency for the Azure Functions Maven plugin. Set up the Maven Clean plugin, to take into account the locations of the generated Azure-specific files.

<plugins>
   <plugin>
   	<groupId>org.apache.maven.plugins</groupId>
   	<artifactId>maven-dependency-plugin</artifactId>
   	<executions>
   		<execution>
   			<id>copy-dependencies</id>
   			<phase>prepare-package</phase>
   			<goals>
   				<goal>copy-dependencies</goal>
   			</goals>
   			<configuration>
   				<outputDirectory>${stagingDirectory}/lib</outputDirectory>
   				<overWriteReleases>false</overWriteReleases>
   				<overWriteSnapshots>false</overWriteSnapshots>
   				<overWriteIfNewer>true</overWriteIfNewer>
   				<includeScope>runtime</includeScope>
   			</configuration>
   		</execution>
   	</executions>
   </plugin>
   <plugin>
   	<groupId>com.microsoft.azure</groupId>
   	<artifactId>azure-functions-maven-plugin</artifactId>
   	<configuration>
   		<resourceGroup>${functionResourceGroup}</resourceGroup>
   		<appName>${functionAppName}</appName>
   		<region>${functionAppRegion}</region>
   		<appSettings>
   			<property>
   				<name>FUNCTIONS_EXTENSION_VERSION</name>
   				<value>beta</value>
   			</property>
   			<property>
   				<name>MSDEPLOY_RENAME_LOCKED_FILES</name>
   				<value>1</value>
   			</property>
   		</appSettings>
   	</configuration>
   	<executions>
   		<execution>
   			<id>package-functions</id>
   			<goals>
   				<goal>package</goal>
   			</goals>
   		</execution>
   	</executions>
   </plugin>
   <plugin>
   	<artifactId>maven-resources-plugin</artifactId>
   	<executions>
   		<execution>
   			<id>copy-resources</id>
   			<phase>package</phase>
   			<goals>
   				<goal>copy-resources</goal>
   			</goals>
   			<configuration>
   				<overwrite>true</overwrite>
   				<outputDirectory>
   					${project.build.directory}/azure-functions/${functionAppName}
   				</outputDirectory>
   				<resources>
   					<resource>
   						<directory>${project.basedir}/src/main/azure</directory>
   						<includes>
   							<include>**</include>
   						</includes>
   					</resource>
   				</resources>
   			</configuration>
   		</execution>
   	</executions>
   </plugin>
   <plugin>
   	<groupId>org.springframework.boot</groupId>
   	<artifactId>spring-boot-maven-plugin</artifactId>
   	<dependencies>
   		<dependency>
   			<groupId>org.springframework.boot.experimental</groupId>
   			<artifactId>spring-boot-thin-layout</artifactId>
   			<version>${wrapper.version}</version>
   		</dependency>
   	</dependencies>
   </plugin>
</plugins>

We add the Azure Functions plugin that will generate the function.json files necessary to run the functions in the cloud and will scan the build output directory and copy any jars from there to the staging directory (${project.basedir}/target/azure-functions/${function-app-name}/ by default). We confiugre it with the sepcific resource group, appName and region (possibly placeholders only to be overwritten by the user?). We then use the Maven Dependencies and Maven Resources plugins to copy the dependencies and resources to the Azure staging directory as well. We could also add config for the maven-deploy-plugin to skip the usual maven deployment.

We will probably have to provide a better versioning mechanism here (a bom?), but I would wait with working out the details of that till and if it's agreed that this new functionality will be added at all.

Full setup available here.