> That wasn't what I meant. I meant excluding the single file(s) that
> cause the problem.
Well you /could/ but I would claim that is not very desirable, since we
would have to back out some changes in the existing built code for
pack200, convince each IDE that not all files in the src/main were to be
compiled, remember that there is an out-of-line set of files for archive
etc. Sounds like a form of branching without really doing it.
...but I expect that we won't need any of this, I'm sure Alex can cope ;-)
Hope so. Not necessarily always timely (my day job tends to run into
my night job occasionally) but sooner rather than later.
Alex: can you send what you have done so far?
I've created Harmony 599
(http://issues.apache.org/jira/browse/HARMONY-599) with a zip of what
I've done so far. I don't believe that it has compile errors, and the
tests run OK -- it's just if I depend on a method/class that's not yet
available in the classpath build. Hopefully it should be relatively
easy to fix, and if I do contribute a breaking patch via JIRA then
whoever applies it should be able to tell me before it goes live.
>>> (Or just make Alex keep it working :)
>> That would be my preference -- the committer that applies the patch and
>> the continuous build can check win/linux compilation. If 'keeping it
>> working' is too onerous, then branch.
I guess that if it doesn't work at first, drop me a line and let me
know so that I can try to work around it. For example, I link in the
JavaDoc to java.io.GZipInputStream#MAGIC_BYTES or something, which
might cause an issue if that's not there or been implemented yet. Most
of it is byte-munging anyway; a bit of StringBuffer here and there,
and io.read(). Not really that much.
Alex.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
