2

We have a Project A that downloads an artifact from another Project B, performs an operation on it, and spits out a new artifact as a result. We use the 'dependency:copy' goal from maven-dependency-plugin to get this Project B artifact from our Maven repository.

When we perform a Maven release, I expect the maven-release-plugin's 'release:prepare' goal to check all dependencies and fail if any SNAPSHOT versions are found. This works for normal dependencies under our <dependencies><dependency>...</dependency></dependencies> tags, but not with artifact "dependencies" copied by maven-dependency-plugin.

How (if at all) can I expose the versions of these copied artifacts to maven-release-plugin's prepare test, and make sure we never build a release of Project A that includes a snapshot of Project B?

If context helps, here's a simplified version of the maven-dependency-plugin settings in our pom:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <version>2.8</version>
    <executions>
        <execution>
            <id>copy</id>
            <phase>process-sources</phase>
            <goals>
                <goal>copy</goal>
            </goals>
            <configuration>
                <artifactItems>
                    <artifactItem>
                        <groupId>${ProjectBGroupID}</groupId>
                        <artifactId>${ProjectB}</artifactId>
                        <version>${ProjectBVersion}</version>
                    </artifactItem>
                </artifactItems>
            </configuration>
        </execution>
    </executions>
</plugin>
user1246225
  • 31
  • 2

1 Answers1

0

Adding an answer to my own question, I've found we can expose the version number to maven-release-plugin by including an extra <dependency>...</dependency> element (which refers to Project B) to Project A's pom. This properly causes a failure if we try to release with a snapshot, but it also exposes Project B to Project A's classpath. We can restrict this a bit by including a <scope> of "test" (which keeps B's classes out of A's binary), but this still leaves A's unit tests 'tainted' by B.

I'm hoping someone here has a better solution which doesn't actually add Project B to (any part of) Project A's classpath.

user1246225
  • 31
  • 2
  • I'm also using this solution with extra . The other differences are I'm using copy-dependencies goal. So the copy goal will not have explicit version there. Still looking for a better answer though. – ceilfors Apr 14 '15 at 13:47