|Re: [ide-dev] Some Infos About Oomph|
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.
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]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.
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.
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 project teamsOomph is targeting all Eclipse users.
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.
Back to the top