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
>>
>
