On 11/10/2012, at 7:19 AM, Adam Murdoch wrote: > Hi, > > We've now started using our new native integration > (https://github.com/adammurdoch/native-platform).
Is this its long term home? That is, do you want it to live outside of Gradle/Gradleware? > 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. I wonder how we can go about getting this hardware. I seem to remember us asking the public about this recently. Perhaps we should try this again. > 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. Can we approach corporate Gradle users that we know about this? Perhaps they could either donate some hardware, or we could buy their old hardware. Perhaps we could package it with Gradleware services or something like that. Regardless, we should try a serious campaign to get these resources donated by the public. Even if we get the hardware though, we need to host it somewhere. Tricky. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
