openjdk build pages

[Martin Buchholz]

A slight tangent, but maybe y'all could expand the URLs that allow you to
download an entire repo to make this particular way of grabbing bundles
more convenient:

1. In addition to the various labels like "jdk7u40-b62" that include a
build number, when jdk7u40 is finally released, simply add a tag "jdk7u40"
that is the true final released jdk7u40.  It would point to the same
revision as the last build, presumably jdk7u40-b62".  This allows you to
download via URL, e.g.

http://hg.openjdk.java.net/jdk7u/jdk7u/langtools/archive/jdk7u40.zip<https://www.google.com/url?q=http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/archive/jdk8u5-b13.zip&usg=AFQjCNEkVB2epNK4B2YZSjcgmwvrvCqF0g>

2.  (some hg hacking required) Expand the per-repo URLs to download all the
repos with one URL, e.g.

http://hg.openjdk.java.net/jdk7u/jdk7u/whole-tree/archive/jdk7u40.zip<https://www.google.com/url?q=http://hg.openjdk.java.net/jdk8u/jdk8u/langtools/archive/jdk8u5-b13.zip&usg=AFQjCNEkVB2epNK4B2YZSjcgmwvrvCqF0g>


On Wed, May 21, 2014 at 4:44 PM, Omair Majid <omajid at redhat.com> wrote:

> * dalibor topic <dalibor.topic at oracle.com> [2014-05-21 05:15]:
> > Actually, I think that for 7u60 (and 7u80) we need to move in the other
> > direction, and not publish separate source bundles from the source code
> > that's already in the Project's Mercurial repositories.
>
> I encourage you to think again. The source code system used by OpenJDK
> (hg trees) is not straight-forward to work with for packagers, and needs
> non-standard tools, like the trees extension, to fetch complete and
> consistent things.
>
> Source bundles are really easy to work with as a packager. You know you
> got something consistent that works and don't have to mess around with
> source code control systems checking out various repositories and tags
> to find the 'right' source.
>
> > Beside being potentially error prone,
>
> I am not sure I understand. Surely you can write a script that grabs the
> right tags from the right forests to create a tarball. I could do it, if
> I knew exactly which forests and tags contain the right stuff (and could
> upload it somewhere on openjdk.java.net). In fact, I have something
> generic already written [1]. Feel free to use it.
>
> > and update releases that we can't work on as part of OpenJDK (like
> > 7u55),
>
> I am not sure I follow. If you can commit the source to the repository
> and tag it, why can't you create a source bundle for those tags?
>
> > The added complexity provides little benefit, and the simplest way to
> remove
> > the complexity is to remove the issue causing it, and educate users to
> use
> > the source ... directly from the respective source repository.
>
> I respectfully disagree with your solution. If not providing source
> bundles causes confusion, wouldn't the right fix be to provide source
> bundles?
>
> As for benefit, just today I saw people asking on #openjdk about where
> to get source bundles. And they complained that using source control to
> get a release bundles is too hard (and shouldn't be necessary).
>
> Also, if you think users have problems distinguishing 7u60 from 7u55,
> can you imagine the problems they will have trying to find the
> real/final tag for 7u55 in the repos? And how some tags do not exist in
> some repos at some points in time? [2].
>
> Thanks,
> Omair
>
> [1]
> http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/generate_source_tarball.sh
> [2]
> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2014-April/008969.html
> --
> PGP Key: 66484681 (http://pgp.mit.edu/)
> Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/web-discuss/attachments/20140521/3e366f69/attachment-0001.html>