0

While defining a dependency in maven I am using a dot in groupId shown as below:

<dependency>
            <groupId>sample.group.id.</groupId>
            <artifactId>sample</artifactId>
            <version>1.2.0</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>sample.group.id.</groupId>
            <artifactId>sample</artifactId>
            <version>1.2.3</version>
            <scope>compile</scope>
        </dependency>

PS: I am doing this as I want to use multiple version of same dependency for test and compile scope which is now not supported in maven3

But due to the additional dot in the groupId the generated URL becomes incorrect as an extra slash is added(dot is converted to slash) Any idea how can I not let the dot convert to slash in the generated URL

techAdi
  • 11
  • 1
  • I tried using the trick mentioned in this question: https://stackoverflow.com/questions/24962607/multiple-versions-of-the-same-dependency-in-maven – techAdi Mar 30 '22 at 08:04
  • This is a horrible trick. Why do you want to load these two versions in the first place? What is the motivation behind this? We will find a better solution for you if you explain your reasons. – J Fabian Meier Mar 30 '22 at 08:13
  • @J Fabian Meier: version 2.10.5.1 of jackson-databind has security vulnerability because of which we need to upgrade it to 2.13.2.1 but this version of jackson-databind is not compatible with existing Kafka version and other dependency also. We tried bringing all dependencies to latest version also but that too is giving some error. So finally we decided to go with the approach where we will have two versions of same dependency one for test and one for compile. – techAdi Mar 30 '22 at 09:56
  • I do not really see what you get from this. First: `compile` dependencies are automatically also on the `test` classpath. So on the test classpath, you load both JARs. They have a lot of classes with the same name. When you run tests, you might therefore get the classes from on or the other JAR, depending on the exact order of the classpath. This is brittle and you might end up in situations where you *think* you called a class from the older version but actually called one from the newer one (and vice versa). – J Fabian Meier Mar 30 '22 at 10:48
  • Second: I do not understand how this helps you. If you cannot bring 2.10.5.1 to production because of the vulnerability, why test with it? Your tests will not show the outcome you later have in production. – J Fabian Meier Mar 30 '22 at 10:49
  • Third: If you really (really really) need a different version for tests than for production, define the versions as `${jackson-databind.version}` and override the property on the command line. – J Fabian Meier Mar 30 '22 at 10:49

0 Answers0