2009/8/10 Kelly O'Hair <kelly.oh...@sun.com>: > > Andrew John Hughes wrote: >> >> 2009/8/10 Kelly O'Hair <kelly.oh...@sun.com>: >>> >>> Andrew John Hughes wrote: >>>> >>>> 2009/8/8 Andrew John Hughes <gnu_and...@member.fsf.org>: >>>>> >>>>> 2009/8/8 Kelly O'Hair <kelly.oh...@sun.com>: >>>>>> >>>>>> Andrew John Hughes wrote: >>>>>>> >>>>>>> 2009/8/8 Kelly O'Hair <kelly.oh...@sun.com>: >>>>>>>> >>>>>>>> Yeah. I tossed this around in my head, drop seemed short and cute. >>>>>>>> ;^) >>>>>>>> Most if not all the import components are tools used to do the build >>>>>>>> but not sources that became part of the product built bits. >>>>>>>> >>>>>>>> Maybe the IcedTea guys can chime in on this. >>>>>>>> >>>>>>>> I'm happy to change it to another name that makes more sense. >>>>>>>> >>>>>>>> -kto >>>>>>>> >>>>>>>> Jonathan Gibbons wrote: >>>>>>>>> >>>>>>>>> Well, elsewhere in the JDK build, the name "import" seems to cover >>>>>>>>> the >>>>>>>>> same concept >>>>>>>>> of inbound stuff from outside the repository. >>>>>>>>> >>>>>>>>> But, I know you do similar stuff in the FX world, so I wasn't sure >>>>>>>>> if >>>>>>>>> "drop" came from there. >>>>>>>>> >>>>>>>>> -- Jon >>>>>>>>> >>>>>>>>> Kelly O'Hair wrote: >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> The drop name just dropped into my head :^) >>>>>>>>>> >>>>>>>>>> Do you have a better name for it? >>>>>>>>>> >>>>>>>>>> -kto >>>>>>>>>> >>>>>>>>>> Jonathan Gibbons wrote: >>>>>>>>>>> >>>>>>>>>>> Is the "drop" name a standard convention, as compared to, say, >>>>>>>>>>> "import"? >>>>>>>>>>> >>>>>>>>>>> -- Jon >>>>>>>>>>> >>>>>>>>>>> >>>>>>> 'drop' sounds fine and makes sense to me at least. >>>>>>> >>>>>>> On more important matters, if I'm reading this right it does the >>>>>>> following as part of the build: >>>>>>> >>>>>>> #1: Finds a JAXP zip either via ALT_JAXP_SOURCE_BUNDLE or, failing >>>>>>> that, downloads one >>>>>>> #2: Extracts that bundle >>>>>>> #3: Builds the code >>>>>>> >>>>>> Yes, but actually if the drop area already exists, #1 and #2 are >>>>>> skipped. >>>>>> So if we bundle up a jdk source bundle and preload the drop/src in it, >>>>>> then that works too. >>>>>> >>>>>>> If that is the case, it sounds a hell of a lot like what IcedTea does >>>>>>> with OpenJDK anyway, so I can't see that much of a problem. Is there >>>>>>> a bundle available so this can be tested? >>>>>>> >>>>>> Yes, this should work now. The copy will fail, then it should download >>>>>> a preliminary one we are testing with. >>>>>> >>>>> Great. I'll try and have a quick look over the weekend and test it >>>>> with IcedTea. >>>>> >>>>>>> On the plus side, it would mean we weren't duplicating the JAXP and >>>>>>> JAXWS code about thirty times. >>>>>> >>>>>> Yup. >>>>>> >>>>>>> On the negative side, it makes it even less clear how changes get >>>>>>> into >>>>>>> these. We no doubt have some local ones already that would be lost >>>>>>> by >>>>>>> using the bundle (though I think most are build changes to Makefiles >>>>>>> like DEBUG_CLASSFILES). I don't think that's a blocker, but there >>>>>>> needs to be a clear documented route for getting patches into JAXP >>>>>>> and >>>>>>> JAXWS just like we get them into the rest of OpenJDK. >>>>>> >>>>>> The JAXP changes would need to go through the JAXP team, I don't think >>>>>> that is a change, formal changes to these files always went through >>>>>> that >>>>>> team as far as I know. >>>>>> This should make it easier for the JAXP team to integrate their >>>>>> contribution into jdk7, so in theory we could get more frequent and >>>>>> newer JAXP sources. >>>>>> >>>>> Ok, I suppose what I meant is that the JAXP team is external to the >>>>> OpenJDK project as far as I'm aware. While those of us external to >>>>> Sun are just about getting our heads round the processes and rights >>>>> involved in committing something here, I imagine it's a completely >>>>> different setup for JAXP. Is there some resource that will point us >>>>> in the right direction for JAXP and JAXWS? >>>>> >>>>>> I did put a patch mechanism in place, for jdk7 emergencies. >>>>>> But I would think the first choice would always be to get a fresh >>>>>> drop bundle. >>>>>> >>>>>>> Any plans to do something similar with CORBA? :) >>>>>> >>>>>> Maybe... jaxp and jaxws first. corba is not part of the plan right >>>>>> now, >>>>>> but who knows... >>>>>> >>>>>> -kto >>>>>> >>>>>> >>>>> Thanks for this, >>>>> -- >>>>> Andrew :-) >>>>> >>>>> Free Java Software Engineer >>>>> Red Hat, Inc. (http://www.redhat.com) >>>>> >>>>> Support Free Java! >>>>> Contribute to GNU Classpath and the OpenJDK >>>>> http://www.gnu.org/software/classpath >>>>> http://openjdk.java.net >>>>> >>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>> >>>> No luck it seems... >>>> >>>> [echo] Downloading from >>>> https://jaxp.dev.java.net/files/documents/913/140275/jdk7-jaxp-m5.zip >>>> [get] Getting: >>>> https://jaxp.dev.java.net/files/documents/913/140275/jdk7-jaxp-m5.zip >>>> [get] To: >>>> /mnt/builder/openjdk.icedtea/jaxp/drop_bundles/drop-src.zip >>>> [get] Error getting >>>> https://jaxp.dev.java.net/files/documents/913/140275/jdk7-jaxp-m5.zip >>>> to /mnt/builder/openjdk.icedtea/jaxp/drop_bundles/drop-src.zip >>>> >>>> -drop-src-update: >>>> [mkdir] Created dir: /mnt/builder/openjdk.icedtea/jaxp/drop/sources >>>> [unzip] Expanding: >>>> /mnt/builder/openjdk.icedtea/jaxp/drop_bundles/drop-src.zip into >>>> /mnt/builder/openjdk.icedtea/jaxp/drop/sources >>>> >>>> BUILD FAILED >>>> /home/andrew/projects/openjdk/upstream/icedtea/jaxp/build.xml:187: >>>> Error while expanding >>>> /mnt/builder/openjdk.icedtea/jaxp/drop_bundles/drop-src.zip >>>> java.io.FileNotFoundException: >>>> /mnt/builder/openjdk.icedtea/jaxp/drop_bundles/drop-src.zip (No such >>>> file or directory) >>>> >>>> Built using my usual script: >>>> >>>> LANG=C make ALT_BOOTDIR=/usr/lib/icedtea6 \ >>>> ALT_OUTPUTDIR=/mnt/builder/openjdk.icedtea \ >>>> ALT_PARALLEL_COMPILE_JOBS=9 \ >>>> HOTSPOT_BUILD_JOBS=9 \ >>>> ALT_JIBX_LIBS_PATH=/home/andrew/projects/openjdk/jibx \ >>>> ANT=/usr/bin/ant >>> >>> Try doing a 'ant clobber' then 'ant' again. >>> >>> I was able to download this file from my home network fine, but >>> java.net downloads are not horrible reliable, the bundle may be >>> truncated? I suppose I should download to a temp file, then move >>> it to the real file if there was no failure. I'll look at that. >>> This ant scripting is a bit bizarre. :^( >>> >>> -kto >>> >> >> No luck, even wget seems to have stalled on it: >> >> wget -v >> https://jaxp.dev.java.net/files/documents/913/140275/jdk7-jaxp-m5.zip >> --2009-08-10 04:04:25-- >> https://jaxp.dev.java.net/files/documents/913/140275/jdk7-jaxp-m5.zip >> Resolving jaxp.dev.java.net... 204.16.104.198 >> Connecting to jaxp.dev.java.net|204.16.104.198|:443... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 5912912 (5.6M) [application/zip] >> Saving to: `jdk7-jaxp-m5.zip' >> >> 29% [======================> >> ] 1,736,704 489K/s eta 11s > > Can you try curl?: > > curl -o jdk7-jaxp-m5.zip > https://jaxp.dev.java.net/files/documents/913/140275/jdk7-jaxp-m5.zip > > If curl fails too, then it seems we have a server issue on java.net, > but why does it work for me and not you? :^( > > FYI... The version of wget on my Mac is 1.11.4: > > KellyMacBook.local<12> wget --version > GNU Wget 1.11.4 > > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://www.gnu.org/licenses/gpl.html>. > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Originally written by Hrvoje Niksic <hnik...@xemacs.org>. > Currently maintained by Micah Cowan <mi...@cowan.name>. > > > > -kto > >
Strangely, curl worked so if I hack the delete invocations out of the ant script and copy it into place, I can build... but that's not really a solution :) Has anyone else managed to download this successfully? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
