Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-10687

Artifact versions of Camunda Spring Boot Starter must be defined multiple times in project pom

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: None
    • Icon: L3 - Default L3 - Default
    • None
    • None
    • spring-boot
    • None

      Goal
      Align the getting started experience of Camunda Spring Boot Starter to Non-Camunda Spring Boot

      What does Non-Camunda Spring Boot do?

      • If I create a Non-Camunda Spring Boot project, the getting started guide points out to add a parent to my pom.xml file [1]
      • As a user I can easily select the Spring Boot version in the parent pom section at one central point
      • This parent pom in turns has a parent which specifies sensible dependencies which could come along with my project in the dependency management section [2]

      Problem

      • The concept described above is not present for Camunda Spring Boot Starter dependencies
      • For instance, if I want to pull in the REST API as well as the Webapp, I have to specify the version twice (e. g. 3.4.0-alpha1) for each dependency even if it makes no sense to specify different dependency versions

      Solution

      • Introduce a Camunda Spring Boot Starter parent pom (or BOM) that specifies a dependency management section
      • The dependency management section should contain all artifacts that are sensible to use together with Camunda Spring Boot Starter

      Hint
      Compare BOM (Bill of Materials) and parent pom concept and choose the best.

      [1] https://docs.spring.io/spring-boot/docs/current/reference/html/getting-started-first-application.html#getting-started-first-application-pom
      [2] https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-dependencies/2.1.6.RELEASE/spring-boot-dependencies-2.1.6.RELEASE.pom

        This is the controller panel for Smart Panels app

            [CAM-10687] Artifact versions of Camunda Spring Boot Starter must be defined multiple times in project pom

            Thorben Lindhauer added a comment -

            Decision: Let's try to do this in th 7.12 cycle if we have time.

            Spontaneously I believe a BOM is better than a parent POM for the following reasons:

            • Consistent with other Camunda BOMs
            • A project can only have one parent. Requiring people to use the Camunda parent could be a limitation.

            Regarding declaration of third-party dependencies, I'm not sure yet. I see the following things:

            • If we want to be consistent with our other BOMs, we would only declare Camunda artifacts
            • Declaring the versions of transitive dependencies again is one more place we need to update in case of bumping versions
            • Maven chooses the version of a dependency that is declared "closest" to the current POM. Moving transitive dependencies "up" could override the versions from other BOMs/dependencies that the user declares. I can't currently oversee the actual impact of this, though.

            Thorben Lindhauer added a comment - Decision: Let's try to do this in th 7.12 cycle if we have time. Spontaneously I believe a BOM is better than a parent POM for the following reasons: Consistent with other Camunda BOMs A project can only have one parent. Requiring people to use the Camunda parent could be a limitation. Regarding declaration of third-party dependencies, I'm not sure yet. I see the following things: If we want to be consistent with our other BOMs, we would only declare Camunda artifacts Declaring the versions of transitive dependencies again is one more place we need to update in case of bumping versions Maven chooses the version of a dependency that is declared "closest" to the current POM. Moving transitive dependencies "up" could override the versions from other BOMs/dependencies that the user declares. I can't currently oversee the actual impact of this, though.

            Yana Vasileva added a comment -

            Review hints:

            Yana Vasileva added a comment - Review hints: As we discussed the starter-bom/pom.xml has to be adjusted to have the `camunda-bpm-release-parent` defined as a parent Do we want to set the bom as the pom.xml parent?, my feeling is we don't want to do this (because of qa) but it feels like the right moment to discuss it Do you think it makes sense to adjust the following pages as well, to remove <version>{project-version}</version> or change it to ${starter.version}? https://docs.camunda.org/manual/develop/user-guide/spring-boot-integration/rest-api/ https://docs.camunda.org/manual/develop/user-guide/spring-boot-integration/webapps/

            Thorben Lindhauer added a comment -

            After merging the spring boot starter, the artifacts are part of the platform BOM.

            Thorben Lindhauer added a comment - After merging the spring boot starter, the artifacts are part of the platform BOM.

              Unassigned Unassigned
              tassilo.weidner Tassilo Weidner
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: