Hey, What's the main motivation of moving away from jna/jansi?
Cheers! On Thu, Oct 11, 2012 at 8:19 AM, Adam Murdoch <[email protected]> wrote: > 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 > -- Szczepan Faber Principal engineer@gradleware Lead@mockito --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
