Skip to content

Instantly share code, notes, and snippets.

@evant
Created September 16, 2015 14:02
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save evant/bd375bc117d684576a21 to your computer and use it in GitHub Desktop.
Save evant/bd375bc117d684576a21 to your computer and use it in GitHub Desktop.

Suggestions for the new Transform Api

Possibly the biggest issue I see with the current api is that it is very hard to extend it in the future without breaking current implementations. For example, I asked to be provided the LoggingManager for the task so I can redirect stdout output inside the transform. This cannot be done without changing the api. I have a couple suggestions to fix this issue, it would be better to do it now while it's still in beta.

  1. Provide the gradle task that performs the transform to the transform method. This way you can define an api for accessing information on the task that can evolve over time. This for example, gives you the LoggingManager for free. This would also allow the same api to be used by simply obtaining the task through normal gradle means.

Alternative: Provide a different class that only provides a subset of information about the task. This trades some flexibility with higher control on how this api will be used.

  1. Change the Transform interface to an abstract class. This allows you to add more methods in the future without breaking the current implementations by providing default implementations. As a bonus, some of the current methods like getSecondaryFileInputs() can have default implementations as they would often just return an empty collection.

Alternative: Default methods in java 8 interfaces. Would achieve the same goal, but it's unlikely that it would be possible to force everyone to use compile with java 8 at this point in time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment