- JNA is LGPL, ASF is -1 to anything with this license that you must have to work, so it will take some care to get this to co-exist. Having an ivy dependency that says JNA must be on the classpath is not going to work.
- I don't like the .conf files which seem to build up classpaths from hard coded paths, assume you are running from the build directories, and could not be used in production systems for this reason.The conf files are there because you've chosen one way to run Hadoop as service, but as there are other options, that's a different patch, independent of everything else.
- Moving from UnixUserGroupInformation to UserGroupInformation is going to break a lot of downstream code
- The usual space vs tab rules and other changes to javadocs complicate the patch.
- A patch to 0.20.x will only break everything that uses cygwin
- I expect for performance reasons not using the commons-compress libs on Unix makes sense, but that codepath should still be tested on unix, so that hudson catches problems.
- I don't see any explicit tests of the new stuff, so the only way this stuff would get tested now is if someone sets up Hudson on one or more windows versions and runs this as a service.
what you have done is very impressive, but as it stands, I'm -1 to this. I may be more amenable if
- There is a strategy which the hadoop dev teams and the ASF are happy with for using JNA. Building against it when present but not redistributing it is one option, in which case Hadoop on windows has to fall back to cygwin where JNA isn't on the path
- changes are against SVN_TRUNK, no attempt to support existing releases.
- the wrapper stuff is separated completely off from the JNA stuff. How you run Hadoop as a service on windows is independent from making Hadoop work without cygwin; merging the two just makes it harder to use.
- TaskRunner.normalizeClassPath() needs a complete rewrite following apache coding best practices, some test cases that are designed to work cross platform (hint: split the windows and unix options, test both)
- Minor: the patch shouldn't make changes to javadocs, line endings that aren't needed.
The big concern I have is the split between windows and everything else. I know you've eliminated cygwin, but you've added in requirements to understand the Win32 APIs, win32 vs win64 issues, and a separate windows codebase that will need to be tested on 32-bit and 64 bit versions of Windows Vista, Win7 and windows server; 6 different OS combinations we currently avoid.
That scares me.