Howdy, There's an aspect of the migration comparison/verification work that could benefit from some focused discussion. It's mostly an implementation level issue so this conversation can run in parallel to other work in this space.
At a basic level what we need to do is run two builds and compare _things_ about this. What I want to try and lock down is exactly what these “things” can be. There's two prevailing schools of thought; these things are always files, or they are much more abstract and could be anything. A component of this work will be delivering an API that allows the user to assemble their own comparison process (for non trivial cases). If everything is a file the API could be simpler, *maybe* in a significant way. In the migration from tool X (Ant or Maven) to Gradle, tool X is more or less an opaque box that we poke and then it does something. Our options for understanding what it did are its process exit value, its stdio output and what it leaves on the filesystem. In a Gradle to Gradle migration (i.e. upgrade), we have much richer information exchange potential. If we decide that _all_ we want to do with this feature is compare the files that builds generate then the issue is moot. We can obviously then design the entire API around comparing files. I'm not sure we want to do make this restriction though. I think there's a case for comparing other things. Consider something like a classpath. In the case of a migration from a different system, it might be useful to understand how the compile classpath is different for an artifact during the development of the Gradle build being migrated to. Unless we did this automatically (which we probably could do for Maven but not Ant) I doubt many users would bother with this. It seems more compelling in the Gradle upgrade case though. That's definitely something I'm going to want to be aware of changing if it does. There are some other Gradle specific things we could compare: * All of the tasks in a project (i.e. be told that a Gradle upgrade introduces or removes tasks that were in the build before) * All of the DSL extensions in a project (this one is pretty dubious I think) * The set of configurations/archives etc. Upgrade verification isn't just about giving a binary yes/no answer. Part of it will be understanding differences introduced by new versions, which means deeper analysis. When (if?) we start using this feature to help people test speculative changes to their build, this becomes even more important. We also may use this “comparison” toolkit in our own QA, which is another argument for being more general/abstract. My current thinking is that at the base of the API we need to stay general and be able to compare just about anything (by plugging in different strategies), and then layer a file oriented set of strategies on top. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
