Hi, We've now started using our new native integration (https://github.com/adammurdoch/native-platform). Currently, we're using this integration to:
1. Detect the console. 2. Determine the width of the console. This is happening for Windows, Linux and OS X (for intel based machines only). If something goes wrong with either of the above, and for other platforms, we fall back to the existing jansi/jna based implementations. Nothing has changed with the actual rendering to the console. We're still using jansi for this. And nothing has changed with any of the other native stuff, such as UNIX file mode support and so on. This should allow us to shake out the native integration in a relatively safe way in Gradle 1.3. If it proves stable, we can migrate more stuff across in Gradle 1.4. So, please give a recent build a try and let me know if anything goes wrong with the console output. One question is how we should deal with platforms that are supported by the old integration but are not supported by the new integration. At the moment, these are: * FreeBSD on intel machines. * Solaris on intel machines. * Solaris on Sparc machines. * Linux on ia64 machines. The first 2 are not supported because I haven't gotten around to finishing the ports. The second 2 are not supported because we don't have access to any machines with this hardware. Some options for migration: 1. For a given integration feature, remove the jansi/jna/jna-posix backed implementation once the new implementation is available and stable. 2. Keep the jansi/jna/jna-posix backed implementations and remove them in Gradle 2.0. 3. Get hold of the above hardware (combined with #1 above). Each integration feature may have a different answer. For example, dropping support for console output is not necessarily a breaking change, so we might go with #1 for console support. Dropping support for file permissions, on the other hand, would be a breaking change, so #1 is no good in this case. The best overall option is #3, but to do this we would need to get some help with access to the hardware. I'm not sure of a good way to encourage folks to help here. I guess one option would be to drop console output on these platforms and mention in the release notes (and elsewhere) that we need the hardware. Or perhaps we just mention in the release notes that this support is deprecated and will be removed in Gradle 2.0 unless we can get help with the hardware. I don't think a deprecation nag message is appropriate in this case. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
