Re: [ide-dev] Some Infos About Oomph
Thanks Eike. We¹ve downloaded the installer and showed it to a couple of
people on our QNX Momentics team. One of the things we¹re mainly concerned
about is having a good install experience for new users and use that
mindset when evaluating install technologies.
I guess, as a new user, I found it really confusing that the first thing I
was asked for was to set up a bunch of preferences, the first being
³Refresh Resources Automatically². New users won¹t likely know what the
preferences mean until they try it out, and they may never know what
Refresh Resources Automatically, means. What¹s a Resource?
Do you have an even simpler mode that skips over that part? We¹ve all seen
installers for product and they usually aim at the absolute newbie. The
idea is to get them into your product with the least amount of friction.
That first impression is pretty lasting, even if they only run the
I was just wonder what your philosophy is and what drove you to put the
preferences settings first.
On 2015-01-28, 8:07 AM, "Eike Stepper" <stepper@xxxxxxxxxx> wrote:
>Am 28.01.2015 um 13:08 schrieb Max Rydahl Andersen:
>> Where can I try that nice oomph looking installer ?
>You can download it from http://wiki.eclipse.org/Eclipse_Oomph_Installer
>> and is there a a way to reuse it for building my own custom installer of
>> non-eclipse.org content, such as JBoss Tools and/or JBoss Developer
>Yes, you'd need to repackage the installer with a slightly modified
>oomph.ini option. But let me start with some details
>about how product and project profiles are discovered (I'll omit the word
>Each product is logically contained in a product catalog and each project
>is logically either contained in a project
>catalog or, if it's a sub-project, in another project. All catalogs are
>logically contained in a catalog index. The
>index also contains pointers to SetupTask extension packages. All
>products, projects and extensions are thereby
>discoverable from the index. Physically the containment can an href,
>i.e., the entire index tree can be fragmented into
>many files. These files are typically accessible through a web browser.
>At Eclipse.org we maintain a default index:
>And the Eclipse.org product catalog:
>And the Eclipse.org project catalog:
>And a Github.com project catalog:
>The index and all the elements contained in it are referenced through
>logical URIs, for example index:/org.eclipse.setup
>for the index itself. The physical URIs are determined by Oomph's general
>URI-redirection facility, which is controlled
>through two different mechansims:
>1) URIRedirectionTasks that are specified in the applicable profiles, for
>example the user profile.
>2) System properties (or env vars if the dots are replaced by
>underscores) that are for example specified in the
>eclipse.ini (or oomph.ini for that matter). They have the form
> "-Doomph.redirection." + someID + "=" + fromURI + "->" + toURI"
>The involved URIs can point to directories, in which case they redirect
>that directory and its contents.
>The physical URI of our default catalog is hard-coded in Oomph, but it
>can be easily redirected to any other location.
>So, one way to provide a custom installer is to add the following to the
>On the other hand it might be better that you don't maintain an own index
>and require your users to use a repackaged
>installer. Instead we could add a new product catalog to the existing
>index at Eclipse.org. You could add your products
>there and people would see them immediately and could install them with
>their existing Oomph installer. If that sounds
>interesting I suggest you submit a bugzilla so that we can discuss the
>ide-dev mailing list
>To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit