Re: [ide-dev] Eclipse IDE Ultimate (totally not: Re: what about doing le

[Doug Schaefer <dschaefer@xxxxxxx>]

Sure, but wasn't there a lot of work put into the Eclipse platform to make
sure it scaled? And if it doesn't, isn't that a problem we need to fix,
since sooner or later, there will be users who install all these things
into their environment.

Take my use case as a example, where I'm developing cloud based apps with
a mix of native mobile and browser-based clients. I'm using a whole mess
of languages and environments to build this single app. I may be crazy,
but I'd like to see this work well in a single IDE, and for the most part
it does, which is the great thing we've accomplished. There are only a few
rough areas.

On 2013-10-28 12:55 PM, "Miles Parker" <miles.parker@xxxxxxxxxxx> wrote:

>
>Yeah, I was one of the people arguing that the Eclipse ³Classic² package
>should be front and centre, and that I think is basically what the
>standard package is.
>
>Personally, I put a lot of thought into having the smallest possible
>footprint getting everything I need but nothing I don't. This means for
>example adding some of the wtp server pieces but not the whole WTP stack.
>Adding emf, xtext, xcore, xsd but not all of the graphical editing tools
>etc.. That stuff all adds up and by aligning my toolset with my needs I
>end up with a clean package. It doesn¹t matter how well-behaved all of
>the individual pieces are, when you add all of the language tools,
>runtime environment supports, modeling tools, etc.. you¹re going to have
>monster bloat. Still, more power to it ‹ that may be just what some users
>are looking for.
>
>So I guess I agree w/ Fabian¹s comment in the other thread that one of
>the real strengths of the platform is the modularity. Where I think we
>break down is in the granularity of that modularity. The EPPs are too
>coarse grained, features are too fine grained. Perhaps we need a level of
>granularity that improves cohesion while allowing preserving modularity
>and rewarding bundles of features that fit nicely on the features/bloat
>tradeoff landscape. These would be role based. So you might have a
>³Modeling and DSL² *feature set* that gave you xtext and xcore and all of
>the dependencies. An "open source developer² that had egit, gerrit,
>Mylyn++.. A ³streamlined web developer² that had WST, Tomcat, JS, HTML,
>but no EE...
>
>On Oct 28, 2013, at 9:32 AM, John Arthorne <John_Arthorne@xxxxxxxxxx>
>wrote:
>
>> So one interesting statistic that may be relevant, there was a complete
>>inversion of the download stats this year compared to last year. Last
>>year the JEE package was by a large margin the dominant download. This
>>year it was the recently rejigged "standard" package that was the large
>>majority of downloads. My interpretation (perhaps wrong) is that it
>>means people didn't actually want the much larger JEE package, and the
>>much smaller "standard" package had what they needed. Of course it could
>>be they were just confused by all the choices and picked the first one
>>on the list :)   
>> 
>> FWIW, I think people would prefer something smaller and higher
>>performance than an "ultimate" package with everything in it they might
>>possibly need. Compare our downloads for example with the tightly
>>focused IntelliJ packages...
>> 
>> John 
>> 
>> 
>> 
>> 
>> From:        Doug Schaefer <dschaefer@xxxxxxx>
>> To:        Discussions about the IDE <ide-dev@xxxxxxxxxxx>,
>> Date:        10/28/2013 05:02 PM
>> Subject:        [ide-dev] Eclipse IDE Ultimate (totally not: Re: what
>>about doing less?)
>> Sent by:        ide-dev-bounces@xxxxxxxxxxx
>> 
>> 
>> 
>> I'll throw my hat in the "while doing less would help performance, it
>> isn't what our users want" camp. At the end of the day they want a great
>> experience while working on their projects. The performance issue is
>> probably less important IMHO, than missing functionality.
>> 
>> To help contribute to our understanding, I'd like us to produce an EPP
>> that is the ultimate IDE with everything included that most Eclipse IDE
>> users would use. From there we can gain a better understanding of where
>>we
>> are and where we need to go to improve performance and interop issues.
>>And
>> that will likely kick off another discussion of what to put in it. :)
>> 
>> Thoughts?
>> Doug.
>> 
>> On 2013-10-27 4:10 PM, "Fabian Steeg" <fsteeg@xxxxxxxxx> wrote:
>> 
>> >I realize I'm not convincing anyone here, just contributing some
>>thoughts
>> >:-)
>> >
>> >This goal of a great OOTB universal IDE has always been there, and (I
>> >guess for multiple reasons) it isn't happening. So maybe it's time to
>>try
>> >a different approach and embrace what Eclipse is instead of clinging to
>> >an inadequate version of something we'd like it to be.
>> >
>> >Because the OOTB experience has two sides: if everything is included
>>and
>> >anything sucks, the whole thing sucks. That's, 'Eclipse sucks'. But if
>> >you have a stable platform plus plugins, it's 'Oh, this sucks since I
>> >added X, let me check my setup'. And maybe this can improve the common
>> >attitude towards Eclipse that I don't get: stuff that can be fixed, be
>>it
>> >by changing some setting, updating or removing some plugin, etc. is
>> >considered an inherent part of 'Eclipse', which therefore sucks.
>> >
>> >It has been discussed that the Platform's been reluctant to accept
>> >contributions to avoid bloat. I think this is very important, and has
>> >worked. But that doesn't seem to contribute to today's impression of
>> >Eclipse. And how would a user today know about the modular nature of
>> >Eclipse? We all do, because we work with this technology. When I
>>started
>> >as an Eclipse user 10 years ago, it was obvious to users, too. Maybe
>> >today it isn't.
>> >
>> >And maybe focussing less on providing the best OOTB experience, and
>>more
>> >on being a great platform and ecosystem could help with that. I'm
>>certain
>> >it would appeal to a lot of developers. And anyone who's happy today
>>can
>> >continue that way, but this different focus would center around what's
>> >unique about Eclipse, and what we're actually best at.
>> >
>> >Cheers,
>> >Fabian
>> >
>> >On 26.10.2013, at 10:56, Denys Digtiar <duemir@xxxxxxxxx> wrote:
>> >
>> >> I tend to agree with Konstantin. I am a regular user and I like when
>> >> my tools just work out of the box. TBH vim is an exception but maybe
>> >> that is the reason why I am not using it on a regular basis.
>> >> 
>> >> In terms of doing less, what about removing CVS integration from
>> >> default packages? How many people is still using it? I have never
>>used
>> >> it myself and never heard about anybody using it on commercial
>> >> projects. I understand that I am not representative, but I can see
>> >> Foundation running a poll on the website to get more broad feedback.
>> >> 
>> >> 
>> >>> Date: Fri, 25 Oct 2013 18:13:49 -0700
>> >>> From: "Konstantin Komissarchik" <konstantin.komissarchik@xxxxxxxxxx>
>> >>> To: "'Discussions about the IDE'" <ide-dev@xxxxxxxxxxx>
>> >>> Subject: Re: [ide-dev] what about doing less?
>> >>> Message-ID: 
>><00ca01ced1e8$a12afd10$e380f730$@komissarchik@xxxxxxxxxx>
>> >>> Content-Type: text/plain;       charset="us-ascii"
>> >>> 
>> >>> My point is that will not work. The user reaction is not going to be
>> >>> positive. A common description of Eclipse is already "some assembly
>> >>> required" while other IDEs work out of the box. Turning "some
>> >>>assembly" into
>> >>> "a lot of assembly" isn't going to improve user perception of
>>Eclipse.
>> >>> 
>> >>> - Konstantin
>> >>> 
>> >>> 
>> >>> -----Original Message-----
>> >>> From: ide-dev-bounces@xxxxxxxxxxx
>>[mailto:ide-dev-bounces@xxxxxxxxxxx]
>> >>>On
>> >>> Behalf Of Fabian Steeg
>> >>> Sent: Friday, October 25, 2013 5:42 PM
>> >>> To: Discussions about the IDE
>> >>> Subject: Re: [ide-dev] what about doing less?
>> >>> 
>> >>> I also prefer a feature rich IDE, and I'm happy enough with some
>>parts
>> >>>of
>> >>> Eclipse to view the others as challenges on the way to the ultimate
>> >>>IDE. So
>> >>> personally, I totally agree. It just bugs me that people seem to
>>hate
>> >>> Eclipse for what it's trying to be, instead of loving it for what it
>> >>>is and
>> >>> looking forward to what it might become. The things that really
>>shine
>> >>>and
>> >>> attract users and contributors seem to get missed. The platform
>>nature,
>> >>> customizability, and plugin ecosystem are some of these things, so
>> >>>maybe
>> >>> it's better to actively get users into that, instead of trying to
>>hide
>> >>>it.
>> >>> 
>> >>> Cheers,
>> >>> Fabian
>> >>> 
>> >>> On 26.10.2013, at 00:38, Konstantin Komissarchik
>> >>> <konstantin.komissarchik@xxxxxxxxxx> wrote:
>> >>> 
>> >>>>> So as another crazy idea, we could make the Platform (plus
>> >>>>> Marketplace
>> >>>> client) the
>> >>>>> default download, and focus on making it easy to build the IDE
>>that's
>> >>>> right for you
>> >>>>> from there (one part of that could be the changes to the
>>Marketplace
>> >>>> mentioned by
>> >>>>> Marcel in the other thread).
>> >>>> 
>> >>>> This sort of approach is something that a few power users would
>> >>>> appreciate, but a typical user is just not interested in finely
>>tuning
>> >>>> their IDE composition. I have seen too many frustrated questions
>>from
>> >>>> users regarding why their Eclipse doesn't understand XML files (for
>> >>>> instance), when Netbeans has no issue with them. No amount of
>> >>>> improvements to Eclipse Marketplace is going to make users feel
>>good
>> >>>> about having to manually pick the technologies that they want to
>>use
>> >>>>and
>> >>> then hope that they install without issues.
>> >>>> 
>> >>>> Rather than trying to ignore performance issues by including less,
>>a
>> >>>> good item for the IDE working group to tackle is interop between
>> >>>> projects when many projects are installed concurrently. There are
>> >>>> performance issues that are not evident when only a few plugins are
>> >>>> installed. There are UI pollution issues. Like, why do we need a
>>dozen
>> >>>> views to show external resources, like app servers, databases,
>>source
>> >>>> repos, task repos, etc. when other IDEs can get away with a single
>> >>>>view.
>> >>>> 
>> >>>> - Konstantin
>> >>>> 
>> >>>> 
>> >>>> -----Original Message-----
>> >>>> From: ide-dev-bounces@xxxxxxxxxxx
>>[mailto:ide-dev-bounces@xxxxxxxxxxx]
>> >>>> On Behalf Of Fabian Steeg
>> >>>> Sent: Friday, October 25, 2013 3:23 PM
>> >>>> To: Discussions about the IDE
>> >>>> Subject: Re: [ide-dev] what about doing less?
>> >>>> 
>> >>>> Hi,
>> >>>> 
>> >>>> I really like the general idea of doing less. I think a lot of
>>grief
>> >>>> around Eclipse today is rooted in one of its actual strengths: a
>> >>>> large, open ecosystem.
>> >>>> 
>> >>>> Some like using advanced tools, and gladly work around their bugs
>>and
>> >>>> limitations, but others prefer to stick to a rock solid text editor
>> >>>> and the terminal instead of using a feature rich editor that hangs
>> >>>> while you're typing. So why not give people that option?
>> >>>> 
>> >>>> On my current machine, the latest stable Platform build (4.4M2)
>>starts
>> >>>> up in
>> >>>> 5 seconds something. That's not quite the 2 seconds mentioned by
>> >>>> Martin yet, but it's pretty close, and it's a start. As an easily
>> >>>> achievable goal, we could avoid adding more to that than really
>> >>>> required by a given user. And this is not just about startup time,
>>but
>> >>>> overall user experience, like tools running background tasks etc.
>> >>>> 
>> >>>> So as another crazy idea, we could make the Platform (plus
>>Marketplace
>> >>>> client) the default download, and focus on making it easy to build
>>the
>> >>>> IDE that's right for you from there (one part of that could be the
>> >>>> changes to the Marketplace mentioned by Marcel in the other
>>thread).
>> >>>> 
>> >>>> The open platform and focussed tools that made Eclipse great 10
>>years
>> >>>> ago are still here, but maybe seeing them has become more difficult
>> >>>> over the years, and is almost impossible for new and casual users
>> >>>>today.
>> >>>> 
>> >>>> Cheers,
>> >>>> Fabian
>> >>>> 
>> >>>> On 24.10.2013, at 08:57, Max Rydahl Andersen <manderse@xxxxxxxxxx>
>> >>>>wrote:
>> >>>> 
>> >>>>> On Wed, Oct 23, 2013 at 11:20:00AM +0200, Mickael Istria wrote:
>> >>>>>> On 10/23/2013 09:38 AM, Max Rydahl Andersen wrote:
>> >>>>>>> Dart editor "solves" it by removing anything but Dart required
>> >>>> dependencies.
>> >>>>>> FWIW, It's already what Tycho does with tycho-surefire-plugin by
>> >>> default:
>> >>>> it generates the minimal application for a test to run. So we don't
>> >>>> need anything new to have something similar working.
>> >>>>> 
>> >>>>> Not following why that is relevant ?
>> >>>>> Tycho's minimal application is rarely actually usable by users
>> >>>>> because it doesn't take into account add-ons that aren't related
>>to
>> >>>>> your specific
>> >>>> tests.
>> >>>>> 
>> >>>>>>> I think for this specific issue (performance) putting together
>> >>>> plan/resources to revive or reimplement focus on performance would
>> >>>> help alot.
>> >>>>>> Performance tests by themselves are generally a bit tricky to
>> >>>>>> analyze,
>> >>>> but coupling them with a profiler (yourkit-maven-plugin) could make
>> >>>> them much more relevant.
>> >>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=420149
>> >>>>> 
>> >>>>> Eclipse already have or at least had plenty of performance tests
>> >>>>> which
>> >>>> junit output usecase specific performance numbers instead of more
>> >>>> generic profiler output.
>> >>>>> 
>> >>>>> There were tests for "opening workspace", "load of eclipse",
>>import
>> >>>>> of project etc. which were then tracked to not have to big of a %
>> >>>>> difference
>> >>>> over time.
>> >>>>> 
>> >>>>> Not saying having easy access to profiler data but doing it
>> >>>>> generically will probably not solve end-user problem faster IMO.
>> >>>>> 
>> >>>>> /max
>> >>>>> 
>> >>>>>> --
>> >>>>>> Mickael Istria
>> >>>>>> Eclipse developer at JBoss, by Red Hat
>><http://www.jboss.org/tools>
>> >>>>>> My blog <http://mickaelistria.wordpress.com> - My Tweets
>> >>>>>> <http://twitter.com/mickaelistria>
>> >>>>> 
>> >>>>>> _______________________________________________
>> >>>>>> ide-dev mailing list
>> >>>>>> ide-dev@xxxxxxxxxxx
>> >>>>>> https://dev.eclipse.org/mailman/listinfo/ide-dev
>> >>>>> 
>> >>>>> _______________________________________________
>> >>>>> ide-dev mailing list
>> >>>>> ide-dev@xxxxxxxxxxx
>> >>>>> https://dev.eclipse.org/mailman/listinfo/ide-dev
>> >>>> 
>> >>>> _______________________________________________
>> >>>> ide-dev mailing list
>> >>>> ide-dev@xxxxxxxxxxx
>> >>>> https://dev.eclipse.org/mailman/listinfo/ide-dev
>> >>>> 
>> >>>> _______________________________________________
>> >>>> ide-dev mailing list
>> >>>> ide-dev@xxxxxxxxxxx
>> >>>> https://dev.eclipse.org/mailman/listinfo/ide-dev
>> >>> 
>> >>> _______________________________________________
>> >>> ide-dev mailing list
>> >>> ide-dev@xxxxxxxxxxx
>> >>> https://dev.eclipse.org/mailman/listinfo/ide-dev
>> >> _______________________________________________
>> >> ide-dev mailing list
>> >> ide-dev@xxxxxxxxxxx
>> >> https://dev.eclipse.org/mailman/listinfo/ide-dev
>> >
>> >_______________________________________________
>> >ide-dev mailing list
>> >ide-dev@xxxxxxxxxxx
>> >https://dev.eclipse.org/mailman/listinfo/ide-dev
>> 
>> _______________________________________________
>> ide-dev mailing list
>> ide-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/ide-dev
>> 
>> 
>> _______________________________________________
>> ide-dev mailing list
>> ide-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/ide-dev
>
>_______________________________________________
>ide-dev mailing list
>ide-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/ide-dev