-
Task
-
Resolution: Fixed
-
L3 - Default
-
None
-
None
-
None
Problem
The test release javadocs job fails since the module distro/run/modules/example has a dependency to org.camunda.bpm.springboot:camunda-bpm-spring-boot-starter-webapp which is not produced by the reactor.
The following modules are currently not part of the Javadocs job since the distro-ce profile is not called:
[INFO] Camunda Platform - Spring Boot Starter - Webapps Core [jar] [INFO] Camunda Platform - Spring Boot Starter - Webapps [jar] [INFO] Camunda Platform - Spring Boot Starter - QA - Webapps [pom] [INFO] Camunda Platform - Spring Boot Starter - QA - Webapps Invoice Example [jar] [INFO] Camunda Platform - Spring Boot Starter - QA - Webapps Runtime [jar] [INFO] Camunda Platform - webapp - JBoss [war] [INFO] Camunda Platform - webapp - JBoss Standalone [war] [INFO] Camunda Platform - webapp - Tomcat [war] [INFO] Camunda Platform - tomcat Distro [pom] [INFO] Camunda Platform - webapp - Tomcat Standalone [war] [INFO] Camunda Platform - Run - Module Webapps [pom] [INFO] Camunda Platform - Run - Distribution [pom] [INFO] Camunda Platform - Run - QA - Runtime [jar] [INFO] Camunda Platform - Wildfly Distro [pom]
Premise
As a user, I want to understand the implementation a bit better, and as the first point of contact, I can read a bit of Javadocs before debugging directly or even checking out the source code on GitHub.
There is no hard reason why the modules above are not part of the Javadocs. The reason might be a legacy back when we had different jobs for building artifacts, the Webapps, and Distros.
Solution ideas
- Exclude distro/run/modules/example module from the release job
- Cons
- We might introduce in the future more such situations and would then maintain this list of excluded modules
- There is no hard reason for excluding these modules
- Cons
- Call maven command twice to build the missing dependency first and second generate the Javadocs
- Cons
- Bigger refactoring
- Build duration of the job grows
- Cons
- Add the distro-ce profile to the maven command
- Pro: all modules are included in the Javadocs
- Cons
- Build duration of job grows slightly
Decision
Solution #3 is the best one since it allows us to provide Javadocs that reflect our entire codebase.