On 10:52 Tue 11 Oct , 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.
>
FWIW, I recently did exactly that in IcedTea because I'm sick of all the
problems this drop solution causes.
This has cut things down from needing five tarballs (jaxp + jaxws repositories
+ three drop zips) to two with
everything in. Should someone really want to build from the tarballs, they can
just delete the sources.
I don't see why touching the files is a problem; surely all changesets have to
pass review and any that attempt to
alter this files would just not do so? What am I missing?
> -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
>
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
