Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] Presentation about IJ vs Eclipse IDE

Wikimedia recently decided to switch from Gerrit to GitLab:

Sqlalchemy uses Gerrit, but also accepts pull requests from GitHub, and keeps the two in-sync:

OSGi and p2 are fairly complex technologies, and if you invest the time to learn them, they don't pay dividends in domains outside of the Eclipse RCP universe.

I *love* Eclipse and I think it has some of the best guts around, but because it was early into public open source, and has its own ways for everything.  It was far ahead of the curve on things like scheduled releases, but in the broader ecosystem, p2 lost to maven, and OSGi lost to just keeping dependencies up-to-date / being stuck if the transitives are incompatible.

I maintain a Gradle plugin for downloading eclipse artifacts without p2/OSGi, and it gets ~400 downloads a day: I think the biggest project to adopt it so far is WALA (  I apologize for being a broken record, but I think modern forums/discussion lists ala Discourse, and a newcomer-friendly bugtracker / repo are table stakes.

Ned Twigg
Lead Software Architect, DiffPlug LLC
540-336-8043 (cell)
888-513-6870 (fax)
340 S Lemon Ave #343
3, Walnut, CA 91789

On Thu, Oct 29, 2020 at 11:19 AM Torkild U. Resheim <torkildr@xxxxxxxxx> wrote:
Thanks Mickael,

> 29. okt. 2020 kl. 18:41 skrev Mickael Istria <mistria@xxxxxxxxxx>:
> Hi,
> On Thu, Oct 29, 2020 at 6:20 PM Torkild U. Resheim <torkildr@xxxxxxxxx> wrote:
> Maybe it would be helpful setting up a formal gap-analysis (not sure if that's the correct term), comparing Eclipse IDE with its competition? It could help in pinpointing where to focus effort.
> To be honest, I don't think anything formal would help.
> Here with this presentation or other articles pointed in the past, we have a formal enough resources with a clear enough gap-analysis to act. Our issue isn't in identifying the delta, but more on actively reducing. And it's as usual a resource issue that anything formal fails to address IMO.

Is this based on what you and other Eclipse IDE developers know from experience or what is written down? By formal I simply mean that it is easily accessible in a formalised structure (for example a table in the Wiki), summarising the issue and what should be done, with links to corresponding Bugzilla reports, complaints, videos displaying the competition being better etc. I think such a document could help focus efforts and also encourage contributors. Actually, I think a curated public Bugzilla search would be a good start for the occasional contributor.

> Eclipse is the Maven integration, and almost equally often "front end" stuff.
> That's what people like to complain about, but not really where the gap is these days. I think the gap has already been much reduced (think about newer Java features, performance, save actions, Maven support...), and what's left is not new and is almost all about the editor.

I agree with most of what you said here, Eclipse is an awesome IDE. Performance is great, support of new Java features is great, etc. But in my experience the Maven support is still a bit lacking. Also there is something weird going on with the generic text editor, sometimes it spends several seconds in a blocking UI thread. I have not written enough code lately to put my finger on it, but it may be related to a node.js installation. I digress.

> I realise that this is a big undertaking, but with some collaborative effort I think it can be done.
> We already have all the means and all the processes already there to address all that. I'm afraid more processes and more formal stuff will just distract people from doing what actually matters here: write the necessary code.
> However, if you can convince me that having something more formal will increase the amount of development/contribution time received by Eclipse IDE, I'm all for it; but at the moment, I have the impression after the few last releases that the less formal we are, and the more  time we actually spend developing, the more contributors we attract, and the more value we ship.

My apologies, I did not suggest that Eclipse IDE developers should spend a large chunk of their time working on formal documents in stead of coding. Contribution is not always about writing code – it could also be documenting why IntelliJ is better at feature X and what should be done for Eclipse IDE to catch up or be better. Would that be helpful?

Best regards,

> _______________________________________________
> ide-dev mailing list
> ide-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit

ide-dev mailing list
To unsubscribe from this list, visit

Back to the top