Add maven profiles and caching to speed up builds.

[motlin]

I have two changes here:

• Separating maven plugins into profiles and only enabling the relevant profiles in the relevant workflows
• Adding the GitHub shared action for caching the .m2 directory

These are only related in that they both are intended to speed up the build and they both were created by comparing with another open source GitHub workflow which is written in this style.

The maven profile thing creates a third related change, splitting the "test" configuration into separate test, enforcer, and dependency:analyze-only jobs.

If this is too much, I can definitely split out the caching, and possibly more.

[motlin]

This bit was a surprise to me. Jacoco must have been doing this on our behalf. Without this, unit tests and serialization tests started to fail in Java 17 and higher when calling clone().

[motlin]

Before:

After:

[motlin]

Could we please land this? I just resolved the merge conflicts between this and the OSGi stuff, and I have other branches stacked on top of this one.

[motlin]

@fipro78 I rebased my changes and now I'm getting build failures I don't understand, just in the Javadoc workflows. Could you help me figure them out?

13:14:44:117 [ERROR] /home/runner/work/eclipse-collections/eclipse-collections/eclipse-collections-api/target/generated-sources/java/org/eclipse/collections/api/factory/primitive/DoubleBooleanMaps.java:[25,21] error: package aQute.bnd.annotation.spi is not visible
  (package aQute.bnd.annotation.spi is declared in the unnamed module, but module aQute.bnd.annotation.spi does not read it)
13:14:44:117 [ERROR] /home/runner/work/eclipse-collections/eclipse-collections/eclipse-collections-api/target/generated-sources/java/org/eclipse/collections/api/factory/primitive/DoubleBooleanMaps.java:[26,21] error: package aQute.bnd.annotation.spi is not visible
  (package aQute.bnd.annotation.spi is declared in the unnamed module, but module aQute.bnd.annotation.spi does not read it)
...

[fipro78]

I also had issues with the javadoc builds while I worked on the pr.

One thing is that I had to build the generators first separately, as otherwise there are dependency issues.

The other thing is that the javadoc step needs to be done before the install.

Apart from that, I don't know the changes you are rebasing that could cause the breakage. But the two topics I mentioned above did cost me a while to fix.

Hope that helps.

[motlin]

The other thing is that the javadoc step needs to be done before the install.

The point of running install first is to make sure the code generator is built and all code-generated code is generated since it also has Javadoc. I'll try splitting the steps differently.

[donraab]

@motlin What do the region Phase numbers mean?

[motlin]

@motlin What do the region Phase numbers mean?

Even after using maven all this time, I get confused about what order the plugins will run in. I got in the habit of numbering by phases.

https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#lifecycle-reference

I start with validate is 1 and just count from there. It's not a common convention but I find it helpful.

[donraab]

@motlin What do the region Phase numbers mean?

Even after using maven all this time, I get confused about what order the plugins will run in. I got in the habit of numbering by phases.

https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#lifecycle-reference

I start with validate is 1 and just count from there. It's not a common convention but I find it helpful.

I found them a bit confusing because there were references to phase 16, phase 17, but no other phases in some files.

[donraab]

@motlin I am approving and you can feel free to merge. @fipro78 if you can validate there are no issues with your recent changes, I would appreciate it. Thanks!

[fipro78]

As far as I can see this PR "only" improves the build execution. Only in the sense of "it should not affect my recent OSGi and JPMS changes". From having a look at the changes sources, I would not see any effect in that area.

To be 100% sure you should double check the generated artefacts. Open the generated jar files for API and IMPL and ensure that the META-INF/MANIFEST.MF contains now quite a lot of information, there is a module-info.class file on top level and the META-INF/services in the IMPL jar file contain the factory services definitions.

[motlin]

While I was able to land this by working in GitHub workflows, I find I'm no longer able to do development for Eclipse Collections in the IDE, or run certain maven builds. I consistently get errors like this.

java: package aQute.bnd.annotation.spi is not visible
  (package aQute.bnd.annotation.spi is declared in the unnamed module, but module org.eclipse.collections.api does not read it)

[fipro78]

Maybe the same issue as on github? Is a multi stage build required locally?

I developed my PR in Eclipse and got it working there. But I am not sure about the intermediate steps. It was a longer journey.

[donraab]

@motlin @fipro78 Looking at the diff, a large section was removed from the parent pom in this PR. I will build in IDE to see if I see same issues.

Craig, I can confirm I am having the same issues building and running in the IDE. Additionally, there is a dependency issue with koloboke impl jar when running analyze.

[donraab]

@motlin I was able to get IntelliJ to work running Unit Tests and running Unit Tests with Coverage by disabling the IntelliJ build and run in the configuration for All Unit Tests. I changed the IntelliJ JUnit configuration to use run only, after running Maven clean/test.