Biggest Bang for IDEA

Just a quick note. As a long time IDEA user and some one who is really sick of hearing about eclipse and seeing how much mind-share it is getting while IDEA remains so much better, I thought I'd pass along what I think will make IDEA even with eclipse in perhaps the one area where it is not. And that's pluggins. If IDEA could offer a compability layer that allowed it to use eclipse pluggins seamlessly I think it would go a long to getting back some mindshare and market.

24 comments
Comment actions Permalink

+infinity

This idea has to be taken seriously. I don't know how much work it
would be, but if it worked it would be killer!

Spencer Marks wrote:

Just a quick note. As a long time IDEA user and some one who is really sick of hearing about eclipse and seeing how much mind-share it is getting while IDEA remains so much better, I thought I'd pass along what I think will make IDEA even with eclipse in perhaps the one area where it is not. And that's pluggins. If IDEA could offer a compability layer that allowed it to use eclipse pluggins seamlessly I think it would go a long to getting back some mindshare and market.

0
Comment actions Permalink

+infinity

This idea has to be taken seriously. I don't know how much work it
would be, but if it worked it would be killer!

Spencer Marks wrote:

Just a quick note. As a long time IDEA user and some one who is really sick of hearing about eclipse and seeing how much mind-share it is getting while IDEA remains so much better, I thought I'd pass along what I think will make IDEA even with eclipse in perhaps the one area where it is not. And that's pluggins. If IDEA could offer a compability layer that allowed it to use eclipse pluggins seamlessly I think it would go a long to getting back some mindshare and market.

0
Comment actions Permalink

I doubt that's possible. It's not only a "thin" compatibility layer -- IDEA and Eclipse are fundamentally different at the core, and any compatibility layer would have to be really huge. There's too many (differently) exposed functionality.

0
Comment actions Permalink

It could be even worse than that if there's a dependency on SWT.

As per the usefulness of such a theoretical thing, +++++++++

Marcus Brito wrote:

I doubt that's possible. It's not only a "thin" compatibility layer -- IDEA and Eclipse are fundamentally different at the core, and any compatibility layer would have to be really huge. There's too many (differently) exposed functionality.

0
Comment actions Permalink

It could be even worse than that if there's a dependency on SWT.

As per the usefulness of such a theoretical thing, +++++++++

Marcus Brito wrote:

I doubt that's possible. It's not only a "thin" compatibility layer -- IDEA and Eclipse are fundamentally different at the core, and any compatibility layer would have to be really huge. There's too many (differently) exposed functionality.

0
Comment actions Permalink

I wander if the opposite may not be more possible, which would
potentially make writing plug-ins for both platforms easier.

0
Comment actions Permalink

I wander if the opposite may not be more possible, which would
potentially make writing plug-ins for both platforms easier.

0
Comment actions Permalink

Hello Norris,

Unfortunately it's about as much work as rewriting a big portion of Eclipse
from scratch. We'd rather spend time on writing IDEA, not rewriting Eclipse.

NS> +infinity
NS>
NS> This idea has to be taken seriously. I don't know how much work it
NS> would be, but if it worked it would be killer!
NS>
NS> Spencer Marks wrote:
NS>
>> Just a quick note. As a long time IDEA user and some one who is
>> really sick of hearing about eclipse and seeing how much mind-share
>> it is getting while IDEA remains so much better, I thought I'd pass
>> along what I think will make IDEA even with eclipse in perhaps the
>> one area where it is not. And that's pluggins. If IDEA could offer a
>> compability layer that allowed it to use eclipse pluggins seamlessly
>> I think it would go a long to getting back some mindshare and market.
>>
--
Dmitry Jemerov
Software Developer
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

Hello Norris,

Unfortunately it's about as much work as rewriting a big portion of Eclipse
from scratch. We'd rather spend time on writing IDEA, not rewriting Eclipse.

NS> +infinity
NS>
NS> This idea has to be taken seriously. I don't know how much work it
NS> would be, but if it worked it would be killer!
NS>
NS> Spencer Marks wrote:
NS>
>> Just a quick note. As a long time IDEA user and some one who is
>> really sick of hearing about eclipse and seeing how much mind-share
>> it is getting while IDEA remains so much better, I thought I'd pass
>> along what I think will make IDEA even with eclipse in perhaps the
>> one area where it is not. And that's pluggins. If IDEA could offer a
>> compability layer that allowed it to use eclipse pluggins seamlessly
>> I think it would go a long to getting back some mindshare and market.
>>
--
Dmitry Jemerov
Software Developer
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

>Unfortunately it's about as much work as rewriting a big portion of Eclipse
>from scratch. We'd rather spend time on writing IDEA, not rewriting Eclipse.

Hmm, I had not considered the SWT part of the problem. That could definitely complicate things. I haven't looked at the APIs, but I guess they contain platform specific UI calls - that's too bad. However, I am still a bit surprised that SWT crud could not be mapped to SWING equivalents at least enough to be compatible. Perhaps there's even more going on. Probably I am just being idealistic.

However, I found this part of the comment:

"We'd rather spend time on writing IDEA, not rewriting Eclipse."

a bit glib. I hope this means that you'd rather spend time making IDEA as competitive (i.e. as good) as possible and you don't think the time needed to do Eclipse plugin support is worth it rather than how it sounds which is you'd rather just work on new bits.

If it is true that adding such a compatibility layer is just not worth the effort involved (and it very well might be) I'd like to see what you think is more compelling.

For example, duplicating continuous integration control features seems like the wrong direction to me. Not only is it a lot of work, but it will end up making IDEA more of a close system rather than a more open one. I think this type of lock in the wrong direction unless you completely own the market already. In addition, there are already pretty CI products out there. Why not work more closely with them?

If that actually boiled down to rewriting parts of IDEA to mimic Eclipse functionality in order to make IDEA better, I hope that you'd consider it. Might not be a thrill ride, but IDEA is a commercial product and developing commercial software doesn't always mean getting to do the new and fun stuff.

Sadly, in order IDEA to survive long term I think it needs to learn to interact as seamlessly as possible in a Eclipse dominated environment. In the five years I have been using IDEA I have not worked a contract where everyone on the team, or even a majority, used IDEA. Eclipse, or WSAD have been the norm. In order for me to be able to use IDEA, I've had to play in that world. In some cases, I've even gotten other developers to adopt IDEA, but compatibility with the dominate tool set is always the concern, not (again sadly) how good a specific tool is.

This has just been my experience. I am sure other people's experience has varied.

0
Comment actions Permalink

For example, duplicating continuous integration control features seems like the wrong direction to me. Not only is it a lot of work, but it will end up making IDEA more of a close system rather than a more open one. I think this type of lock in the wrong direction unless you completely own the market already. In addition, there are already pretty CI products out there.

The build server stuff is more than just a rewrite. Remote run and deferred commit truly are new things under the sun, and have the potential to cut hours off of developer workflows. It's worth checking them out.

Also, I'm pretty sure that TeamCity integration with Eclipse and VS.Net are in plan.

--Dave Griffith

0
Comment actions Permalink

Also, I'm pretty sure that TeamCity integration with Eclipse and VS.Net are in plan.

Yes, it seems "official" for TeamCity 1.5 . Even the integration with Netbeans:
http://www.jetbrains.com/teamcity/documentation/featureMatrix.html
(see "Supported IDEs").

Ahmed.

0
Comment actions Permalink

Sadly, in order IDEA to survive long term I think it needs to learn to
interact as seamlessly as possible in a Eclipse dominated environment.
In the five years I have been using IDEA I have not worked a contract
where everyone on the team, or even a majority, used IDEA. Eclipse, or
WSAD have been the norm. In order for me to be able to use IDEA, I've
had to play in that world. In some cases, I've even gotten other
developers to adopt IDEA, but compatibility with the dominate tool set
is always the concern, not (again sadly) how good a specific tool is.

This has just been my experience. I am sure other people's experience
has varied.


I'm afraid that I can second this. "But Eclipse is free" is a mindless refrain
from managers and ignorant developers who don't realize that they get what
they pay for; I own a personal license simply to avoid the argument. Worse,
I've had people that I would generally consider good developers try to convince
me seriously that Plugins for Eclipse are a good thing, even when the core
product from IDEA has the same or better functionality, which is usually
the case for these instances. (at which point, I wonder if I've mis-estimated
their abilities)

I'm sure that this has been suggested before, but IDEA ships with a good
number of plugins. Since the "plugin mentality" around Eclipse is irrational
to begin with, it might be possible to fight some of it by just listing the
plugins that IDEA ships with in the installer (including a short advertisement
for the plugin repository during install). Maybe even include simple "pre-configured"
install profiles (e.g. IDEA for Web Development; IDEA for Swing Development
-- of course, the default should be everything). Granted, these profiles
are completely unnecessary, but adding them would defeat the (erroneous)
belief that the ability to tweak like this is somehow a "feature" of Eclipse
(instead of a pain in the rear).

Most people and teams really don't even use the plugins for which they say
Eclipse is great, or they only use a handful for missing functionality (e.g.
Subclipse, MyEclipse, Web Tools, or Hibernate Tools -- ok, that last one
has some nice features like the HQL Translator). If they just saw plugins
with the same name during the IDEA install process, it would be much easier
to convince them that they aren't losing anything by switching to IDEA.
They won't realize how much they gain until they actually try it.

--Mike


0
Comment actions Permalink

Hello Spencer,

>> Unfortunately it's about as much work as rewriting a big portion of
>> Eclipse from scratch. We'd rather spend time on writing IDEA, not
>> rewriting Eclipse.
>>
SM> Hmm, I had not considered the SWT part of the problem. That could
SM> definitely complicate things. I haven't looked at the APIs, but I
SM> guess they contain platform specific UI calls - that's too bad.
SM> However, I am still a bit surprised that SWT crud could not be
SM> mapped to SWING equivalents at least enough to be compatible.
SM> Perhaps there's even more going on. Probably I am just being
SM> idealistic.

There are definitely some possibilities of either mapping SWT to Swing or
embedding SWT components into a Swing application, but it's a complicated
task in any case. However, mapping the complete Eclipse environment to IDEA
is far more complicated still.

SM> However, I found this part of the comment:
SM>
SM> "We'd rather spend time on writing IDEA, not rewriting Eclipse."
SM>
SM> a bit glib. I hope this means that you'd rather spend time making
SM> IDEA as competitive (i.e. as good) as possible and you don't think
SM> the time needed to do Eclipse plugin support is worth it rather than
SM> how it sounds which is you'd rather just work on new bits.

The reason why people still buy IntelliJ IDEA when they can get NetBeans
or Eclipse for free is that they consider it a more productive environment.
In order to keep the lead in productivity, we need to continue innovating
all the time, because the competitors try hard to catch up. Stopping or significantly
slowing down all innovation for half a year or more in order to copy the
Eclipse API would be a huge gift to the Eclipse and NetBeans products, and
a major detriment to our company.

SM> For example, duplicating continuous integration control features
SM> seems like the wrong direction to me. Not only is it a lot of work,
SM> but it will end up making IDEA more of a close system rather than a
SM> more open one. I think this type of lock in the wrong direction
SM> unless you completely own the market already. In addition, there are
SM> already pretty CI products out there. Why not work more closely with
SM> them?

Sorry, I fail to see how a continuous integration system which is compatible
with multiple development environments (IDEA and Visual Studio right now,
Eclipse and NetBeans in a future version) makes IDEA "more of a close system".
Also note that all APIs required to integrate with TeamCity are open and
available for everyone to use.

Also, we believe that TeamCity is a superiour continuous integration solution
compared to others on the market, and, plain and simple, we want to earn
money selling TeamCity licenses. I don't understand how we could accomplish
this goal by working more closely with vendors of competing products.

(Another note, by the way, is that our plans for TeamCity go far beyond continuous
integration.)

SM> If that actually boiled down to rewriting parts of IDEA to mimic
SM> Eclipse functionality in order to make IDEA better, I hope that
SM> you'd consider it. Might not be a thrill ride, but IDEA is a
SM> commercial product and developing commercial software doesn't always
SM> mean getting to do the new and fun stuff.

I do not believe that mimicing Eclipse functionality is always the best way
to implement features.

SM> Sadly, in order IDEA to survive long term I think it needs to learn
SM> to interact as seamlessly as possible in a Eclipse dominated
SM> environment. In the five years I have been using IDEA I have not
SM> worked a contract where everyone on the team, or even a majority,
SM> used IDEA. Eclipse, or WSAD have been the norm. In order for me to
SM> be able to use IDEA, I've had to play in that world. In some cases,
SM> I've even gotten other developers to adopt IDEA, but compatibility
SM> with the dominate tool set is always the concern, not (again sadly)
SM> how good a specific tool is.

This is a real problem indeed, and we are well aware of this situation. However,
I don't think that supporting Eclipse plugins is the best, or the only, way
out of it. I think that it's much better to invest into the development of
IDEA plugins (both internally and by third parties) which are as good, or
better, than the Eclipse plugins supporting the respective technologies.

--
Dmitry Jemerov
Software Developer
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

>The build server stuff is more than just a rewrite.

I didn't mean to imply that this stuff was a rewrite or not useful or even uncool. I think it could be very useful. Interoperating with existing systems is defnitely useful (and is direction other than the closed model I mentioned which is also a goodthing). A remaining concern is which of the at least several CI solutions out there is IDEA going to cater to? For example, I'd like to see Anthill 3 integration of some sort.

I will check out TeamCity though. Thanks for the suggestion.

0
Comment actions Permalink

Hello Spencer,

>> The build server stuff is more than just a rewrite.
>>
SM> I didn't mean to imply that this stuff was a rewrite or not useful
SM> or even uncool. I think it could be very useful. Interoperating with
SM> existing systems is defnitely useful (and is direction other than
SM> the closed model I mentioned which is also a goodthing). A remaining
SM> concern is which of the at least several CI solutions out there is
SM> IDEA going to cater to? For example, I'd like to see Anthill 3
SM> integration of some sort.

Anthill is a direct competitor to TeamCity, and we don't plan to develop
any features for integrating with Anthill.

--
Dmitry Jemerov
Software Developer
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

I'm wondering exactly what eclipse plugins you got to have? I personally
only have a few plugins loaded. (HungryBackspace,SyncEdit,SmartIntroduce,RegexPlugin,
IdeaJad,YourKit)

Plugins are great, but what are the reasons for someone writing a plugin?

1) One reason is to correct a glaring deficiency or source of pain in the
product or to provide some feature that someone saw in another IDE or
Editor.

What I would argue is that because Jetbrains has been the innovator and has and
continues to be very responsive to customers, there isn't as much glaring
holes in IntelliJ. They did a great thing by folding in the Inspection Gadgets Plugin
into the core product. I feel like my IDE is more stable, faster, and useable with the
fewest plugins as possible, esp. when you are using EAP releases.

It's true that IntelliJ has been slowing losing the technology lead vs. Eclipse's
barbarian hordes, at least if you keep score by checkboxes in marketing punch
sheets. There's even some things that show up in Eclipse before IntelliJ now (
e.g. searchable settings), and lots of areas where eclipse has something
IntelliJ doesn't (e.g. ant debugger).


2) Another reason is to support some new technology or a niche application
which the company won't support.

I would say they were somewhat late in creating a strong offering for enterprise
development. I think this might be where they are feeling the competition more.
I do java web enterprise development, and I'm still not very happy with JSP support.

I am curious how IDEA 5.1 stacks up against the latest MyEcipse ($29.95/annually)
http://www.myeclipseide.com/ContentExpress-display-ceid-15.html
because they have a good enterprise package. That might be the real competitor
to IDEA rather than plain vanilla free eclipse with a hodge podge of plugins
loaded.

There are definately a ton of eclipse plugins for new languages, technologies, etc.
and niche applications, and also alot of commercial software trying to sell the latest
UML code analyzer whizbang gadget. The danger for IDEA is that some of these
new technologies will take off or become important, and Eclipse get ahead of
the curve. esp. if Jetbrains stops putting the pedal to the metal... but heh,
now that they've got TeamCity, Jetbrainer's productiviy should go up 100%!

Can you name some other key technologies which have reached critical use, i.e. wide
use in a commercial development environment, that Eclipse has Plugin for and IDEA has
nothing?

3) Sometimes, someone comes along and creates something new and wonderful, e.g.
Inspection Gadgets, but's I think that's very rare.

0
Comment actions Permalink

One other thing Eclipse has really pushed is the Eclipse Rich Client Platform (RCP). (See http://wiki.eclipse.org/index.php/Rich_Client_Platform)

It is interesting when you visit Eclipse Plugin Central (http://www.eclipseplugincentral.com/index.html), they list not only plugins for Eclipse, but also entire applications written on RCP like Integrated Ontology Development Toolkit and Eclipse Trader.

For IDEA, I just hear about the Plugin Development Kit. It's probably too late to matter much, but you coud have a IntelliJ Platform Kit which gives you a skeleton application and lets you use some of the custom UI compoents like the docking framework and panels, look and feel, etc. so that you can have something similar to Ecipse RCP.
Whatever custom UI componts you include could also be supported by your bundled UI designer.

0
Comment actions Permalink

Hello Alex,

A> One other thing Eclipse has really pushed is the Eclipse Rich Client
A> Platform (RCP). (See
A> http://wiki.eclipse.org/index.php/Rich_Client_Platform)
A>
A> It is interesting when you visit Eclipse Plugin Central
A> (http://www.eclipseplugincentral.com/index.html), they list not only
A> plugins for Eclipse, but also entire applications written on RCP like
A> Integrated Ontology Development Toolkit and Eclipse Trader.
A>
A> For IDEA, I just hear about the Plugin Development Kit. It's
A> probably too late to matter much, but you coud have a IntelliJ
A> Platform Kit which gives you a skeleton application and lets you use
A> some of the custom UI compoents like the docking framework and
A> panels, look and feel, etc. so that you can have something similar to
A> Ecipse RCP.
A>
A> Whatever custom UI componts you include could also be supported by
A> your bundled UI designer.

We do not have any plans to create a rich client platform out of IntelliJ
IDEA. There are a number of well-established and well-documented rich client
platforms (including Eclipse RCP and the NetBeans platform), and we aren't
going to compete with them.

--
Dmitry Jemerov
Software Developer
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

I'm wondering exactly what eclipse plugins you got to have?


Hibernate and Accurev plugins in come immediately to mind.

And got to have is too strong a phase.

Typically vendors provide Eclipse plugins but not IDEA plugins. In fact, I offered to write an Accurev plugin (for free) if they'd share the Eclipse plugins source but Accurev was not even interested in providing that level of support for IDEA. And, yes, I know there is an Accurev plugin for IDEA but it does not work well enough to be usable. (Same, the last time I checked, was true for Hibernate).

I was not suggesting that Eclipse is somehow better or more of innovator just because they have more vendors providing plugins for it. They just have more mind share. They have more mind share because end users don't directly pay for the cost of its' development. I'd like to see IDEA regain some of the mind-share is it losing to those "barbarian hordes" so I offered a suggestion. I was not trying to be critical. I was offering feedback because it was solicited. However, it seems like I hit a raw nerve based on the defensiveness of some of the replies it generated.

I'd also like plugins that didn't cause the Mac OS X version of IDEA simply not to start (with no diagnostic information) but that's another problem entirely. Right now, installing plugins on the Mac is a bit of a crap shoot.


Spencer

0
Comment actions Permalink

Hello Spencer,

>> I'm wondering exactly what eclipse plugins you got to have?
>>
SM> Hibernate and Accurev plugins in come immediately to mind.
SM>
SM> And got to have is too strong a phase.
SM>
SM> Typically vendors provide Eclipse plugins but not IDEA plugins. In
SM> fact, I offered to write an Accurev plugin (for free) if they'd
SM> share the Eclipse plugins source but Accurev was not even interested
SM> in providing that level of support for IDEA. And, yes, I know there
SM> is an Accurev plugin for IDEA but it does not work well enough to be
SM> usable. (Same, the last time I checked, was true for Hibernate).

By the Hibernate plugin that doesn't work well enough to be usable, do you
mean Hibero, which is offered as a companion product for IntelliJ IDEA? If
you had problems with a recent version of Hibero, we would be very interested
to know more about them.

SM> I'd also like plugins that didn't cause the Mac OS X version of IDEA
SM> simply not to start (with no diagnostic information) but that's
SM> another problem entirely. Right now, installing plugins on the Mac
SM> is a bit of a crap shoot.

Can you name some of the plugins that cause such problems?

--
Dmitry Jemerov
Software Developer
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

>>> I'm wondering exactly what eclipse plugins you got to have?
>>>

SM> Hibernate and Accurev plugins in come immediately to mind.
SM> SM> And got to have is too strong a phase.
SM> SM> Typically vendors provide Eclipse plugins but not IDEA plugins. In
SM> fact, I offered to write an Accurev plugin (for free) if they'd
SM> share the Eclipse plugins source but Accurev was not even interested
SM> in providing that level of support for IDEA. And, yes, I know there
SM> is an Accurev plugin for IDEA but it does not work well enough to be
SM> usable. (Same, the last time I checked, was true for Hibernate).

By the Hibernate plugin that doesn't work well enough to be usable, do
you mean Hibero, which is offered as a companion product for IntelliJ
IDEA?

I suppose most of the users under "Hibernate plug-in" understand this plug-in:
http://plugins.intellij.net/plugin/?id=124
(Hibernate Tools) as it is in top 10 of the most downloaded plug-ins.

That plug-in indeed has many problems, but they seem to be mostly due to the fact
that it's abandoned. Because it has no "untilDate" property, people keep trying it
with the latest IntelliJ version too.


Ahmed.

0
Comment actions Permalink

Hi,

I could not get early versions of Hibero to work but that was a long time ago. But the Hibernate guys where only releasing there plugin for eclipse for a while (this might have changed too, I have not been doing HIbernate work lately so it has not been on my radar).

I have not been playing with 6.0 plugins much but I can start when I have time and send you any errors I encounter.

In the past I would ping the authors (sometimes) if a plugin didn't work on the Mac, but that got tired after a bit. One large problem where plugin that required JDK 1.5 which wasn't the default VM on the Mac. When a plugin barfed because this type of error IDEA would just hang. (The copyright plugin comes to mind)

What would be really cool is a team-city type deferred commit of plugins. Something along the lines of plugins get posted to some known place, then get tested (some minimal startup validation) which they must pass before they are available for download. However, I beat you guys have already considered something like this.

0
Comment actions Permalink

Hello Spencer,

SM> What would be really cool is a team-city type deferred commit of
SM> plugins. Something along the lines of plugins get posted to some
SM> known place, then get tested (some minimal startup validation) which
SM> they must pass before they are available for download. However, I
SM> beat you guys have already considered something like this.

In fact this is not the real problem: even if a new plugin which gets uploaded
is totally broken (which I don't think happens much), the developer fixes
it really soon after that. Many more problems are caused by plugins which
break after some changes in the APIs they use (either OpenAPI or our internal
classes).

We spent some time on plugin compatibility testing after the 5.0 release,
but we didn't cover all plugins, and we definitely can't do that for every
EAP or beta release.

--
Dmitry Jemerov
Software Developer
http://www.jetbrains.com/
"Develop with Pleasure!"


0

Please sign in to leave a comment.