I am working on a couple of tasks that help generate double clickable applications (".app" bundles on MacOSX and using launch4j for windows). The task obviously “depends” on the list of runtime jars and other things like name and version in the project.
I was thinking of just adding the project.buildFile to my task’s inputs, but this seemed wrong.
Is there a way to say that a task “depends” on a value in the build file, like the version? I am guessing not as then gradle would have to save the old build file to determine what the values used to be.
Is there a better way to do this? In particular, in a multiproject some things might be set in the super project’s build file, and so the dependency on just the build file would not catch it.
Similarly, is there a way for a task to know that it needs to run again if the actual task itself has been updated. I have been bitten several times by making changes to my task’s source, recompiling it (as a separate project) and then running the task on the test project and nothing happens because gradle thinks the task is up to date. Can I “depend” on the jarfile that declares the task? Should gradle do this automatically?
Is there a way to say that a task “depends” on a value in the build file, like the version?
I’m not sure what you’re trying to achieve by making the task depend on a version. E.g. do you want to take advantage of the incremental builds and when the version changes the task needs to run again? If that’s the case then you can simply configure the version as an input to the task.
In particular, in a multiproject some things might be set in the super project’s build file
Well, there are ways of configuring that evaluation of particular project depends on evaluation of some other project. However, we don’t like it very much and want to deprecate it at some point
is there a way for a task to know that it needs to run again if the actual task itself has been updated
At the moment we want only the task to run again if its inputs or outputs have changed. So for good or bad, it was a design choice to ignore the fact that the implementation has changed for the sake of up-to-date checks. You can always run clean before (provided you apply the base plugins).
Can I “depend” on the jarfile that declares the task? Should gradle do this automatically?
I’m not sure I understand… provided that the jar file of the task is a declared output of this task, you should probably simply depend on the task.
Sounds strange. When I change anything (including *.gradle files of cause) that effects the build I expect corresponding parts to be rebuilt. When I change pom in maven the sub-project and all dependences rebuild. Is there a proper way to fix gradle?
