[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[emf-dev] Re: Galileo build failed
- From: Nick Boldt <nickboldt@xxxxxxxxx>
- Date: Thu, 05 Feb 2009 15:05:06 -0500
- Delivered-to: firstname.lastname@example.org
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=jukheA1h4Yti5xx1XXZALjTKn2k4l0lzpy+wRgWDf0Y=; b=NCEQxfwDng2WQxfZ5zD3S83NFCn6Qydj479pbiRHemEgIy3OZK1dtrk7VO6cLIVbr9 +YZoGhBQH9QFKtSOQqomLV/ET8QzI3mLGYyRG/JuZSWYNszDCAnDpiovQu8oinL0ZCI6 VN2feJRoshPjnXhwHkfXXqjgdxuQ3VhwMgz00=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=ckixMLk2xK1eJkuUKqTCW9bkGy5AlgUf2vlrgUm/K5RkMLXbzyuH1YrHPTrjYTbYwb +MYZPtxtpq7SvwLmkJYmWFtHKeY2oFVvTA7KMz8/IiZZmFfR1xsL2KcFW4gCl5JXg5GE OBe31roSIOT3VzB4Wvlq85lAE3EsDVyRgWtBc=
- User-agent: Thunderbird 18.104.22.168 (X11/20090105)
(Extending distribution to -dev lists...)
The system works like this:
* Every new build produces a "category.xml" - it's not a valid XML
document, just a fragment for the category contributed to the overall
* Each new build (say, for EMF (Core) 2.5 on milestones site) will push
out the oldest of the 3 stable builds and keep only the new one + two
older ones. For I/M builds, we keep the three most recent ones; for R,
we keep two.
* Every new build also collects a list of jars that are still required
for the 1-3 builds kept on the site per project. This is done by storing
a copy of each build's features/ and plugins/ folder ON THE BUILD
SERVER. The list of jars to be kept is held on download.eclipse.org, and
each build server produces its own list.
* This is done so that we don't end up with an ever-larger update site
with irrelevant / unreferenced / obsolete jars. We need multiple files
because not all builds are produced on the same server, and thus we'd
either need to store all the update site jars + category.xml for each
build on download.eclipse.org, or cheat by use of the listfile. I went
the listfile route to save disc usage on download.eclipse.
* Every time a build is published, all jars NOT on the aggregate
jarlist.clean*.txt files for a given site are deleted. All category.xml
files for that site are merged to create the new site.xml files.
* The system, in theory, does its own maintenance and cleanup every time
a new build is added to the pile. Also in theory, we should never end up
with site.xmls that reference jars that are missing because the full
list of required jars comes from Master zip (signed + packed jars) ->
unpacked site on build server -> directory listing of included jars ->
So, the reason that EMF (Core) 2.4.0RC3 is still on the update site is
that it's the second newest milestone/stable build for EMF (Core) 2.4.
There's also 2.4.2RC1 on there. This is intentional.
What may not be intentional is that there are three site*.xml files in
the site, and I'm not sure from which one the content.jar and
artifacts.jar metadata are produced. I'd expect it to be the site.xml
(73K) file which should include EVERYTHING, not the smaller
site-galileo.xml (16K) or site-ganymede.xml (40K), but I'll have to
We may need to split these sites into separate streams for eclipse 3.4
and 3.5, if p2 or the amalgam/galileomatic is getting confused. This
would also prevent end users from installing, say, CDO 2.0 onto Eclipse
3.4. The only complication here is that unlike, say, PDT, who spawned a
/2.0/updates/ site, we'd have to do /e35/updates/ or /galileo/updates/
because everyone's at a different version number within a given project.
Of course renaming/moving update sites will also mean updating all your
feature.xml files to point at the new site.
Dave Steinberg wrote:
I have no idea how Nick's scripts remove old builds and manifest
entries. It seems odd that an old entry for a missing feature matters at
all when you're trying to update something newer, but then, I have no
idea how that works either.
Should I investigate, or can I hope Nick will?
Rational Software - IBM Toronto Lab
905-413-3705 (t/l 313-3705)
Inactive hide details for Richard Gronback ---02/05/2009 01:14:35 PM---I
suspect the problem here is the cleanup script. The reRichard Gronback
---02/05/2009 01:14:35 PM---I suspect the problem here is the cleanup
script. The referenced jar seems to be from 2.4.0RC3, which would make
sense to no l
Richard Gronback <richard.gronback@xxxxxxxxxxx>
Ed Merks <ed.merks@xxxxxxxxx>, Dave Steinberg/Toronto/IBM@IBMCA
<nickboldt@xxxxxxxxx>, Anthony Hunter/Ottawa/IBM@IBMCA
02/05/2009 01:14 PM
Re: Galileo build failed
I suspect the problem here is the cleanup script. The referenced jar
seems to be from 2.4.0RC3, which would make sense to no longer have on
the site, although the entry in the site.xml persists.
On 2/5/09 12:46 PM, "Ed Merks" <_ed.merks@xxxxxxxxxx> wrote:
I'm not sure if some magical promotion step was missing or
Richard Gronback wrote:
Sorry, was testing XSD (GEF error was expected).
XSD seems to install fine,
though exceptions are thrown due to the update
site problem mentioned
in the site manifest, but doesn't exist.
[exec] [exec] !SESSION 2009-02-05 12:32:11.159
[exec] [exec] eclipse.buildId=I20090202-1535
[exec] [exec] java.fullversion=J2RE 1.5.0 IBM J9
2.3 Linux ppc-32
j9vmxp3223-20071007 (JIT enabled)
[exec] [exec] J9VM - 20071004_14218_bHdSMR
[exec] [exec] JIT - 20070820_1846ifx1_r8
[exec] [exec] GC - 200708_10
[exec] [exec] BootLoader constants: OS=linux,
[exec] [exec] Framework arguments: -application
[exec] [exec] Command-line arguments: -os linux
-ws gtk -arch ppc
[exec] [exec] !ENTRY org.eclipse.equinox.p2.core
4 0 2009-02-05
[exec] [exec] !MESSAGE Provisioning exception
[exec] [exec] !STACK 1
not connect to _
On 2/5/09 12:33 PM, "Richard Gronback"
Contribution org.eclipse.gef.sdk version
failed to install from_
Check the log file for more
Nick Boldt :: http://wiki.eclipse.org/User:Nickb
Release Engineer :: Eclipse Modeling & Dash CBI