Improving source drops documentation

[Jonathan Gibbons]

..  you could use a patch file instead of a zip file.

-- Jon

On 10/11/2011 11:35 AM, Kelly O'Hair wrote:
> Checking in any binary files is frowned upon.
>
> -kto
>
> On Oct 11, 2011, at 6:54 PM, Dan Smith wrote:
>
>> So it sounds like doing anything to improve the current setup would be a waste of time, since it's just going to go away.  That's fine.
>>
>> Is committing zip files frowned upon?  That would make clear that the "source" is the intact bundle, not a bunch of separate, editable files.  Just a thought...
>>
>> —Dan
>>
>> On Oct 11, 2011, at 1:52 AM, Kelly O'Hair wrote:
>>
>>> My plan of record has been to just unzip these bundles right into the repositories and get rid of this painful
>>> situation, that I have to confess, I created. :^(
>>> But I was thinking I could come up with some kind of way to paint these sources RED or something so
>>> that people do not patch these files, but instead feed changes to the upstream jaxp and jaxws open source projects.
>>> These files are like generated files, re-packaged and different legal notices from the originals, by the
>>> jaxp and jaxws teams.
>>>
>>> I could just declare 'do not edit these files unless you have approved' and hope that people obey that rule.
>>>
>>> I just haven't had the cycles to deal with this of late.
>>>
>>> This is a sore point in building that we really need to fix.
>>>
>>> -kto
>>>
>>> On Oct 11, 2011, at 2:14 AM, Dan Smith wrote:
>>>
>>>> I build infrequently, but when I do, I often get errors due to out-of-date jaxp and jax-ws source bundles.  My typical process is something like this:
>>>>
>>>> 1) Start to build
>>>> 2) Observe a failure complaining about an improper $ALT_DROPS_DIR
>>>> 3) Track down my note where I wrote down the URL where I can get to a Web view of /java/devtools/...
>>>> 4) Navigate to the right folder and look for file timestamps that are more recent than the last time I did this
>>>> 5) Download&  save the appropriate files to my source drops dir
>>>> 6) Try again
>>>>
>>>> I think this is more or less the "best practice," but correct me if I'm wrong.  In particular, I'm not relying on mounted access to the /java filesystem, as I think most veteran Sun employees do, and I'm not using ALLOW_DOWNLOADS, which is discouraged in the build documentation.
>>>>
>>>> Short of getting rid of the source drops entirely, it seems like there's a lot that could be done to streamline this process.
>>>>
>>>> - It would be nice if the sanity check caught the missing files, rather than waiting to complain in the middle of the build.  (Fortunately, at least these get built early.)
>>>>
>>>> - The error message would be a lot more useful if it told me the name(s) of the missing file(s) (which includes the version number) rather than assuming that my ALT_DROPS_DIR setting is wrong.
>>>>
>>>> - Even better, the error message could spit out the URL(s) where I could download the file(s)!  (This should be the same URL as used by ALLOW_DOWNLOADS.)
>>>>
>>>> - The docs ("Creation of New Source Drop Bundles") say the OpenJDK team puts new bundles in "/java/devtools/...", which is difficult to access.  (Can non-Oracle folks get to it? I rely on the javaweb internal server, which happened to be down today...)  Is/could this directory be made available somewhere public, too?
>>>>
>>>> Thanks,
>>>> Dan