Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [modeling-pmc] Re: [emf-dev] Builds: The never ending nightmare

Martin:

I've run your build locally and notice that the output is not a zipped update site.

So, to use the promote.xml script, you will need to:

a) zip up your update site (if you want a zip)
b) cp the zip + update site folder from build.eclipse to download.eclipse using the promote.xml script, passing in a few properties to define source and target dirs:

http://wiki.eclipse.org/Common_Build_Infrastructure/Publishing

You also don't appear to be producing zips of your tests or individual SDK/runtime "runnable" zips, so if that matters you'll have to produce those too. Failing that, it's fairly easy to set up your existing download page to no longer look for those deprecated zips and focus on just the update site zip as the single offering per build.

Of course if you want to drop zips entirely and just publish a weekly update site... that works too.

Oh, and of course the same story applies to the EMF build once that build gets redone as a Bucky build instead of an Athena one.

FWIW, I love the fact that the Bucky build can calculate what is needed in the target runtime without anything more than a pointer to sources (Bucky .rmap replaces PDE .map file) and a list of update sites (Bucky uses .rmap, Athena uses build.properties). Athena unfortunately cannot yet do this magic w/o an explicit list of repos + features/plugins or SDK/runtime zips.

However, Athena does produce prettier test output, more zips, zipped update site, and even now has the option to insert associate sites into the repo's metadata (so that for example a build could automatically add/enable SVN provider URLs in the list of available update sites). And because your stuff is ultimately going on the web, it produces simple index.php files so people can browse your content. Anyway, pros and cons, that's all I'm saying. :)

N

On 03/02/2010 01:18 AM, Martin Taal wrote:
Hi,
Here is the wiki page describing the Teneo build setup
(Buckminster/Hudson) in some detail:
http://wiki.eclipse.org/Teneo/Teneo_Build_Setup

The remaining thing for Teneo is to use how I can use the promote.xml
script to promote scripts to the modeling update sites and download
locations. I will update the wiki page with any changes I will make (you
can watch the wiki page to get notified of changes).

With Regards, Martin Taal

Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@xxxxxxxxxxxxxx - mtaal@xxxxxxxxx
Web: www.springsite.com - www.elver.org



Stéphane Bouchet wrote:
Hi Martin,

Maybe you could share your build experience on a wiki pages for others
builds team ?

Martin Taal a écrit :
Hi All,
Teneo is doing builds using Buckminster and it works nicely for me.
It required some setup but I have now good control over the build
process. And the number of configuration files is pretty modest. Also
a multi-step build procedure (build core plugins, create test
environment, run tests) was quite doable.
I liked it that buckminster helps to auto-retrieve dependencies,
build the target platform and setup the build workspace.
The buckminster people have been quite responsive on the newsgroup also.

I don't know the specifics of other builds but I think that both CDO
and Teneo offer good example setups if you want to use buckminster to
do the build.

gr. Martin

Ed Merks wrote:
Guys,

As I mentioned yesterday, CDO has been converted to use Buckminster
with Cloudsmith's help and Teneo is also in the process of doing
that. The Cloudsmith folks are offering to help convert a bunch of
the projects over, starting with the projects in EMF itself, e.g.,
the core. I'd like to see how that progresses. Once all the
subprojects of EMF are successful, we can look at replicating that
success. The advantage of this approach, as I see it, is that we'll
have a dedicated professional build organization to help us with our
common problems going forward. And in the longer term, we'll be able
to easily migrate to b3 as that involves; a model-based build system!

Cheers,
Ed
_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/emf-dev



_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/modeling-pmc

--
Nick Boldt :: http://nick.divbyzero.com
Release Engineer :: Eclipse Modeling & Dash Athena


Back to the top