Installer without external URLs

[tanaga-fh]

Due to government regulations it is not allowed to contact p2 repos in the external network. For this reason I have stored all dependencies locally in p2 repos. These are stored in the oomph setup files and are also used. Unfortunately, oomph includes additional external repositories during installation. Now the question is how can I redirect them to the internal repositories? One idea was to add a -D..redirect in the eclipse-inst.ini. However, this refers to the org.eclipse.setup index. I have created my own index. However, it does not work properly. First a message “No configuration found” appears. And in the startup phase only the P2 task is found. Individually as User Product and Project it works but then with the external oomph URLs.

In addition, the OS browser always opens with empty content when selecting a product. Even if I temporarily activate the proxy. Both with the original Eclispe products such as RCP and with my own product.

There is nothing usable to be found in the setup.log.

[merks]

In general there are redirection tasks that will modify (redirect) the URIs of any p2 task, e.g., I use this to fake there being a next release before there really is one:

The system property oomph.update.url controls which URL is used for Oomph updates.

If you given an example of a URL that's being contacted I might have more of a clue the specifics.

It's pretty tricky to get your own index working. Lot's of trick URI considerations so it's hard to help without more specifics about exactly what you are trying. Setting up and Oomph development environment and running things under debug control is probably the best approach to track down problems...

[tanaga-fh]

Thank you very much. The redirection of the p2 URL works so far.

On the subject of index and product/project catalogs, a small example would be good. The oomph original org.eclipse.setup, product and product setups are too confusing. And the documentation still refers to an old version where you should use -D...redirection=https://git.eclipse...->.

Currently I have simply created an org.eclipse.setup that refers to a product.setup with one product and a project.setup with two projects.

Using DaD I drop the org.eclipse.setup in Advance Mode into the head line of the product view of the installer. The product and then the project can be selected. The installation starts and Eclipse starts. Unfortunately only the p2 task of the product is displayed, all tasks of the project are not considered in the STARTUP and MANUAL phase. I suspect the models such as are missing. Do I have to consider anything else?

[merks]

Good documentation is a lot of work and then it gets stale, or they kill the vehicle for delivering it. And yes, it's pretty tricky to do so many magical things correct. I'm not sure what to suggest. It's a lot of work to explain and help and I have so many other things that I need to get done. 😱

[tanaga-fh]

Thank you very much for your support.
Then I'll go and look for the magic of the oomph index. (-;

[merks]

My suggestion would be to make a complete copy and gradually delete parts. Prune out projects and products from the catalogs. Reduce to just one project and one product catalog. Make sure things keep working as you go. Even do this in place in the oomph development environment where you can easily debug launch the installer.

[merks]

There are really useful options in the launcher in the IDE:

-Doomph.update.url=${file_uri:${resource_loc:/org.eclipse.oomph.site}}/target/repository/
-Doomph.redirection.setups=https://raw.githubusercontent.com/eclipse-oomph/oomph/master/setups/->${file_uri:${resource_loc:/setups}}/
-Dorg.eclipse.ecf.provider.filetransfer.excludeContributors=org.eclipse.ecf.provider.filetransfer.httpclientjava
-Duser.home=${system_property:user.home}
-Doomph.setup.user.home.redirect=true

It lets you use the update site build in the IDE (via the External Tools launcher), lets you use the setup/index you have in the workspace in the installer (and in the installations you create), use the older ECF provider (if necessary), specify where the installer thinks is your user.home, and tells the installer to generate -Duser.home in the installation so it uses your local index. Then it's possible to delete the entire "fake user home" clean up and do a fresh test.

This is far better than trying to get things working without really being able to debug it and without really seeing and understand how it's actually working.