Am 29.01.2015 um 11:43 schrieb Mickael
I like it. Although I'd prefer another shot at your french Rum Bar
Thanks for debating with me ;)
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]
No, they're not. They just had to accept that there was no better
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.
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.
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.
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.
I find overkill is the manipulation of a new language
I was already wondering how long I can push myself to use the term
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.
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
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
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.
only missing thing is probably a format to define installed IUs
Right, though not the only one missing.
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
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
Yes, but that is Oomph!
the issue Oomph has tried to resolve is a pure UI issue.
I don't get that.
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
talking is cheap and it's easy to say "should" ;)
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
I recommend to play a little with Oomph, both the installer and the
runtime. I hope you'll recognize its potential.