Eclipse Community Forums: Oomph » Running an arbitraty project.setup

Home » Eclipse Projects » Oomph » Running an arbitraty project.setup (Possible to run a project.setup not previously known by Oomph?)

Show: Today's Messages :: Show Polls :: Message Navigator

Running an arbitraty project.setup [message #1778835]

Fri, 22 December 2017 10:46

Anders Jönsson

Messages: 48
Registered: January 2012

Member

Hej,

We are using Oomph to provison an Eclipse IDE to a fairly large organisation with a lot of teams and projects.
We now want to make use of Oomph project setups to make it easier for a team member to get started working on a project, by automating the import of other needed projects and plugins.

What we would like to do is to place a project.setup file in each "code-project", i.e. in a git-controlled directory.
The user will import the main code-project into Eclipse IDE, find the project.setup and run it... somehow. We expect to invoke some Oomph API maybe?

Is this doable?

To be clear. Since there are many projects, and since we want the teams to easily create and manage projects and project setups themselves, there should be no reference from any central Oomph file to the project setup files, i.e. the Oomph installation itself cannot know about these project setups.

///Anders

Report message to a moderator

Re: Running an arbitraty project.setup [message #1778845 is a reply to message #1778835]

Fri, 22 December 2017 12:39

Ed Merks

Messages: 33133
Registered: July 2009

Senior Member

Do your git repositories support a web view that serves up plain text resources? E.g, github supports links like this: https://raw.githubusercontent.com/merks/sample/master/project/README

Generally the Project Catalogs are designed to help make the Project setups discoverable and therefore acts as an index. But a Project Catalog itself can be extensible via a special contained Project with a special URI like this one:

 <project href="user:/org.eclipse.projects.setup?name='user.project',label='&lt;User>',description='A container project for local user projects that are virtual members of the Eclipse.org project catalog'#/"/>

This will demand create a sub-Project that's local to the user and they can add sub-Projects to this Project so that they're "virtually" in the Project Catalog as a contained child and can therefore inherit the common set tasks (and variables) of the containing Project Catalog.

So you could create such a Project Catalog with a user extensible sub-Project and that would allow the users to add their object Project setups.

But to me it would seem better if you provided a central Project Catalog that already has references to the Project setup of each team. Because Projects can nest, each team then has control over adding any number of sub-Projects to the root Project without needing to ask the manager of the central Project Catalog to add anything each time the team wants to add something. Managing one link per team would not seem like too much central management overhead to me.

Note that https://wiki.eclipse.org/Eclipse_Oomph_Authoring#Hosting_your_own_index_.2F_catalogs describes how you can use -Doomph.redirection.myProjectCatalog=index:/redirectable.projects.setup-> to add a Project Catalog to Oomph "standard" index. You can of course host your own instead, if you want. This is why I ask about plain text links to your git repositories, i.e., will you be able to provide links to setups in the Git clone without needing to clone it locally first to see it. I expect such support is easily enabled if not already available. Also note that using Configuration https://wiki.eclipse.org/Eclipse_Oomph_Authoring#Automation_and_Specialization_with_Configurations you can automate the selection of the Products and Projects including the addition of Product or Projects to the user extensible catalogs.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Running an arbitraty project.setup [message #1778872 is a reply to message #1778845]

Fri, 22 December 2017 17:46

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

Hi Anders,

I imagine we could develop something that discovers IProject-specific setup fragments, for example directly after a Git-checkout/import, and informs the user, or asks whether the installation should be updated accordingly. Is that what you have in mind? If so, and if your large organization is able to fund such development, it would be great if you contacted me directly.

Cheers
/Eike

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Re: Running an arbitraty project.setup [message #1778977 is a reply to message #1778872]

Wed, 27 December 2017 10:55

Anders Jönsson

Messages: 48
Registered: January 2012

Member

Ed, Eike, thank you for your much appreciated answers.

We are focusing on automation for several reasons. One of them is to reduce errors. The most time consuming type of error is when "someone else far away" changes something that breaks "my" project. This is of cause handled by decoupling. We do not want to add yet another dependency, we struggle with the ones we got.

Ed wrote:
> Managing one link per team would not seem like too much central management.

It may not be to much work but I see it as a kind of unwanted dependency. Is this central management fault tolerant? If this means that 10 or 100 people are going to fiddle with the same central file the risk of breaking someone else's project seams significant.

Also, we want a short development cycle for the project.setup. This means that it should ideally be possible to write and run a project setup locally without pushing/building/publishing before being able to test it.

Eike wrote:
>I imagine we could develop something that discovers IProject-specific setup fragments.

Yes, that sounds very interesting. I imagine this should make it possible to use project.setups without any central management. I also imagine this would mean that project setup development can be made completely local. A few thoughts:
- It will have to work across multiple (git-) repositories with interdependent IProjects.
- git is frequently used on the command line (not necessarily known to eclipse). The discovery must handle this, maybe by being possible to start manually.

Regards
///Anders

Report message to a moderator