openjdk build pages

[Martin Buchholz]

Another way to look at it is that "jdk7u40" is a tag that will gather far
more interest than the build-specific tags "jdk7u40-b62" currently
available, which are likely mostly of interest to Oracle release
engineering.


On Wed, May 21, 2014 at 6:38 PM, Martin Buchholz <martinrb at google.com>wrote:

> 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/11f91095/attachment.html>