Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] Eclipse IDE Ultimate (totally not: Re: what about doing less?)

Can something like this be implemented in the Marketplace? When the user creates a new project in, say C/C++ package (using whatever package) there can be a button "More project types" where the user can search for "Java Project" and install JDT. When I double-click JS file in my SDK install, instead of just popping up Xcode show a dialog - "Do you want to open a file in Xcode [or open a plain text editor (this is a separate suggestion)] or install one of these plugins - JSDT, VJet or Aptana?".

I wonder if Marketplace could crawl plugin.xmls of published plugins for new project wizards, editors and such.

On Oct 28, 2013, at 10:10 AM, Doug Schaefer <dschaefer@xxxxxxx> wrote:

> Actually, as I think of it more, maybe an installer is the better approach
> to producing an ultimate install, which is what the EPP packages are doing
> anyway. All we need is a manifest that lists the features to install and
> repos to install from and drive the p2 director from it. We could write an
> NSIS installer and Mac pkg file that distributes the core Eclipse piece
> and the manifest and invokes the director to complete the install. That
> would at least get us started down that road. I'll see what I can in that
> direction.
>
> On 2013-10-28 1:01 PM, "Konstantin Komissarchik"
> <konstantin.komissarchik@xxxxxxxxxx> wrote:
>
>> FYI... There was some discussion a while ago about making it easy to
>> combine
>> solutions into sets in Eclipse Marketplace. It would be a really nice
>> improvement, but nothing ever came of that.
>>
>> - Konstantin
>>
>>
>> -----Original Message-----
>> From: ide-dev-bounces@xxxxxxxxxxx [mailto:ide-dev-bounces@xxxxxxxxxxx] On
>> Behalf Of Miles Parker
>> Sent: Monday, October 28, 2013 9:55 AM
>> To: Discussions about the IDE
>> Subject: Re: [ide-dev] Eclipse IDE Ultimate (totally not: Re: what about
>> doing less?)
>>
>>
>> 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
>>
>> _______________________________________________
>> 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

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------


Back to the top