add customFields to InitializrConfiguration

[JoarVarpe]

The customFields feature in Spring Initializr empowers users to define additional metadata beyond the standard options, offering a high degree of flexibility and adaptability. This feature allows organizations to configure values unique to their specific environments—such as default project configurations, organizational dependencies, version control requirements, deployment targets, and other custom options—thereby enabling projects generated by Initializr to seamlessly align with their internal standards and practices.

With customFields, organizations can dynamically add new metadata properties without the need to alter the core configuration, avoiding the overhead of modifying the base metadata structure whenever new requirements arise. This flexibility extends Spring Initializr’s usability, making it more responsive to evolving business needs and diverse project types. For instance, organizations can use customFields to incorporate information specific to internal workflows, compliance protocols, testing guidelines, or infrastructure requirements, injecting tailored configurations directly into newly generated projects.

By streamlining custom configuration management, customFields enhances Initializr’s adaptability and ensures it can support a broader range of use cases—providing value to organizations that rely on Initializr to maintain consistent, standardized, and easily configurable project setups across development teams.

[pivotal-cla]

@JoarVarpe Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

[pivotal-cla]

@JoarVarpe Thank you for signing the Contributor License Agreement!

[mhalbritter]

Hello!

This feature essentially tunnels the data from the config file over the /metadata/config endpoint to the client.

What is your use case for this?

[JoarVarpe]

Hi!

In our company we are using a custom initializr to create projects and provide example code for usage, and has immensely increased the userfriendliness of our project generation. Due to company policies and security requirements we use our own libraries in addition to several other dependencies and would like to be able to arrange the dependencies, in different packages that the user can select for convenient development and quick setup. This has proved a challenge as it stands now, and the current solution requires band-aid solutions of duplicating code, and the logic supporting selection of packages has to be done in the front-end instead of the back-end, which overall is an unsatisfying solution. In addition to this we have platform related variables that we would like to be able to send to the frontend for potential selection and use in generation in the backend, this too currently needs duplication of variables instead of being able to send the data and use it in the frontend.

In the case that the solution provided is not an option, a better way of achieving this functionality would be greatly appreciated, as we really do like the initializr and wish to use it.

[mhalbritter]

we use our own libraries in addition to several other dependencies and would like to be able to arrange the dependencies, in different packages that the user can select

Right now, the initializr supports grouping the dependencies, for example "Spring Web" and "Spring for GraphQL" are both in the "Web" group on start.spring.io. Do you need more grouping functionality or what exactly is it that you need?

nd the logic supporting selection of packages has to be done in the front-end instead of the back-end

How would this pull request move the selection from the packages from the frontend to the backend?

In addition to this we have platform related variables that we would like to be able to send to the frontend for potential selection and use in generation in the backend

Those variables are not tied to a dependency? Those are global variables which are just sent from backend to the frontend? What is the use case of those variables?

[JoarVarpe]

Right now, the initializr supports grouping the dependencies, for example "Spring Web" and "Spring for GraphQL" are both in the "Web" group on start.spring.io. Do you need more grouping functionality or what exactly is it that you need?

Yeah, the grouping is fantastic currently, what i mean by package is that we have example code that depends on multiple dependencies to work out of the box. For working example code example1 that needs dep1, dep2 and dep3 we currently use a way of selecting where you packageName1 is sent to the frontend as a dependency, and when selected, dep1, dep2 and dep3 is also selected. Before the call to the backend is sent, packageName1 and all other "packages" are filtered out for the generation call.

How would this pull request move the selection from the packages from the frontend to the backend?

This pull request in its entirety would not move the selection from the packages from the frontend to the backend, but by defining packages or another describing name in the application.yaml it would be possible to put packageName1 with the list of dependencies dep1, dep2 and dep3 underneath. This would then be the only place these are defined and references to this would be used instead of defining them again in the frontend as we currently do.

Those variables are not tied to a dependency? Those are global variables which are just sent from backend to the frontend? What is the use case of those variables?

No, those variables are not tied to a dependency, but we still wish to be able to send our own variables to the frontend to be able to generate projects where these are already integrated by default. The use case of these variables are for instance deciding which pipeline to build with and deciding where the project will be running.

[mhalbritter]

selecting where you packageName1 is sent to the frontend as a dependency, and when selected, dep1, dep2 and dep3 is also selected. Before the call to the backend is sent, packageName1 and all other "packages" are filtered out for the generation call.

This is somewhat similar to the "native" dependency on start.spring.io. Users can select it, we can react to it (see this code) and before the project generation we remove it (see this code). But this all happens in the backend.

Maybe an approach like this would be suitable for you? In your case, you could define those packages, then write some code with @ConditionalOnRequestedDependency which adds the real dependencies, and then a customizer which removes the package again.

[mhalbritter]

No, those variables are not tied to a dependency, but we still wish to be able to send our own variables to the frontend to be able to generate projects where these are already integrated by default. The use case of these variables are for instance deciding which pipeline to build with and deciding where the project will be running.

That means you have multiple instances of your initializr deployed where those custom fields are set to different values in each instance?

[JoarVarpe]

This is somewhat similar to the "native" dependency on start.spring.io. Users can select it, we can react to it (see this code) and before the project generation we remove it (see this code). But this all happens in the backend.

Maybe an approach like this would be suitable for you? In your case, you could define those packages, then write some code with @ConditionalOnRequestedDependency which adds the real dependencies, and then a customizer which removes the package again.

Thank you for the suggestion! It would definitely cover the functional aspect with regards to the generated project. However, we're also aiming to ensure that users clearly see the included dependencies when they select the package. This approach might lead to similar issues we're currently facing, but I'm open to any ideas that might address both goals.

[JoarVarpe]

That means you have multiple instances of your initializr deployed where those custom fields are set to different values in each instance?

No, we use one instance of our initializr, but we would like to be able to send our variables to the frontend, so that the user may choose to include them or not

[mhalbritter]

However, we're also aiming to ensure that users clearly see the included dependencies when they select the package.

Ah, I see. Maybe some feature in the metadata for composite dependencies would help.

No, we use one instance of our initializr

Your initializr is a custom Spring Boot application, I guess. Why don't you add your own custom controller and return the custom fields for your frontend in your application?

I'll flag this for our next team meeting to discuss it.

[mhalbritter]

Hey,

thanks for the PR and for the discussion. However, we feel that having an untyped map in the configuration is too broad scoped for initializr. I suggest you add your own custom controller for your use case. We can also think about adding an extension point where you can hook into to modify /metadata/config. Does the custom controller works for you?