Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 12:30 Go to next message
Rice Bauer is currently offline Rice BauerFriend
Messages: 3
Registered: August 2009
Junior Member
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
Re: Complete versioning support of target / targlet with OOMPH ? [message #1797681 is a reply to message #1797662] Mon, 05 November 2018 05:50 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30461
Registered: July 2009
Senior Member
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.
Previous Topic:Targlets and p2 profiles
Next Topic:Product setup does not set Preferences
Goto Forum:
  


Current Time: Sun Sep 22 09:52:02 GMT 2019

Powered by FUDForum. Page generated in 0.01393 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top