0

Given that I have the following dependency for my multi-module CI:

<groupId>my_group</groupId>
<artifactId>artifact1</artifactId>
<version>2.0.0-SNAPSHOT</version>
<dependencies>
    <dependency>
        <groupId>my_group</groupId>
        <artifactId>artifact2</artifactId>
        <version>${project.version}</version>
    </dependency>
</dependencies>

On my CI I want to compile artifact 2. However, on my dev I rarely touch it and since compilation of that artifact requires some external dependencies and significant time I would very much like to skip it and use whatever latest release exists.

Up until now I had a profile that overrode artifact2 version with RELEASE, e.g.: use-released-artifact2 my_group artifact2 RELEASE

and locally I would run with -Puse-released-artifact2. Great.

Now maven3 deprecates RELEASE and LATEST pseudo-versions and I'm trying to find a solution that:

  1. doesn't leave modified pom.xml files to be identified as "modified" by git. in the past that led to developer inadvertently committing the wrong file. for the same reason I can't just add ignore to this file.
  2. doesn't require the developer to follow the release schedule and substitute parameters in their "mvn clean install..." line.
  3. doesn't go through lengthy resolution as version ranges do.
  4. doesn't force me to commit a version on every release (besides version plugin doesn't support advancing to version "next-1" afaik).

any ideas?

Clarification:

I don't want to run artifcat2 build at all. Moreover, artifact2 isn't available at 2.0.0-SNAPSHOT in the repository as it has not been released yet. I really want to take the latest release (e.g. 1.5.7) from the repository to compile artifact1 against that.

Ran Biron
  • 6,091
  • 4
  • 33
  • 66
  • What about building modules individually (on your local machine)? https://stackoverflow.com/a/3899772/927493 – J Fabian Meier Feb 12 '20 at 09:28
  • @JFMeier how would that help? to make the module depend on latest release I would still need to encode it into the pom.xml which increases the chance of committing this by mistake – Ran Biron Feb 19 '20 at 22:33
  • Maven developer here, don't use or rely on those tokens. They WILL go away. – Michael-O Feb 19 '20 at 23:12
  • @Michael-O so what’s the solution? I understand repeatable builds in CI but work station builds should factor in as wel. – Ran Biron Feb 20 '20 at 06:46
  • Why do you constantly need to change the version? I don't understand this? – Michael-O Feb 20 '20 at 11:34
  • One main issue is the way you execute Maven as mentioned in #2. By calling `clean` you will remove the results from the previous builds, even when things haven't changed. Try `mvn verify` – Robert Scholte Feb 20 '20 at 19:14
  • @RobertScholte I'm removing this from my local build folder by not from the .m2 local repo. – Ran Biron Feb 21 '20 at 00:13

1 Answers1

0

My advice would be as follows.

  1. Check out the whole multi-module project.
  2. Build all the modules once.
  3. Then, use a flag (as described here) to only build artifact1 for each subsequent build.

So the first build will take some time, but afterwards you only need to build artifact1 and the SNAPSHOT for artifact2 will be readily available in your local repository.

Of course, with this approach you use the latest version of artifact2, not the latest release version, but in practise, this should not matter to much.

J Fabian Meier
  • 26,766
  • 8
  • 52
  • 98
  • Thanks but that won’t work. As I mentioned in the question artifact2 build requires special software installed which I really don’t want to have all dev install on their local workstation. Moreover, maven default cache policy will invalidate this every time the project version changes, so after a few days (fast cycles) I’ll have to rerun this slow build again. – Ran Biron Feb 20 '20 at 07:58
  • Ok, then you have a very special situation. Idea1: Just stop building projects locally, but let the build server build on every commit and use IDE means (not real builds) for local testing. Idea2: Split up the multi-module project and let the developer just check out artifact1. Implement the logic of updating versions and building in the right order into your build server. – J Fabian Meier Feb 20 '20 at 08:03