TaskGenerator should allow user controlled UUIDs for their Tasks

[PetrosPapapa]

No description provided.

[MBaczun]

I think this is now implemented.
The next question is, why are resources not considered part of a task, and in turn part of a taskGenerator? Maybe this could be combined in a similar way?

[PetrosPapapa]

How do you mean? The actual TaskResource objects? Because they are shared among all tasks. They are also mutable (at least in the current implementation).

I am also considering more flexible resource matching (#5) than just directly through names. This, however, will make the Scheduler much more complicated, so I've been holding off from trying it.

[MBaczun]

Currently whenever I pass a task generator I also need to pass a Seq[String] of task resources. It might be nice if the task generator contained this Seq instead of always passing it separately. Maybe it's wrong, but I think of the resources that a task uses to be an attribute/property that defines this task, so I always found it strange that it's not treated like a part of the task. I don't mean that resources belong exclusively to any single task, but that the resources that are required for a task are, in a way, what defines the task.

[PetrosPapapa]

Ah I see what you mean now. I can't currently think of a reason not to add this too to the generator, so go ahead!

[MBaczun]

ok! it's added on the same branch.

[PetrosPapapa]

Good stuff!

[PetrosPapapa]

Do we actually need a TaskGenerator at all now? It can no longer generate more than one task anyway (it used to, but not any more). The only thing it does is pick random values. Maybe it's just better to pass Tasks to the Coordinator? One can still use generators externally if they want.

[MBaczun]

That's a good point. In some ways it would simplify the code. However, there is a benefit to TaskGenerator.create(), which is that the person calling .create can specify the time at which a task is created. When the coordinator does this, it has easy access to the current time, unlike the simulation which has no access to the current time.
I use the creation time of a task in lookahead too, and this creation time is set by calling .create in the scheduler (which has access to both the current time and the lookahead function which describes the starting time of a task given its predecessors).

[PetrosPapapa]

Ah yes that's a good point, but I think that can also be circumvented in a few ways... Simplifying the code would be more useful.

Just leave it as is for now, and I'll start a new issue to consider this in the future. We ought to keep the focus on the lookahead stuff right now.