Exclude all transitive dependencies of ssj besides commons-math3 and replace linear regression implementation

[dwnusbaum]

#625 added a dependency on ssj, which in turn picked up a few additional dependencies. I think we can avoid some of these dependencies to reduce the size of the HPI, avoid unusual licenses, and reduce supply chain risk by excluding all dependencies of ssj except for commons-math3.

[INFO] +- ca.umontreal.iro.simul:ssj:jar:3.3.2:compile
[INFO] |  +- colt:colt:jar:1.2.0:runtime
[INFO] |  |  \- concurrent:concurrent:jar:1.3.4:runtime
[INFO] |  +- com.github.rwl:optimization:jar:1.3:runtime
[INFO] |  \- org.apache.commons:commons-math3:jar:3.6.1:runtime

While reviewing the update, some of these dependencies stood out to me as being a bit unusual.

• colt:colt
  • The main homepage seems to be https://dst.lbl.gov/ACSSoftware/colt/, which offers jar downloads but does not mention anything about Maven, and from some quick searches it is not clear to me who owns colt:colt on Maven central.
  • The library has a split license, where the hep.aida.* packages (which are unused by ssj, but due to the nature of Jenkins plugins are exposed to plugins that depend on junit) are LGPL "with the exception that any usage related to military applications is expressly forbidden", which means that it is definitely not an OSI-approved license (which is a requirement for plugins hosted by jenkinsci), so that seems bad. There are different versions of the library under other groupIds where the problematic package has been removed, but none that have clear ownership on Maven central traceable to a clear and current owner.
• concurrent:concurrent
  • Main homepage seems to be https://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html, which only offers source downloads, and again it is not clear to me who owns the package on Maven central.
  • Also, this dependency has been obsolete for decades (since JDK 1.5), so anything using it is probably also obsolete, or is attempting to support very old versions of Java.

All we need from ssj is linear least squares regression (LeastSquares) and some kind of smoothed spline interpolation (SmoothingCubicSpline).

• LeastSquares makes use of classes from the colt library, which I would prefer to avoid, but commons-math3 has a direct replacement in its SimpleRegression class.
• I did not see any direct equivalent to SmoothingCubicSpline in commons-math3. There is SplineInterpolator, but it does not have smoothing support. Probably smoothing support good enough for our purposes (just a visual aid in some charts) could be implemented on top of SplineInterpolator with some preprocessing on our side if someone is interested and wants to spend some time on it.

Note:

Really I would prefer to not depend on ssj at all, and instead just copy the source code of SmoothingCubicSpline into this repo with proper attribution. I doubt we care at all about tracking updates for the code we are using, and there is a good chance the code will never change anyway. I am also a bit concerned that the 3.3.2 version that we are using and that is in Maven central is only mentioned in the README in https://github.com/umontreal-simul/ssj, and there is no corresponding release or tag. However, I did not find any good way to report licensing information correctly via https://github.com/jenkinsci/license-maven-plugin and https://www.mojohaus.org/license-maven-plugin/ without having the library that you want to include the license for actually be a dependency.

Testing done

I ran the plugin, created a job that created random test data and recorded it with this plugin, built the job around 50 times, took a screenshot of the charts on the test history page with and without my changes, and verified that the relevant trend lines in the screenshots were the same.

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests - that demonstrates feature works or fixes the issue

[dwnusbaum]

This was already a dependency via ssj, I think it was just unused previously, but now we use it for SimpleRegression.

[dwnusbaum]

Uses libraries from colt, which we can avoid by using SimpleRegression instead.

[dwnusbaum]

A bit awkward, but the SimpleRegression methods that accept arrays of data expect double[n][2] instead of double[2][n], so I did not see a simpler approach.

[basil]

Thanks for the PR!

[timja]

Thanks!

[dwnusbaum]

Probably smoothing support good enough for our purposes (just a visual aid in some charts) could be implemented on top of SplineInterpolator with some preprocessing on our side if someone is interested and wants to spend some time on it.

Also though, looking at the uses of SmoothingCubicSpline a bit more, I think the build duration distribution chart should be a histogram, not a trend line, and we could implement that relatively easily.

The uses of SmoothingCubicSpline in the test results chart to produce a nonlinear trend line when you have at least 200 builds could perhaps be replaced with a moving average to be much simpler, but I also wonder whether it's even worth adding a special trend line for this case.

(with changes like these we could drop the ssj dependency completely)

[basil]

CC @mdealer