Hello Igniters,
We have a lot of Ignite extensions waiting to be released (e.g. aws, gce, topology-validator, ignite-spring-tx-ext etc.). I think it is a good point in time to make some kind of automation and simplify our release process for Ignite extension modules removing manual steps from it. During the investigation I've found some issues that we have: 1. Ignite extensions have their own parent pom file [2]. The code and dependency versions are fully duplicated with the Ignite parent pom [1], however, these properties must be shared for Ignite Extension project. Take a look at the <jetty.version>: - master Apache Ignite: 9.4.39.v20210325 - master Apache Ignite Extensions: 9.4.11.v20180605 2. The checkstyle configuration between these two repositories are different [3] [4]. Each of Apache Ignite and Apache Ignite Extensions projects have their own checkstyle config file, however, it must be shared the same as the maven checkstyle profile. 3. The Extensions have a dependency on the latest Apache Ignite version in the master branch (e.g. 2.13-SNAPSHOT), but without deploying it in the local repository the Extension projects can be built. It seems the latest version should be published to the maven snapshots repository [5]. 4. log4j-test.xml, tests.properties these files from the ignite-core module required to run tests and it seems they should be shared between projects also as tests resources. 5. The apache-release profile [7] from the apache parent which will prepare the sources, checksums, gpg sign is not used in the release process at all. Here are my suggestions to fix all the issues mentioned above: 1. Create the `ignite-parent` module that will be released each time with the latest release version. This module will be based on the parent/pom.xml [1]. This will allow us to share all common configurations, profiles, dependency versions and properties to the Ignite Extensions. 2. Create the `ignite-plugin-bom` bill of materials [8] module with the common Ignite dependencies required for developing a new extension. This is a common practice for companies that have their own parent pom file and can't inherit from Ignite's one (e.g. spring-boot-bom example [9] with all spring dependencies). 3. Create the additional `ignite-resources` jar file to share checkstyle configuration, resources, tests resources and etc. for the Extension project. 4. Configure Travis [10] to deploy a new snapshot version to the apache maven snapshots repository [5] each time the Ignite master branch is updated. 5. Clean up the pom.xml Extensions file from profiles and dependencies that are not required to release extensions e.g. the release profile [11]. 6. Reuse the `apache-release` profile for preparing sources of the extensions during the release. WDYT? [1] https://github.com/apache/ignite/blob/master/parent/pom.xml#L35 [2] https://github.com/apache/ignite-extensions/blob/master/parent/pom.xml#L36 [3] https://github.com/apache/ignite-extensions/blob/master/checkstyle/checkstyle.xml [4] https://github.com/apache/ignite/blob/master/checkstyle/checkstyle.xml [5] https://repository.apache.org/content/repositories/snapshots [6] https://github.com/apache/ignite-extensions/tree/master/modules/aws-ext/modules/core/src/test/config [7] https://github.com/apache/maven-apache-parent/blob/apache-24/pom.xml#L375 [8] https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms [9] https://github.com/snowdrop/spring-boot-bom/blob/sb-2.5.x/pom.xml#L31 [10] https://blog.travis-ci.com/2017-03-30-deploy-maven-travis-ci-packagecloud/ [11] https://github.com/apache/ignite-extensions/blob/master/pom.xml#L242
