Examplar has reached about the 2/3rds completion mark.
[code]
/home/phanes/Development/internal/Examplar/cmake-build-debug/ftests
Parsed ‘/home/phanes/Development/internal/Examplar/conf/config.json’ with 2 element(s).
Parsed ‘/home/phanes/Development/internal/Examplar/conf/units/all_test.units’ with 1 element(s).
Added unit "independent test 1" to Suite.
Added unit "independent test 2" to Suite.
Added unit "dependent test" to Suite.
Parsed ‘/home/phanes/Development/internal/Examplar/conf/plans/test.plan’ with 1 element(s).
Added task "independent test 1" to Plan.
Added task "independent test 2" to Plan.
Added dependency "independent test 1" to task "dependent test".
Added task "dependent test" to Plan.
Loaded definition "independent test 1" for task "independent test 1".
Loaded definition "independent test 2" for task "independent test 2".
Loaded definition "dependent test" for task "dependent test".
Ready to execute all tasks in Plan.
Process finished with exit code 0[/code]
Project Status
At this point I’m ready to start implementing the execution of tasks in the plan.
I’ll need to decide on the behaviour of execution.
Currently it executes the executable at units[i].target. If that returns a non-0 or does not print what is in units[i].output to STDOUT, then it will check if units[i].rectify is set — if it is, then it will execute a heal attempt at filepath units[i].rectifier.
So far it’s a pretty concrete process.
There is a decision to make. Should it execute target then rectifier and then target again to see if it passed, or should it assume rectifier heals the broken condition? I believe the former is the case: It should alternate between target and rectifier until a 0 exit code with output printed to STDOUT. However, I would prefer to avoid an infinite loop in cases that, for whatever reason a user’s rectifier script is not healing the condition that causes target to fail.
Without intervention, I will have it execute target, rectifier on fail, and then target again before checking units[i].required. If that bool is set to true it should halt the entire plan. If not, it should note it and move on.
This behaviour will be important later in determining how dependencies really work in Examplar. If a dependency is listed in a Task, and that dependency failed but has a required attribute of false, then we’d be overriding that required attribute by checking for the completion flag of that failed dependency and simply halting. This may be desired behaviour. I am seeking feedback on this.
Data Integrity Assurance
There’s still some work to do with data integrity assurance during linking of tasks and units but it is currently working reliably when fed intact files.
Exceptions
The exceptions will need reworked eventually. They are accurate but somewhat lacking in references. Don’t want to do that to anyone who would end up supporting this. Luckily I’ve used strict OOP designs in this so it should be pretty easy to rework the exception later when the time comes.
Documentation
I’ve moved to Doxygen style documentation for all classes and methods.
Logging
We’re at a point where logging patterns should be considered.