Created by: erichaagdev
This PR adds support for building and running tests using Gradle to the following subprojects:
- openapi-generator
- openapi-generator-core
- openapi-generator-gradle-plugin
The Maven build still exists and has been left mostly untouched. The majority of CI actions continue to build with Maven.
However, building with Gradle can be done locally. Contributors will see a noticeable improvement in build times when building with Gradle locally. In addition to incremental building, local build caching has also been configured to reduce build times even further.
Notable changes
- Several subprojects can now be built using Gradle. Just run
./gradlew build
! - A new action has been created to build and test the project with Gradle.
- Instructions for building with Gradle have been added to the project's README.
- Gradle builds have been configured to publish a Build Scan™ on CI, and optionally for local builds (opt-in feature).
- A
build-logic
folder has been created in the root project to better isolate and organize the project's build logic. Several convention plugins have been created for use throughout the project, thus keeping project build files clean. - Java Helidon functional tests have been updated to be compatible with both Maven and Gradle builds.
CI Build Scan: https://scans.gradle.com/s/jsfxijn2jz6ke
PR checklist
-
Read the contribution guidelines. -
Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community. -
Run the following to build the project and update samples: ./mvnw clean package ./bin/generate-samples.sh ./bin/utils/export_docs_generators.sh
./bin/generate-samples.sh bin/configs/java*
. For Windows users, please run the script in Git BASH. -
File the PR against the correct branch: master
(6.3.0) (minor release - breaking changes with fallbacks),7.0.x
(breaking changes without fallbacks) -
If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.