Adam Murdoch wrote: > >> One use case was a release workflow where the order of tasks needed to be >> different for different types of builds (snapshot, release, etc.). > > This sounds like an implementation rather than a use case. What was the > problem you were trying to solve? >
The release workflow had about ten steps which were naturally modeled as tasks. At some point we got a new requirement: "For a release build, the steps have to be performed in a different order, namely...". This had to do with their artifact repository, but it doesn't really matter. It was a valid requirement. Adam Murdoch wrote: > > Currently, the plan for the clean problem is to make clean as real > dependency of the build lifecycle task, and have some way to force it to > run first (or a convention that does this automatically). So, I don't > really see clean as being a variation. It's a real dependency. > The requirement said: "(Only) for a release build, clean has to be performed automatically, without the need to specify it explicitly". Yet another form of variation was when we used Gradle to drive (and enrich) Maven builds, and the teams owning the Maven builds told us which Maven parameters (phases, goals, profiles) we had to use for each build type. Again, these were requirements we had to satisfy. Adam Murdoch wrote: > > For most users of a build (ie the audience for the build output), the > lifecycle tasks are more important than the implementation tasks, and the > implementation tasks are noise. > I like to see the tasks that get executed. "build", "check", etc. seems too abstract to me. It's more the (often huge) list of up-to-date/skipped tasks that strike me as noise. Adam Murdoch wrote: > > Even as someone who is a build author with a good knowledge of what all > the tasks do, when I run the build I usually only care about the lifecyle > tasks - check, devBuild, install, sometimes classes or test. I just want > to see progress in terms of the high-level build lifecycle, I don't really > care about the details. I want the logging to reflect this. > As soon as a task takes longer than a second or so, I want more detailed information, like which task currently runs and what it currently does (running test 7/10, resolving dependency x:y:1.0, etc.). Also if something fails, I'll probably have to deal with the task level. If I've never been exposed to the task level before, this will be difficult. Cheers, Peter -- View this message in context: http://gradle.1045684.n5.nabble.com/Task-Variations-tp4884963p4963115.html Sent from the gradle-dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
