Eclipse Community Forums: Oomph » Complete versioning support of target / targlet with OOMPH ?

Home » Eclipse Projects » Oomph » Complete versioning support of target / targlet with OOMPH ?

Complete versioning support of target / targlet with OOMPH ? [message #1797662]

Sun, 04 November 2018 07:30

Eclipse User

Hi everybody,

we've been using OOMPH for our team for some time now to setup the development IDE for an Eclipse RCP project and it's really charming.
We make the latest version of the setup file available to our team at say https://example.com/master/oomph.setup and we use that URL in the Eclipse Installer.
The setup file contains (amongst others) a Targlet task and also a TargetDefinitionGenerator task that generates the target file for our Tycho build. We commit the generated target file to the RCP project's Git repo, so Tycho should always be able to build every version (every Git commit).
The target platform of the Eclipse IDE however always points to the latest version of the targlet.
Thus, whenever one developer checks out an old version (one that uses another target file), the Tycho build still works, but the IDE shows missing dependencies due to the Target Platform pointing to the wrong targlet.

I've also added a graph to illustrate our problem:
index.php/fa/34233/0/

Are there ways to achieve this kind of complete versioning with OOMPH?

Best regards
Rice

Attachment: oomph-versioning.jpg
(Size: 176.71KB, Downloaded 366 times)

Re: Complete versioning support of target / targlet with OOMPH ? [message #1797681 is a reply to message #1797662]

Mon, 05 November 2018 00:50

Eclipse User

You'd need to version the setup itself. Typically the Project setup is maintained in the same Git clone as the projects that it sets up. It would be referenced via a plain text link to the master branch version in that repository. E.g.,
http://git.eclipse.org/c/emf/org.eclipse.emf.git/plain/releng/org.eclipse.emf.releng/EMF.setup
The Project setup can then contain a task like this:

<?xml version="1.0" encoding="UTF-8"?>
<setup:EclipseIniTask
    xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI"
    xmlns:setup="http://www.eclipse.org/oomph/setup/1.0"
    option="-Doomph.redirection.emf.setup"
    value="=http://git.eclipse.org/c/emf/org.eclipse.emf.git/plain/releng/org.eclipse.emf.releng/EMF.setup->${emf.git.clone.location|uri}/releng/org.eclipse.emf.releng/EMF.setup"
    vm="true"/>

I.e., it will generate a -Doomph.redirection.* system property in the eclipse.ini of the installation. The * is arbitrary but of course should be unique if there are other project setups involved. This causes the URI to be redirected to the version in the local clone, once the clone is in place. So the installation uses the local cloned version of the setup, and you can change it and test it locally before committing changes to it. The setup itself is then versioned in the clone, so if you check out an older commit in the clone, the IDE would see that older version of the setup, so you could Perform the Targlet Task again to resolve dependencies in the older way.

The tricky part is if accessing the plain text link to the setup in the Git repository web view requires authentication. As of the most recent release of Oomph, there is support for cookie-based authentication as used by Github/Gitlab-type hosts. E.g, you can use a URI of this form:
https://github.com/<user>/<repo>/raw/master/<path>/<Project>.setup?oomph_form=b'login'
Such a URI is processed by org.eclipse.oomph.setup.internal.core.util.ECFURIHandlerImpl.Main.transform(URI, Map<Object, Object>) which forces the URI handling logic to visit https://github.com/login first where it finds and downloads an HTTP form. Oomph will then prompt for the user name and password to submit that form, acquiring the cookie it needs to access the original URI so that it can download the actual Project setup.

Note that the process of creating an installation can be made easier by using a Configuration. E.g, see the instructions on this page:
https://ci.eclipse.org/emf/
Then the user only needs to drag and drop(apply) the Configuration on/to the installer. The Configuration itself need not be versioned; it is used only as a template to initialize the installer pages (and the Installation and Workspace setups it uses). The Configuration processing can automatically add the Project setup to the User extension of the Project Catalog in which the setup is logically contained.

Re: Complete versioning support of target / targlet with OOMPH ? [message #1821052 is a reply to message #1797681]

Tue, 04 February 2020 15:52

Eclipse User

Hey Ed,

I just came across this post as I logged in for another issue.

We thought we had a problem with cookie-based authentication at first - the installer came to a state where it crashed reproducibly and in the end, we switched to unathenticated access.
Meanwhile I think the root of the problem was the incapability of Eclipse to store different HTTPS credentials for different paths of the same host name, so I guess it wasn't a problem with the installer.

The redirection of the setup file works really smoothly by the way. I hope you accept my slightly late thank you :-)

Best regards
Rice

Previous Topic:	Combine Product and Project setup
Next Topic:	stale cache until restart

Goto Forum:

-=] Back to Top [=-

Current Time: Thu Jul 24 14:20:31 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter