Re: [ide-dev] Some Infos About Oomph

[Eike Stepper <stepper@xxxxxxxxxx>]

Am 29.01.2015 um 11:43 schrieb Mickael Istria:

Hey Eike,
Thanks for debating with me ;)

I like it. Although I'd prefer another shot at your french Rum Bar :P

[Still about the single IDE vs multiple IDEs there, not about Oomph provisioning existing IDEs with additional features and Git repo for the project, which seems good to me]
The separation I want to make is that there are developers who provide IDEs for other developers in order to make their project more accessible, which is IMO the one who are the most interested by Oomph; and the end-users, who code directly the project "payload". Those second type of users may not like using mutliple IDEs, and may prefer provisioning their ones, with their favorite plugins and so on, without introducing another technology to achieve that. This kind of users exists and explains why so many projects are more successful as plugins installed in Eclipse than as dedicated RCP applications.
They typically document their setup somewhere, or keep it in their memory for the future, and they're ok with that.

No, they're not. They just had to accept that there was no better way.

I don't find it realistic to expect SQL/JEE/JS developers to define their IDE in the Oomph language,

That's just a matter of the authoring tools (including automatic change recorders) being offered.

I'm starting to understand things better, the installer is basically a Oomph configuration editor,

Not really. The Oomph Installer is "just" a standalone (SWT) application that uses the Oomph Runtime to bootstrap an Eclipse installation. That typically includes the installation of p2 IUs, the modification of the eclipse.ini, the configuration of a matching Java VM and the launching of the installed product. The installer generally doesn'tt edit the involved profiles (with one technical exception that is not relevant here).

The profiles are usually edited inside an IDE with the Oomph Editor and other authoring tools such as automatic task generators.

and when clicking Finish on the wizard, the Oomph configuration gets materialized. Is that it?

Yes, the parts (Setup Tasks) of the profiles that can be performed outside of the to-be-installed product. Notice that most tasks need to be performed inside the IDE (new or not). Oomph currently defines three different triggers (Bootstrap, Startup and Manual) and each task knows for what triggers it can be performed.

What I find overkill is the manipulation of a new language

I was already wondering how long I can push myself to use the term "language" :P

Oomph uses extensible EMF models almost everywhere. Technically that's an abstract syntax or a domain-specific language (but not textual), but typically its instances (or "programs") are manipulated through tree structure editors. Automatic generators (sniffers or task builders) are available for specific tasks, too.

and a new type of file, whereas the IDE already provides definition/export/import of preferences, definition/import/export of SCM repo with psf files, definition/import/export of target-platforms.

Most of these existing mechanisms have no composition in mind. The target platform is a good example. Just imagine the steps needed by a developer to create a combined target platform for CDO, EMF and Xtext!

Generally Oomph tries to reuse these existing mechanisms wherever adequate. In some cases, especially when composition is desirable, we contribute our enhancements (well, we think they're enhancements) to these mechanisms. In some cases it made more sense not to reuse inadequate file formats.

I suspect that users don't care so much about the involved file formats if only they can easily achieve what they want.

The only missing thing is probably a format to define installed IUs

Right, though not the only one missing.

(.target files could maybe achieve that).

AFAIK., .target files don't support the specification of version ranges (except for the onmi version range), neither do they allow the specification of optionality or capabilities other than the self capabilities of their IUs. Not to talk about the questionable experience of the PDE Target Definition Editor (I've seen that some effort is ongoing to iron out at least some of its wrinkels).

Interestingly Oomph uses the same underlying language (jeesh, model) to define the content of composable P2DirectorTasks and composable TargletTasks.

So instead of yet-another-language, it seems easier to me to simply create a super "export IDE configuration wizard" and and "import IDE configuration" wizard that would composite those existing pieces.

Yes, but that is Oomph!

IMHO, the issue Oomph has tried to resolve is a pure UI issue.

I don't get that.

The alternative I suggested (which sounds more like an addition than an alternative) for a good 1st experience or a re-installation of Eclipse was a more integrated usage of marketplace favorites (which can be seen as a subset of a profile) inside the IDE directly, and some wizards while starting the IDE for the 1st time, allowing users to install their favorites marketplace entries  in IDE, advertising about Marketplace and MPC to make discovery easier for users.

Yes, but that is Oomph!

Granted, we haven't managed, yet, to implement "picking from market place" but it's on the list of things we want to do soon and definitely among the things that are very easy to do on top of the Oomph Runtime.

But talking is cheap and it's easy to say "should" ;)

Yes ;-)

I want to make it explicit that I'm not against Oomph, I'm mainly having this discussion to consolidate my understanding of the future Eclipse installer and to evaluate how helpful it would be for users.

I recommend to play a little with Oomph, both the installer and the runtime. I hope you'll recognize its potential.

Cheers
/Eike

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