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