Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] Some Infos About Oomph

Hey Eike,
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:
Am 29.01.2015 um 08:16 schrieb Mickael Istria:
On 01/28/2015 08:39 PM, Doug Schaefer wrote:

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 you’re going.
I agree with Doug.
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.
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.

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.
Ok, that's cool.
So my answer doesn't really applies to Oomph, but more to Mike's answer about the multiple IDEs.

Defining 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 dream.
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 options.
[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. 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 project.

Oomph profiles are interesting, but since Oomph is targeting project teams
Oomph is targeting all Eclipse users.
I have the feeling that it's an overkill technology for the goal of providing easier 1st experience with the "generic" Eclipse IDE.
What exactly is the overkill and what alternative would you suggest?
To get started on an existing project quickly, using the Oomph configuration provided by the project (if existing) to configure existing IDEs is great.

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.
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets

Back to the top