Skip to content
This repository was archived by the owner on May 14, 2025. It is now read-only.
This repository was archived by the owner on May 14, 2025. It is now read-only.

Add common-security-config modules to dependency management #5485

@onobc

Description

@onobc

We are currently missing the following modules in the Dataflow dependency management (/spring-cloud-dataflow/spring-cloud-dataflow-dependencies/pom.xml)

  • spring-cloud-common-security-config-core
  • spring-cloud-common-security-config-web
  • spring-cloud-starter-common-security-config-web

Additionally, we are also using project.version as the dependency version in other modules in Dataflow, such as /spring-cloud-dataflow/spring-cloud-dataflow-server-core/pom.xml:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-common-security-config-web</artifactId>
    <version>${project.version}</version>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-common-security-config-web</artifactId>
    <version>${project.version}</version>
    <type>test-jar</type>
    <scope>test</scope>
    <exclusions>
        <exclusion>
            <groupId>org.codehaus.jackson</groupId>
            <artifactId>jackson-mapper-asl</artifactId>
        </exclusion>
    </exclusions>
</dependency>

In normal conditions this is not a problem, the Dataflow project.version is used and all is well. However, if an application extends Dataflow and pulls the above module into its build, the project version of the consuming project will be used.

Example: SCDF Pro has a reference to

<dependency>
    <groupId>com.vmware.dataflow</groupId>
    <artifactId>scdf-pro-server-core</artifactId>
</dependency>

This ends up pulling in the common-security-config-web and uses a version of 1.6.0-SNAPSHOT (which is the Pro project.version) which just so happens that the common-security-config-web has an old version number of 1.6.x and so it uses the very old 1.6.x dependencies.

Re-evaluate usage of project.version

We should also re-evaluate our usage of project.version as our version identifier. Where else could this be an issue for us?

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions