Question

I create my application archive with the maven assembly plugin. All the dependency present in my pom are included without any problem.

Now I need to include two or more version of the same artifact.

If in my pom I put

<dependencies>
        [...]
        <dependency>
            <groupId>db.test</groupId>
            <artifactId>my-model</artifactId>
            <version>1.0.3</version>
        </dependency>
        <dependency>
            <groupId>db.test</groupId>
            <artifactId>my-model</artifactId>
            <version>1.1.0</version>
        </dependency>
</dependencies>

Of source the dependenvcy resolver remove the old version and only the 1.1.0 is packaged in the archive

I try to include the jar by using assembly xml descriptor file. And I didn't find any solution.

A possible solution will be to manually put all the needed model.jar inside a folder and tell the assembly to copy it in the archive. But I'm looking for a more configurable solution.

Any idea ?

Was it helpful?

Solution

I found a solution by using maven-dependency-plugin to copy resolved pom dependencies and additional jar.

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.1</version>
<executions>
    <execution>
        <id>copy-dependencies</id>
        <phase>package</phase>
        <goals>
            <goal>copy-dependencies</goal>
        </goals>
        <configuration>
            <outputDirectory>${project.build.directory}/lib</outputDirectory>
            <overWriteReleases>false</overWriteReleases>
            <overWriteSnapshots>false</overWriteSnapshots>
            <overWriteIfNewer>true</overWriteIfNewer>
            <includeScope>runtime</includeScope>
        </configuration>
    </execution>
    <execution>
        <id>copy-model</id>
        <phase>package</phase>
        <goals>
            <goal>copy</goal>
        </goals>
        <configuration>
            <artifactItems>
                <artifactItem>
                    <groupId>my.test.pkg</groupId>
                    <artifactId>my-model</artifactId>
                    <classifier>server</classifier>
                    <version>1.0.3</version>
                    <type>jar</type>
                </artifactItem>
                <artifactItem>
                    <groupId>my.test.pkg</groupId>
                    <artifactId>my-model</artifactId>
                    <classifier>server</classifier>
                    <version>1.1.0</version>
                    <type>jar</type>
                </artifactItem>
            </artifactItems>
            <outputDirectory>${project.build.directory}/lib</outputDirectory>
        </configuration>
    </execution>
</executions>

Now I just have to add the following lines in my assembly xml

    <fileSet>
        <directory>${project.build.directory}/lib</directory>
        <outputDirectory>/lib</outputDirectory>
        <filtered>false</filtered>
        <includes>
            <include>*.jar</include>
        </includes>
        <fileMode>0600</fileMode>
    </fileSet>

OTHER TIPS

Maven assumes it doesn't make any sense to have more than one version of a module at once. It assumes that a newer version replaces the older version. If it doesn't it is not the same module. I suggest you give the newer module a different name and make sure it has different packages to avoid choising a random module.

In general Maven tried to encourage good application design and deliberately makes it difficult to do things it has determined to be a bad idea.

Another ugly solution might be to use WAR file overlays, exploiting the fact that this mechanism pays no attention to the versions of component JAR files when applying the overlays.

I agree, different versions means replacing the older one. If we have to consume two different versions of a webservice for some business requirement. It is a good idea to generate the stubs in different packages and while adding to maven you can specify different them in groupid. This should work.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top