Reduce code duplication in gradle files

[dminones]

There's a trick you can do to reduce some of the code duplication, specifically the 'buildscript' blocks at the header of every gradle file. If you create a 'buildSrc' directory, that will be used for a 'local gradle plugin'; if you put in that directory a 'build.gradle' file that has the 'repository' and 'dependencies' lines necessary to use the LensKit Gradle plugin (as top-level blocks, just like a normal Gradle project, not within 'buildscript'), then it will be available through the whole project without needing to duplicate that code.

[Roj]

I've tried to factor some of the duplicated code into a task. For example, I tried grabbing the definition of the algorithms (which right now is in every dataset-evaluate task) and putting it into another task. But for some reason, gradle ignores it. I've tried using doLast, mustRunAfter, etc. It configures the script and parses just fine, but it doesn't actually run the algorithms.

[Roj]

It appears that I've misunderstood mustRunAfter, as it does something different (orders the execution of tasks when many are called).

I've attempted a solution using finalizedBy but I am getting "illegal state exception: no jobs defined" errors..

[Roj]

I've finally been able to sort the dependencies, but the main problem seems to be passing parameters from one task to another. The ideal scenario would be no code repetition, each evaluate for each dataset just sets the correct parameters, and is then followed (finalizedBy) by a general "algorithm"s task, that sets them up and stuff. Given the problems of scope in groovy and gradle files (both inside the same file as well as between multiple files), and the impossiblity of passing task values by parameter, I'm going to create a new branch and go back to the old idea of having one big build.gradle, which may be a little bit messy, but has much less code repetition and also allows me to configure the algorithms in one place.

The main idea here is to have a functioning version of the hyperparameter search. Once that's done, we can choose the best implementation. But I've spent many hours on the main branch trying to work it out and frankly I just want to get it running.