Removed repos as they are now inherited from the parent pom

[kaikreuzer]

Signed-off-by: Kai Kreuzer kai@openhab.org

[kaikreuzer]

This should help speeding up our openhab-core builds, I hope.

[wborn]

Let's speed it up. :-)

[cweitkamp]

That's impressive. It nearly hurts ... 🚀

> mvn clean install -DskipChecks -DskiptTests
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 03:06 min
[INFO] Finished at: 2019-08-30T13:34:04+02:00
[INFO] Final Memory: 244M/1693M
[INFO] ------------------------------------------------------------------------

[kaikreuzer]

You're cheating, -DskiptTests wouldn't have been so quick with that typo 😛.
But yeah, the local build isn't too bad now. I'd just would love to get SAT a bit quicker, it makes the addons PR build extremely slow...

[kaikreuzer]

Do you have any idea why https://ci.openhab.org/job/openHAB-Core/265/ fails? It seems it isn't taking the repos from the super-pom into consideration. It does it when I build it locally, though...

[cweitkamp]

I'd just would love to get SAT a bit quicker

What can be done to archive that? Any ideas?

[wborn]

There's already an issue for that (openhab/static-code-analysis#232).

Measuring what takes long would also help so we know where the biggest improvements can be made (openhab/static-code-analysis#319).

If the new Jenkins setup with agents provide enough memory/CPUs fixing parallel SAT execution might also help (openhab/static-code-analysis#200).

[kaikreuzer]

If the new Jenkins setup with agents

Just fyi: I am currently experimenting with that. I have rented a VM with 32GB RAM and installed 4 Jenkins agents in separate docker containers à 8GB RAM. Memory thus should be no issue. I didn't remember the discussion about parallel builds anymore, that's a good idea. I have added -T 1C to the addons (PR) build for a try - let's see what happens...

[kaikreuzer]

Not too bad, https://ci.openhab.org/view/Pull%20Request%20Builds/job/openHAB2-Bundles/742/ took just half as long than the previous builds!

[kaikreuzer]

But https://ci.openhab.org/job/openHAB-Core/ worries me - why isn't it looking for the repos from the super-pom? @cweitkamp or @wborn, would you have any good idea?

[wborn]

Does it store the super POM in the local Maven repository? It doesn't seem to be downloaded at all. A local build with an empty Maven repo works for me. But the first downloaded artifact during that build is the super POM:

$ mvn clean install 
[INFO] Scanning for projects...
Downloading from central: https://repo.maven.apache.org/maven2/org/openhab/openhab-super-pom/1.0.1/openhab-super-pom-1.0.1.pom
Downloaded from central: https://repo.maven.apache.org/maven2/org/openhab/openhab-super-pom/1.0.1/openhab-super-pom-1.0.1.pom (5.5 kB at 25 kB/s)
Downloading from jcenter: https://jcenter.bintray.com/org/apache/karaf/tooling/karaf-maven-plugin/4.2.6/karaf-maven-plugin-4.2.6.pom
Downloaded from jcenter: https://jcenter.bintray.com/org/apache/karaf/tooling/karaf-maven-plugin/4.2.6/karaf-maven-plugin-4.2.6.pom (18 kB at 163 kB/s)
Downloading from jcenter: https://jcenter.bintray.com/org/apache/karaf/tooling/tooling/4.2.6/tooling-4.2.6.pom

It seems to be completely missing from the Jenkins logging. If it were using the super POM it would also download most artifacts using bintray.

[kaikreuzer]

Hm, the parallel build still seems to be an issue for SAT, see https://ci.openhab.org/job/PR-openHAB2-Addons/15005/.

I'll deactivate it again on the PR builds...

[kaikreuzer]

It doesn't seem to be downloaded at all.

Yes, I was wondering about that as well. But as we reference a dedicated version of the super pom, the locally cached version should be completely identical to any remote one, so even if it is cached, it should not matter.

[wborn]

If you have access to the machine you could see if it builds if you run Maven manually on that workspace using the same local Maven repo.

Executing mvn help:effective-pom -N should also show the inherited repos from the super pom. It might be another bug in the Jenkins Maven build plugin.

Using a free style build or pipeline build instead might also fix it. Most people use these nowadays so they don't notice or fix these bugs.

[wborn]

When I build openhab-core using my own Jenkins Docker container using a "Maven project" it builds just fine. It also downloads the super POM with an empty repo while parsing POMs:

Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Parsing POMs
Downloaded artifact https://repo.maven.apache.org/maven2/org/openhab/openhab-super-pom/1.0.1/openhab-super-pom-1.0.1.pom
Discovered a new module org.openhab.core:org.openhab.core.reactor openHAB Core
Discovered a new module org.openhab.core.bom:org.openhab.core.reactor.bom openHAB Core :: BOM
Discovered a new module org.openhab.core.bom:org.openhab.core.bom.compile openHAB Core :: BOM :: Compile
Discovered a new module org.openhab.core.bom:org.openhab.core.bom.compile-model openHAB Core :: BOM :: Compile Model
Discovered a new module org.openhab.core.bom:org.openhab.core.bom.runtime openHAB Core :: BOM :: Runtime
Discovered a new module org.openhab.core.bom:org.openhab.core.bom.runtime-index openHAB Core :: BOM :: Runtime Index
Discovered a new module org.openhab.core.bom:org.openhab.core.bom.test openHAB Core :: BOM :: Test
Discovered a new module org.openhab.core.bom:org.openhab.core.bom.test-index openHAB Core :: BOM :: Test Index
Discovered a new module org.openhab.core.bom:org.openhab.core.bom.openhab-core openHAB Core :: BOM :: openHAB Core

Maybe it helps if it rebuilds all module info? I tested removing the modules dir /var/jenkins_home/jobs/openhab-core/modules and it regenerates all module info on the next build. That might also be an easy way to remove all those no longer existing modules from the add-ons builds.

[kaikreuzer]

Thanks @wborn. I've completely removed the workspaces from the agents and it seems to have helped - the build is green again 👍.