openjdk build pages
dalibor topic
dalibor.topic at oracle.com
Thu May 22 15:22:04 UTC 2014
Once an update release is released, cloning its forest will give you the
OpenJDK source code for the release, as the forests are sealed once a
release has been published. So there is no need for an explicit GA tag,
etc for such releases - just cloning without any tags will do the job.
On 22.05.2014 04:08, David Holmes wrote:
> On 22/05/2014 11:47 AM, Martin Buchholz wrote:
>> 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.
>
> The problem with the build tags is that you have to know which build is
> the GA build beforehand - so a "GA" tag would be generally useful I think.
>
> But that would not address the issue with non-public releases, like
> 7u55, as there is no GA build of that release in that forest. Even if
> you add a tag after all the corresponding changesets are added, that
> wont give you 7u55, it will give you 7u plus the 7u55 changes.
>
> David
> ------
>
>>
>> On Wed, May 21, 2014 at 6:38 PM, Martin Buchholz <martinrb at google.com
>> <mailto: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
>> <mailto:omajid at redhat.com>> wrote:
>>
>> * dalibor topic <dalibor.topic at oracle.com
>> <mailto: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
>> <http://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
>>
>>
>>
--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>
ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Geschäftsführer: Jürgen Kunz
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment
More information about the web-discuss
mailing list