-
-
Notifications
You must be signed in to change notification settings - Fork 208
Building
We're in the process of migrating all wiki contents to ojAlgo's new web site: http://www.ojalgo.org/
There are two different/parallel ways to build ojAlgo, an Ant script and a Maven configuration. They have different requirements and produce slightly different results.
ojAlgo has zero dependencies (other than JUnit for the unit tests) and there are absolutely no tricks involved in compiling the code. You don't really need a build system to build ojAlgo...
Maven is used to build (and upload) the artefacts available at The Central Repository. The actual uploading happens in the deploy life cycle phase - this is not for you!
All you should do is:
mvn clean package
Apart from the plugins and configurations related to uploading artefacts, the pom is the simplest possible.
The Ant script is very old. It has been used for years (decades) to package the SourceForge downloads. It is still used for this. In other words the Maven artefacts and the downloads at SourceForge are not the same.
In addition there are some "secrets" you need to know in order to execute the script:
- You need to have all modules from the SourceForge CVS repository checked out and available on your disk (there are 8 of them).
- In the build.properties file there's a collection of variables named alias.* These should be set to match what you named the modules/projects when you checked them out from CVS.
- You also have to set dist.doc.alias and dist.doc.dir. Together they make out the path to where the generated javadoc ends up.
I think that's all, but if I were you; I simply wouldn't bother with the Ant script.
ojAlgo uses JUnit. The tets are not run as part of either build process - Ant or Maven. They’re executed separately during development. Any/all modern IDE:s have features to allow easy execution of unit tests.
The class org.ojalgo.FunctionalityTest has a main method you can use to run the tests as a plain Java program (just remember JUnit needs to be on the classpath).
In the future it is desirable to integrate test execution with the build process, but the tests need to be cleaned up a bit before this can happen:
- In the optimisation packages there are tests that fail (difficult optimisation problems). Improving ojAlgo so that all these tests pass can be very time consuming, and ignoring them (turning them off) puts them "off the radar".
- A (large) number of tests use randomly generated input. Sometimes that results in test failures. Typically this may happen with complex valued matrices, tests checking overflow/underflow errors or tests actually trying to verify the behaviour of the random number generators.
- There are tests that download data from Yahoo Finance and Google Finance. With no access to the Internet these tests fail. Further some tests actually compare data from Google and Yahoo. At times they return different data when it should be the same - and that fails a tests.
Although ojAlgo (still) construct test cases JUnit3-style, you need JUnit 4.+ on your classpath to compile and run the test cases.
Do NOT use anything deprecated - it will be removed very soon! Most of what was deprecated at the time of the last release has already been removed. Removing something that was already deprecated is not mentioned in the changelog. If you're lagging behind and need to update over several versions it is recommended that you upgrade incrementally to each intermediate version (and finally to the latest snapshot).
The CVS repository at SourceForge contains unbroken history since project start 2003-04-16 up until the release of v42. All released versions (v1 to v42) have a tag/version in that repository. The naming convention for those tags have, however, changed over the years. Here's a table over tag names associted with the releases.
| Release Version | CVS tag/version |
|---|---|
| 1 | jar_1_0 |
| 2 | jar_2 |
| 3 - 31 | Version3, Version4, Version5 ... Version31 |
| 32 - 42 | v32, v33, v34... |
| 43 - ... | CVS repository no longer updated |