Ethan Atkins 9cdeb7120e Add StateTransform class ... This commit cleans up the approach for transforming the sbt state upon completion of a task returning State. I add a new approach where a task can return an instance of StateTransform, which is just a wrapper around State. I then update EvaluateTask to apply this stateTransform rather than the (optional) state transformation that may be stored in the Task info parameter. By requiring that the user return StateTransform rather than State directly, we ensure that no existing tasks that depend on the state transformation function embedded in the Task info break. In sbt 2, I could see the possibility of making this automatic (and probably removing the state transformation function via attribute). The problem with using the transformState attribute key is that it is applied non-deterministically. This means that if you decorate a task returning State, then the state transformation may or may not be correctly applied. I tracked this non-determinism down to the stateTransform method in EvaluateTask. It iterates through the task result map and chains all of the defined transformState attribute values. Because the result is a map, this order is not specified. This chaining is arguably a bad design because State => State does not imply commutivity. Indeed, the problem here was that my state transformation functions were constant functions, which are obviously non-commutative. I believe that this logic likely written under the assumption that there would be no more than one of these tranformations in a given result map.		2019-03-30 16:39:10 -07:00
..
main/scala/sbt	Add StateTransform class	2019-03-30 16:39:10 -07:00
test/scala/sbt	Implement Append for Function1	2019-01-29 09:12:11 +00:00