Re: versions:use-latest-versions and dependency:copy-dependencies

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: versions:use-latest-versions and dependency:copy-dependencies

stephenconnolly
The Maven model of project dependencies is resolved as part of the build
plan because the transitive dependencies could affect the build order.

An example (contrived, but possible).

I have two modules: foo and bar

foo depends on bar

bar depends on a 3rd library that is external to the reactor: manchu

so we have for foo

foo:1.0-SNAPSHOT
    -> bar:1.0-SNAPSHOT
    -> manchu:1.0

The manchu project happens to add a dependency on bar:1.0

So now we have for foo

foo:1.1-SNAPSHOT
    -> bar:1.1-SNAPSHOT
    -> manchu:1.1
        [-> bar:1.0 but as bar:1.1-SNAPSHOT is nearer, we use that]

Now what happens though if you are working on foo and machu at the same
time?

So you create a new "throwaway" reactor pom:

<modules>
  <module>manchu</module>
  <module>foo-parent</module>
</modules>

The build plan would initially (i.e. before we tie in the versions and we
are just building the aggregator) be:

manchu:1.2-SNAPSHOT (because listed first in the <modules> indicative
preferred order)
foo-parent:1.1-SNAPSHOT (because parent of bar)
bar:1.1-SNAPSHOT (because required to be built before foo)
foo:1.1-SNAPSHOT (because this completes foo-parent)

Next we update the dependency of foo to link in the manchu from the reactor

So now we have for foo

foo:1.1-SNAPSHOT
    -> bar:1.1-SNAPSHOT
    -> manchu:1.2-SNAPSHOT
        [-> bar:1.0 but as bar:1.1-SNAPSHOT is nearer, we use that]

The build plan now becomes:

manchu:1.2-SNAPSHOT (because listed first in the <modules> indicative
preferred order)
foo-parent:1.1-SNAPSHOT (because parent of bar)
bar:1.1-SNAPSHOT (because required to be built before foo)
foo:1.1-SNAPSHOT (because this completes foo-parent)

Next we say, oh but we should be using the latest bar when building manchu
so that my IDE can single-step correctly... so now we have

foo:1.1-SNAPSHOT
    -> bar:1.1-SNAPSHOT
    -> manchu:1.2-SNAPSHOT
        [-> bar:1.1-SNAPSHOT but we have that already]

The build plan now becomes

foo-parent:1.1-SNAPSHOT (because parent of bar)
bar:1.1-SNAPSHOT (because required to be built before foo and manchu)
manchu:1.2-SNAPSHOT (because we need to build manchu after bar and before
foo)
foo:1.1-SNAPSHOT (because this completes foo-parent)

There are other ways that the build plan can be affected, more typically
using dependencyManagement to override dependencies. But the long and the
short of it is that when you change dependency versions you could end up
affecting the build plan.

Our current solution to this is that the effective model and the build plan
are locked before we start building. If you want to change the pom then you
would need to either use the maven invoker plugin to fork a new maven
session or use two executions. (and bonus hint, this is one of the reasons
why the release:perform goal uses a forked maven execution, so that the
release poms get parsed)

On Tue, 22 Jan 2019 at 08:08, Anders Nyström <[hidden email]> wrote:

> Hi,
>
> I am using versions:use-latest-versions in an early phase
> (generate-sources) in my maven build and it works nice. It updates the
> versions I want, but when I use it together with
> dependency:copy-dependencies that I have in a later phase
> (process-resources) of my maven build something gets wrong. The dependency
> copied is the dependency version used before it was updated with
> versions:use-latest-versions. Its impossible to fix this in the pom and the
> only way to solve it is to have it in two different commandes. like for eg
> mvn clean versions:use-latest-versions && mvn install, this is not good
> because its needs to be done in two different steps. I want the simplest
> possible command like mvn clean install only.
>
> In pom:
> <plugin>
>             <groupId>org.codehaus.mojo</groupId>
>             <artifactId>versions-maven-plugin</artifactId>
>             <version>2.7</version>
>             <configuration>
>
>
> <rulesUri>file:///${session.executionRootDirectory}/config/maven-version-rules.xml</rulesUri>
>
>             </configuration>
>             <executions>
>                <execution>
>                   <phase>generate-sources</phase>
>                   <goals>
>                      <goal>use-latest-versions</goal>
>                   </goals>
>                </execution>
>             </executions>
>          </plugin>
> .....
>         <plugin>
>             <version>3.1.1</version>
>             <groupId>org.apache.maven.plugins</groupId>
>             <artifactId>maven-dependency-plugin</artifactId>
>             <executions>
>                <execution>
>                   <id>copy-dependencies</id>
>                   <phase>process-resources</phase>
>                   <goals>
>                      <goal>copy-dependencies</goal>
>                   </goals>
>                   <configuration>
>
> <outputDirectory>${project.distribution.directory}</outputDirectory>
>                      <overWriteReleases>true</overWriteReleases>
>                      <overWriteSnapshots>true</overWriteSnapshots>
>                   </configuration>
>                </execution>
>             </executions>
>          </plugin>
> ...
> Output:
> [INFO] --- versions-maven-plugin:2.7:use-latest-versions (default) @ kalle
> ---
> [INFO] Major version changes allowed
> [INFO] artifact se.apa:olle: checking for updates from development
> [INFO] Updated se.apa:olle:jar:2019.1.9559-280 to version 2019.1.9572-287
> .....
> Later in output:
> [INFO] --- maven-dependency-plugin:3.1.1:copy-dependencies
> (copy-dependencies) @ kalle ---
> [INFO] Copying olle-2019.1.9559-280.jar to
> /home/pelle/workspace/develop2/kalle/distribution/olle-2019.1.9559-280.jar
>
> As you can see its copying the old version (2019.1.9559-280) and not the
> new one (2019.1.9572-287). My guess is that maven-dependency-plugin reads
> the pom to earlie? It should read it first in the phase its executed in. So
> the correct dependencies is copied. Or is there any other way to solve
> this?
>
> Regards
> Anders
>