Thanks for debating with me ;)
First of all, I'd like to make it clear that my focus here is on
new or returning users. I understand Oomph targets a wider scope,
but my answers only consider this restricted one.
On 01/29/2015 09:52 AM, Eike Stepper wrote:
Ok, that's cool.
Am 29.01.2015 um 08:16 schrieb
I'd be careful with assumptions about what all people want to do
or not. It's more likely that some people want to use a single IDE
with many different extra tools and some people want dedicated
IDEs for their workspaces. That's why Oomph is carefully designed
to make them all happy.
On 01/28/2015 08:39 PM, Doug
I agree with Doug.
Well, no, the experience I’m looking for is the one I got
recently installing the community edition of Visual Studio
and had when installing Xcode. They just give you everything
at a push of a button. Big, yes, 5+ Gig big, but a pretty
good experience and bloat isn’t really noticeable once
I don't think people want to deal with multiple instances of
their IDE, they want only one, which adapts to the current
activity to show relevant stuff.
Personally I'm (and many people who started using Oomph are)
totally cured of keeping a single uber-IDE intact. In many cases
it's just not possible to install certain tools together and in
some cases it seems possible but leads to bad results.
But again, Oomph is designed explicitely to not interfere with how
users are used to work with Eclipse.
Oomph doesn't inhibit that.
So my answer doesn't really applies to Oomph, but more to Mike's
answer about the multiple IDEs.
[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]
and maintaining one IDE per project or language is more
something that project teams might like in order to make sure
their users get the right stuff, but it's not an end-user's
I don't understand how (or for what purpose) you divide our users
into "project team members" and "end-users". I imagine that our
users could be divided into some that share their code with others
and some that don't. Those that don't today might want to do so in
the future. In any case I think that how many IDEs a user installs
is her personal choice. Eclipse and Oomph support all possible
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
They typically document their setup somewhere, or keep it in their
memory for the future, and they're ok with that. I don't find it
realistic to expect SQL/JEE/JS developers to define their IDE in the
Oomph language, just like they don't do specific RCP apps or even
"master" features that define the required Eclipse tools for the
To get started on an existing project quickly, using the Oomph
configuration provided by the project (if existing) to configure
existing IDEs is great.
Oomph profiles are interesting, but since Oomph is targeting
Oomph is targeting all Eclipse users.
have the feeling that it's an overkill technology for the goal
of providing easier 1st experience with the "generic" Eclipse
What exactly is the overkill and what alternative would you
I'm starting to understand things better, the installer is basically
a Oomph configuration editor, and when clicking Finish on the
wizard, the Oomph configuration gets materialized. Is that it?
What I find overkill is the manipulation of a new language 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. The only missing thing is probably a format to
define installed IUs (.target files could maybe achieve that). 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.
IMHO, the issue Oomph has tried to resolve is a pure UI issue.
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.
But talking is cheap and it's easy to say "should" ;)
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.