IntelliJ 6.0 (Demetra) Roadmap released

Discussions

News: IntelliJ 6.0 (Demetra) Roadmap released

  1. IntelliJ 6.0 (Demetra) Roadmap released (69 messages)

    JetBrains has released the roadmap guiding the development of their IDEIntelliJ 6.0, code named Demetra. While the team is hard at work they are still taking the time to engage the community by asking for people to comment on what features they'd like to see in Demetra. The current list of features is divided into three categories; General, Team Collaboration, and J2EE.

    Included in the list of upcoming features: improved support for testing including integration with JUnit 4.0 and incremental testing, improved refactorings, better source code control integration and an improved GUI designer. Development for JEE will eased by the addition of support for JSF, EJB 3.0 (including migration from 2.1) as well as support for WebSphere and WebLogic 9.0. Other features include support for HTML, CSS and JavaScript.

    The biggest change in the product comes in the area of Team Collaboration. Team collaboration will be supported with a new development server product. The server product is designed to run in a grid or clustered environment. It also includes a portal where developers can obtain the latest statistics and build information about their project. With the server, development teams will be able to:
    • Integration/Nightly/Release build automation
    • Build triggering: VCS, manual, schedule
    • Build from an .ipr, Ant or Maven configuration
    • Provide Instant notification
      • Navigate to failed tests in IDE
      • Review failure stacktrace in IDE
      • Re-run failed tests locally
    • History, statistics
    • Run build using local sources snapshot without committing to the VCS
    • Delayed commit: build and commit if successful
    • Update to the sources of the latest successful build
    • Schedule automated code inspection and code coverage tests.
    Team Collaboration features will include:
    • Instant messaging including code pointers, stacktraces exchange with group chat support
    • Contact list, registered project committers
    • P2P sources sync: diff with remote peer project state, ability to take changes from and to.
    • Collaborative code review: auto-follow-me navigation
    • Warn if start editing file modified by someone else in terms of VCS
    • Warn if simultaneous editing causes merge after commit
    In a conversation with Dmitry Jemerov, a developer for IntelliJ, he stated that they still haven't made any final decisions on how the server for collaboration will be packaged. He went on to add that these new features were motivated by their internal need to support their teams located in three different geographical locations. Dmitry stated that, in this instance, "We are eating our own dog food". JetBrains is also focusing on usability. Generally, setting up a complete development environment is a complex task and that effort needed to do so is often under-estimated. At the micro level, delayed commits have been included as "we (JetBrains) wanted to eliminate the problem of check-ins that break the build".

    With this roadmap, Jetbrains is betting on their ability to gauge what developers want from a Java IDE. Do you think they've succeeded? What features do you think IDEA needs in future revisions?

    Threaded Messages (69)

  2. Now, IDEA is (again) following JBuilder's leadership in the field of Java IDE inovatiion.

    In it's very early days, IDEA borrowed a lot from JBuilder, as well as introduced a tons of innovation.

    Then others (JBuilder, Eclipse) followed IDEA: refactoring, code navigation, code inspections...

    Now, it seems that IDEA is following JBuilder in team collaboration innovations. JBuilder 2006 already has most of the features planned for IDEA 6, although I have no idea how good are they implemented.

    P.S. One feature suggestion for IDEA 6.0:
    Look at JBuilder's (and Delphi) SyncEdit feature. It is simpler but more powerful and productive then IDEA's Live Templates.
    Just select a code fragment, press a key combination to enter SyncEdit mode, and viola, you have a Live Template from the selection. Whenever user changes a word when in SyncEdit mode, all occurancies of that word in the selection scope change automatically. Simple as that, but extremely usefull.
  3. I think live templates are almost unusable in JDK 5.0, because of generics and foreach statement. They were created to hack away deficiencies of Java, but now this deficiencies are fixed . BTW in IDEA when you change name of one variable in live template other occurences of it are changed too.

    When you want to create something from other code for example surround it with runnable for, if, try, in IDEA you can select it, press control+alt+T and you will get what you want.
  4. BTW in IDEA when you change name of one variable in live template other occurences of it are changed too.
    OK, that is what is expected. But please try JBuilder's and Delphi's SyncEdit. It is simple and powerful. Something that every text editor should have.
  5. Now, IDEA is (again) following JBuilder's leadership in the field of Java IDE inovatiion.

    Fortunately, IDEA has chosen not to follow JBuilder's leadership in one area: giving up and reimplementing yourself as a bunch of Eclipse plugins.

    I am really appreciative that IDEA continues to provide an alternative for those of us that just haven't been able to get comfortable with the Eclipse user experience.
  6. comments on roadmap[ Go to top ]

    Three days ago i commented on the IDEA6 roadmap on my blog. For all who are interessted, check this.

    Marc Logemann
    http://www.logemann.org
  7. Fortunately, IDEA has chosen not to follow JBuilder's leadership in one area: giving up and reimplementing yourself as a bunch of Eclipse plugins.I am really appreciative that IDEA continues to provide an alternative for those of us that just haven't been able to get comfortable with the Eclipse user experience.

    Me too. I am not pleased with Eclipse either.
    But I was just talking about team collaboration features and I felt the need to give credit to Borland about that as JBuilder was greately underestimated on TSS forums in his brightest days (2000-2002). Now Borland innovate and others follow again, that must be mentioned.
  8. Indeed, JBuilder 2006 already has some of the features that are planned for IntelliJ IDEA 6.0 in the collaboration area. This doesn't make these features any less useful for our customers. And in many areas of the roadmap, our planned features are unique and not provided by any other product.

    As for SyncEdit mode - we'll consider providing this feature in Demetra.
  9. Plugin and Live template[ Go to top ]

    Roadmap sounds Good, But what all I expect from IntelliJ is/are.
    -There are no proper/very little documentation for developing plugins in Intellij.
    Manier times I have tried wrinting my own plugin but failed due to inadequate support/information about plugins.
    I would suggest to add some sample plugin project with the "out of the Box" release of IntelliJ. I really hate Eclipse but the plugin support they provide is just amazing. May be we have take a similar approach in that front.


    Also Not much of documentation/online helps are available for preparing live templates in intelliJ. Some times I feel like having one reusable live template but I may not succed because I dont know the "how abouts" of live templates.

    Interms of "code-refactoring" & coverage related features, nobody else can even come closer to Intell-J. IntelliJ are the real king in those areas.
    I'm not sure if all the refactoring fundas explained in "Martin Fowler" is implemented in IntelliJ, But it would be great if done.

    Over all Great going IntelliJ team - hats off.
  10. Plugin and Live template[ Go to top ]

    Also it would be great if there is a testing environement where in we can test our Plugins, without restarting IntelliJ
  11. Oh please please make it support WebSphere, so people like me could finally convince management to flush WSAD (and all that latest dung from IBM as well) down the toilet.
  12. Oh please please make it support WebSphere, so people like me could finally convince management to flush WSAD...

    It's funny you say that. I just got the blessing to start an IntelliJ evaluation in our all WebSphere/RAD shop. I used IntelliJ for two years before coming here last April--what a contrast. We constantly fight RAD configuration/hang issues. IntelliJ is soooo transparent and easy to use compared to RAD.

    I don't think we can stand to wait for IntelliJ 6.0. If we have to we will code some tricks in ANT to support project interoperability with RAD. WebSphere will be here for some time, so support in IntelliJ 6.0 for WebSphere would be very nice.


    Steve Mitchell
    ByteworksInc.com
  13. Oh please please make it support WebSphere, so people like me could finally convince management to flush WSAD (and all that latest dung from IBM as well) down the toilet.

    WebSphere support is listed in our roadmap as a planned feature.
  14. Oh please please make it support WebSphere, so people like me could finally convince management to flush WSAD (and all that latest dung from IBM as well) down the toilet.
    WebSphere support is listed in our roadmap as a planned feature.

    There is definitely an huge opportunity there for IDEA to support WebSphere 6.0, and RAD 6.0 is crap. However, it is a little too late to compete with WSAD 5.0, since most WebSphere 4.x/5.x shops have already adopted WSAD5.0 and it is very unlikely they will switch to a new IDE for application support.
  15. Database Support[ Go to top ]

    It would be good to see some databaase support in IDEA. I have put together a simple syntax highlighting configuration for sql files as there isnt one available with the software.

    It would be great to have a simple database browser that would validate and run SQL against a JDBC datasource. Perhaps a code completion engine for SQL that would use JDBC to query the datasource structure and offer to complete column and table names. There may be some SQL refactoring options too.

    Also, there are a few silly little bugs that could use cleaning up. Something that springs to mind is the iteration shortcuts that generate a pre-5.0 for loop and then suggest that it would be better to use the foreach style!

    On the whole an excellent product that I feel justified in paying for despite the free alternatives!
  16. Database Support[ Go to top ]

    Thanks for your support!

    As for SQL, there is already a plugin which allows you to run SQL queries from IDEA. Another plugin that will be released in a few weeks will provide support for SQL CodeInsight and refactoring.
  17. Database Support[ Go to top ]

    Thanks for your support!As for SQL, there is already a plugin which allows you to run SQL queries from IDEA. Another plugin that will be released in a few weeks will provide support for SQL CodeInsight and refactoring.

    That will be interesting. Having just migrated from SQL Server to Oracle and having become dismayed at available tools for Oracle vs. MS Query Analyzer, I was looking for something that had these properties:
      easy to work with a file full of random sql snippets
      non-modal while running queries
      always tells the execution time
      syntax highlighting
      table/column completion
      decent editor
      sql plan display
      free or inexpensive
      decent error messages with highlighting or at least line number indication

    It seems that you can't get them all. Currently I think I may use the free version of toad for sql plan display, but use Idea and the SQL plugin for everything else. However, I find the SQL plugin simple editing capability to be, ahem, minimal, so I'm thinking I'll just use Idea proper to edit sql, sending stuff to the plugin via a keyboard shortcut so that I can select something and hit C-enter C-enter to send and execute. It's easy enough to enter the keywords into a sql file type description for highlighting, but that leaves me lacking table/column completion and schema-based highlighting. Of course, then there is the remaining problem that apparently only SQLPlus and perhaps their JDeveloper will tell you where your sql syntax error is (sometimes).

    Anyway, I mostly wanted to post this to recommend that any SQL plugin really ought to rely on the editing capability of Idea itself rather than implementing its own editor like the existing one does. I'd love to be able to use Idea's navigation and javadoc facility on create table statements as well.
  18. Database Support[ Go to top ]

    "Also, there are a few silly little bugs that could use cleaning up. Something that springs to mind is the iteration shortcuts that generate a pre-5.0 for loop and then suggest that it would be better to use the foreach style!"

    This is not a bug. The shortcuts are live templates. If you type "itco" and tab you will get a pre-5.0 style loop. If you use "iter" and tab then you will get a 5.0 style loop.
  19. Eclipse's Pluggins Support[ Go to top ]

    What features do you think IDEA needs in future revisions?

    I'm not an Eclipse fan also, so I've bought IDEA 5 and I think it is great. So much better than Eclipse. But I think the best improvement they could offer is the support for Eclipse's pluggins. There are so many people writting pluggins for Eclipse that Intellij will soon be left behind (in my opinion).
  20. Eclipse's Pluggins Support[ Go to top ]

    But I think the best improvement they could offer is the support for Eclipse's pluggins. There are so many people writting pluggins for Eclipse that Intellij will soon be left behind (in my opinion).

    That is true, but making one IDE consume other IDE's plugin is 'Mission Impossible' if these two IDEs were developed independently as IDEA and Eclipse are.
  21. Plugin API[ Go to top ]

    While supporting Eclipse Plugins may in fact be nearly impossible, I think IntelliJ should drop all other plans for 6.0 and focus on plugin support. While (don flame suit) IntelliJ is to Eclipse as a BMW 850 is to a Buick Skylark, Eclipse is winning in the market because of (IMO) the fact that Eclipse has far far better plugin support, and therefore a better variety of plugins. I hear every week another colleague saying, with tears in their eyes, they have to switch to Eclipse because they depend on XYZ plugin.

    The developers at IntelliJ are some of the best I've ever seen. I would love to see what they could do if they put all their attention into fixing this one gaping deficiency. Many of the issues on their 6.0 roadmap would be addressed anyway by third parties if their plugin support was better.
  22. There are a lot of developers who uses IDEA and Eclipse simultaniously because IDEA works very well with code but it is easier to integrate other tools with Eclipse.

    There are a lot of deficiencies in Eclipse Java support. For example it isn't possible to refactor code with syntax errors but if you are performing a big refactoring it is almost impossible to make it through small steps after in such a way that after each of them code is compilable so you have to refactor code manually.
  23. Plugin API[ Go to top ]

    +1 Brian

    IntelliJ guys please do that and forget about your roadmap:
    - write extensive doc on the plugin API, openAPI, and all the XML descriptors used in the plugin (where is the custom completion plugin infrastructure? time to fix it...)
    - write 5 "how to write plugin" tutorials to help evangelise and illustrate key concepts (IoC, UI, compiler, openAPI etc)
    - host 3 sessions at java conference to explain IntelliJ plugin dev. key concepts (IoC, packages, compiler infrastructure, UI)
    - write (or have someone really good) 2 books (SourceBeat?) on IntelliJ plugin (I said plugin dev., not core features)
    - write a how-to re-write your Eclipse plugin so that it becomes an IntelliJ plugin - at least draw parralelism and best practices.

    I am sure if you guys lead some vision and roadmap there, you can find good folks to help you execute on that and at the end survive.

    On the side: integrate Java 5 & 6 APT with your compiler infrastructure and work on integration with CUSTOM completion with annotation, error validation, etc so that one can write an APT processor and a IntelliJ plugin that unleash the user experience for it (Eclipse is doing that right now in the JDT BTW, thanks to BEA' commitment).

    Alex
  24. Plugin API[ Go to top ]

    Alex,

    Most users of IntelliJ couldn't care less about plugins. We want an IDE that we download, install, run and it's perfect completely out of the box. I don't want to tinker around with it, I just want it to work.

    That's the fundamental "philosophical" difference between Eclipse and IntelliJ. IntelliJ users trust that JetBrains does the right thing and rarely if ever uses plugins. With Eclipse it's pretty obvious you can't trust the developers of it, and you have to rely on plugins to get it to do what you want.
  25. Plugin API[ Go to top ]

    Alex, sorry, that was a bit disrespectful, I'll rephrase it: I know where you're coming from in terms you want to do funky APT stuff and support both IntelliJ and Eclipse. But personally I just don't think that the vast majority of IntelliJ users care about plugins.
  26. Plugin API[ Go to top ]

    But personally I just don't think that the vast majority of IntelliJ users care about plugins.

    Of course, one doesn't care about plugins for plugins themselves: I care about the added functionality that plugins provide. What IDEA has been generally missing in the last years is comparable functionality with respect to what a number of popular plugins offer to Eclipse users (and I'm saying this being an IDEA user who just influenced a number of unsatisfied WSAD users to do the switch): it seems JetBrains has finally acknowledged this and has done a couple of moves to solve this problem. Only time will tell.
  27. Re: Plugin API[ Go to top ]

    Well, I tend to think most users of IntelliJ IDEA are developers and if they miss a feature and cannot wait for it to be added by Jetbrains (or other developers) they tend to fix it themselves. So plugins are important for them.

    I've tried getting into IDEA plugin development quite a few times, but stopped trying because of the lack of documentation (API docs are mostly empty in the OpenAPI and it's hard to find examples). It simply took way too much time for me to even get the simplest of things done.

    Last week I finally went trough and created my first IDEA plugin (http://ideadoc.sourceforge.net). It still has a lot of rough edges etc. But at least it works for me. It's amazing how much Google'ing one has to do to find out how to do something that simple. This really is the one area where IntelliJ IDEA needs improving in my opinion.
  28. Plugin API[ Go to top ]

    I just don't think that the vast majority of IntelliJ users care about plugins.

    I think the vast majority is not interested in plugin development, but I think they are interested in _using_ some plugin functionality that isn't part of the core IntelliJ package. Everyone I know who's using IntelliJ has some plugins installed, which they use on a regular basis. Maybe you're the exception, and the people you know?

    IntelliJ is IMO the most user-friendly and productive IDE on the market, still I find that most people I meet are using Eclipse, because of three things:

    * It's cheaper.
    * It has more and better plugins.
    * It's the "de-facto standard".

    If IntelliJ had better plugin support, it would have more and better plugins than it has currently. That would essentially make one of the points irrelevant.

    About the price, well any serious software producing company can come up with the money for a more productive IDE if it's IntelliJ the developers want. However, for students etc. Jetbrains needs to come up with something smart to compete with Eclipse.

    The "de-facto standard" part I believe has become a reality due to IntelliJ being behind on the other two parts, in combination with it having support from several powerful companies.

    As I'd like to keep using IntelliJ over Eclipse a while longer, I hope that version 6 turns out as great as I've come to expect from Jetbrains... :)
  29. Hi, guys,

    I think that marketing guys behind IDEA are missing the point.
    From version to version IDEA becomes slower and slower with a lots of hardly usefull things added.. I've played with idea 5.0 for about a day and threw it out. It's project loading time is about five times slower than in 4.0, it eats more memory and CPU and I found no single new feature to excuse such slowness.
    That's the first part. The second thing is a nightmare of public api -- it's not documented, not flexible (at least in vcs integration area), whith no chances to get help on intellij forum.
    I don't like eclipse... really.. it years behind IDEA. But... it has solid comunity and tons of plugins. Every time I've missed feature (related to integration with different VCS (darcs, monotone), different language (R, Ruby), different scms, whatever else .. just any integration task) in IDEA I found one in eclipse... And you know what? It's significally faster and much more responsive than IDEA.

    So the summary -- IDEA is looking much more like a marketing victim rather than leader in modern IDE world. Eclipse is worse for java+cvs development than IDEA, but the gap is narrowing with each release, while IDEA is loosing momentum.
  30. Public API[ Go to top ]

    I agree with all the previous posts asking for API improvements.
    IDEA is my favorite IDE, but it's hardly impossible to develop a plugin. The wiki is very light, the documentation is rare. not even mentioned on the official website!

    One nice feature comes to my mind: it could be great to be able to "deactivate" a module without make it disappear. I guess it could save memory, time, etc.
  31. First of all, we do not have any evidence of so major slowdown in project loading time between versions on usual configurations. IDEA 5.0 includes built-in CPU profiling, so if you could take and upload a CPU snapshot, we could investigate the reason why your specific project loads so slowly.

    As for plugin development support - I can see one message from you in our forums, dated one and a half years ago. Both the OpenAPI documentation and the support that we provide for plugin developers has improved significantly during that time.
  32. Project load slowdown[ Go to top ]

    I have also experienced slower project loading in 5.0 in comparison with 4.5.

    So how can I enable built-in profiling in IDEA to report the problem?

    Artem
  33. Project load slowdown[ Go to top ]

    On Windows, edit the file idea.exe.vmoptions in the bin\ subdirectory of the IDEA installation directory and add the following line:

    -Xrunyjpagent:port=10100

    Then restart IDEA. Buttons "Capture CPU snapshot" and "Capture memory snapshot" will appear in the toolbar.
  34. I bought one of the early IDEA versions (2.x) primarily because the user interface was "snappy" and generally much faster than the competition. It was also excellent for coding with keyboard shortcuts, solid refactoring support and so on. I'm still using IDEA and I still like it, but performance has definitely suffered lately.

    Optimizing performance should definitely be a priority. It is a key factor for me and probably for many others, though of course it may be harder to sell than a pure feature...
  35. Plugin API[ Go to top ]

    Alex, sorry, that was a bit disrespectful, I'll rephrase it: I know where you're coming from in terms you want to do funky APT stuff and support both IntelliJ and Eclipse. But personally I just don't think that the vast majority of IntelliJ users care about plugins.
    ... and you're probably wrong, hence the importance of a very thoroughly documented plug-in API :-)

    If IntelliJ followed your suggestion, IDEA would undoubtedly end up being bloated to the point where users would just give it up because "it's become bloatware and they don't need all these extra features".

    Plug-ins are key to survival for a software product these days. And I'm not talking just about IDE's.

    --
    Cedric
  36. Absolutely[ Go to top ]

    I agree that having good plugin architectures is crucial to successful products. There was a good blog entry on this topic with respect to open source, but it applies just as well to commercial software: http://weblogs.java.net/blog/jive/archive/2005/07/factors_of_succ.html

    One way in which Eclipse's plugin architecture is much better is that they built the product on it. IntelliJ, like older IDE's is based on the add-on model. This makes it dramatically harder to get it right, since the product developers aren't writing plugins as a core activity.

    As an aside, I think IntelliJ users are highly correlated with Mac users: they prefer a beatiful UI over a network of useful products. I can certainly say that I have had a harder time finding IntelliJ info online than Eclipse info...
  37. Please speak for yourself only[ Go to top ]

    You have no idea what most IntelliJ users want. Your notions about philosophical differences between IDEA and Eclipse are rubbish. The goal of both is to create the best IDE possible. Anyone who thinks plugins are not useful is a fool. Anyone who thinks developers at one company can anticipate the needs of all developers is a fool. JetBrains has put a lot of time and energy into their plugin API over the past few versions of IDEA. They know it's important and may be crucial to their long-term survival. I think creating a plugin for IDEA is easier than Eclipse. But for some reason it hasn't caught on yet. The suggestions of others in this thread are well thought out and could benefit IDEA.
  38. Plugin API[ Go to top ]

    That's the fundamental "philosophical" difference between Eclipse and IntelliJ. IntelliJ users trust that JetBrains does the right thing and rarely if ever uses plugins. With Eclipse it's pretty obvious you can't trust the developers of it, and you have to rely on plugins to get it to do what you want.


    Actually the people you trust with Eclipse are the pluggin vendors, so the suggested improvement in the Intellij pluggin support it`s kind of the best choice.
    I believe that when you use an IDE you expect your work to be done fastter and better and you don`t really care of any
    "philosophical" difference
    if you have to use pluggins or not, actually I've believe is a no wonder to use Struts Pluggin. At least at a project that uses Struts.

    Also it is really easy to install an Intellij pluggin, kind of like that.
  39. Plugin API[ Go to top ]

    We aren't able to forget our roadmap. :-)

    As for OpenAPI: our plugin.xml format is already documented. The OpenAPI documentation has been greatly extended in the 5.0.2 update and will be extended even more in Demetra. Some tutorial information is already provided and we're definitely going to provide more. Sessions at Java conferences - possible, but no promises yet. Books - I really doubt they would pay off. We have a lot to provide in electronic form before it'll make sense to start thinking about books.

    Custom code completion API is already listed in the 6.0 roadmap.

    As for APT integration - we're still evaluating this issue. We're currently getting interesting results from a different approach - bytecode instrumentation using the ASM library.
  40. Plugin API[ Go to top ]

    As for OpenAPI: our plugin.xml format is already documented. The OpenAPI documentation has been greatly extended in the 5.0.2 update and will be extended even more in Demetra. Some tutorial information is already provided and we're definitely going to provide more.

    As far as I can gather, it seems that either the current documentation is not good enough, or not found by the majority of people writing here. Maybe some aggregation to one place, with some better marketing is in order?

    Last time I had a look at the plugin stuff (when 5.0 was released), I just gave up after a while because there wasn't one single, reliable source that truly gave me the information I needed to do the (relatively simple) plugin I wanted to test the OpenAPI with.

    I ended up cruising Google, looking around other people's code etc, and then on to trial-and-horror land. Perhaps things are better now, with 5.0.2?
  41. Plugin API[ Go to top ]

    Unfortunately it's true that the documentation we have now is not sufficiently easy to find. This will change very soon.
  42. Plugin API[ Go to top ]

    +1

    Unless the quality and amount of available plugins is improved significantly, then I fear Intellij will no longer be a viable alternative. IMHO it is struggling to be so now, even though it is the best Java development environment by a mile.

    A fancy team server is just not going to cut it.
  43. Plugin API[ Go to top ]

    While supporting Eclipse Plugins may in fact be nearly impossible, I think IntelliJ should drop all other plans for 6.0 and focus on plugin support.

    You hit the nail on the head. There is far more momentum (and hype) in the Eclipse plugin in community ... geez, even the jEdit community, for that matter. I hear the same thing among the Java developers here at Yahoo ... "IDEA is awesome, but Eclipse is the way to go because of the plugin community." Skip a cycle of adding enhanced features, guys, and spend it enhancing the plugin architecture, APIs, IDE support, and documentation -- then let the community help contribute features to make IDEA really rock the world.

    We're using Flex, btw, for some of our rich internet apps -- and it looks like we'll be using Eclipse soon since Macromedia chose it for the next version of FlexBuilder (previously a customized version of DreamWeaver). IDEA guys ... are you listening...?
  44. Plugin API[ Go to top ]

    Fortunately the options are not mutually exclusive: improving the OpenAPI and documentation does not require dropping all other work that can be done in a release cycle.

    Fortunately or unfortunately, IntelliJ IDEA is a development environment, not a platform, so it's no wonder that Macromedia chose Eclipse when they needed a platform.
  45. Plugin API[ Go to top ]

    I hear every week another colleague saying, with tears in their eyes, they have to switch to Eclipse because they depend on XYZ plugin.

    Could you please name some of the plugins which caused people to switch? Maybe we can suggest alternative IntelliJ plugins, or advise how to achieve similar functionality using core IntelliJ features.
  46. Plugin API[ Go to top ]

    I hear every week another colleague saying, with tears in their eyes, they have to switch to Eclipse because they depend on XYZ plugin.
    Could you please name some of the plugins which caused people to switch? Maybe we can suggest alternative IntelliJ plugins, or advise how to achieve similar functionality using core IntelliJ features.

    I won't speak for everyone, but I personally am forced to use Eclipse whenever I use aspects (AspectJ.) I totally understand the JetBrains' point that it doesn't make sense to integrate every technology known to mankind with any particular IDE. That's why I agree with most postings in this forum: IDEA should provide much better support for plug-in development, the kind that would encourage the plug-in developers to write for IDEA. I am in no position to give any advice to the JetBrains marketing people, but IMHO, that should be a #1 priorioty. Someone has brought up the analogy with the Windows/Mac OS war that MS - with their clearly inferior product - has won hands down simply because they had made sure that software vendors write more software for Windows than Mac, or PS/2 for that matter... I evangelize IntelliJ everywhere I go, and I was able to convert one of my clients (a fairly large engineering department with several dozen developers) to IntelliJ. However, I can testify that it's getting more and more difficult to convince dev managers to adopt IntelliJ vs. Eclipse - not because of the cost, but mostly because of the supported functionality/technologies. There are thousands of Eclipse users per one intelliJ user out there, and Eclipse doesn't even come close to IDEA in quality! That's a fact. These days, I am grateful that the client simply doesn't object my using IntelliJ while everyone else on the project is using Eclipse. But even I have to switch when it comes to AspectJ. New technologies pop up all the time, and some of them become a crucial part of everyday development: Spring, Hibernate, AspectJ, etc. It doesn't take long for the Eclipse community to come up with the plug-in. It should be the same with the IntelliJ community. Otherwise, IDEA is doomed. Encouraging developers everywhere to code "for IntelliJ" and making it easy is probably the only way for this wonderful IDE to survive in the market. Therefore, it may well be worth it to invest into a well-written, comprehensive book on IntelliJ plug-in development, and, perhaps, re-architecting IDEA itself to be more open to integration with new technologies.

    I hope folks at JetBrains very well understand that all of us here are true fans and admirers of their product - with no intent to criticize in any way. IMHO, IntelliJ is not just the best IDE ever, it's one of the best and most intelligently crafted software products out there. Period. JetBrains sets standards in software development, and their IDE helps ordinary programmers to become better software engineers. I just hope it continues to be a viable alternative to inferior but dominating products like Eclipse - for a long, long time. Thanks JetBrains, good luck, and keep up the good work! :)
  47. Plugin API[ Go to top ]

    JetBrains sets standards in software development, :)

    Really? Then why should they worry whether their IDE viable or not? Seting standards is the true merits of the Eclipse project.
    I just hope it continues to be a viable alternative to inferior but dominating products like Eclipse - for a long, long time.

    IDEA has never had the penetration JBuilder once had. It will only be viable if it follows the lead of Eclipse.
  48. Plugin API[ Go to top ]

    Remember that people who read this thread are generally pro-IDEA. Most people who are happy with Eclipse probablly don't bother to read this thread.

    My surprise once for not using WSAD at the only WebSphere/IDEA shop (in Australia) was read unfavourably by the interviewee. Without that experience, I wouldn’t have been here.
  49. Plugin API[ Go to top ]

    Being surprised once by a WebSphere shop using IDEA instead of WSAD was read unfavourably by the interviewees at that company.
  50. Plugin API[ Go to top ]

    Since when did the level of market penetration set the standards for the quality of anything??? Does Ford make better cars than BMW? It is the standards for software "craftsmanship" that I am talking about. Every tiny feature in IntelliJ is designed and implemented with a great deal of care, attention, and - without a doubt - with a sense of pride for the final product. That's how all of us should write software. The nature of Eclipse and its openness make it more available, but being open-source by no means implies the quality of the implementation. As we all know...
  51. Eclipse's Pluggins Support[ Go to top ]

    Unfortunately this is not going to happen, because the architecture of IntelliJ IDEA is completely different from that of Eclipse.
  52. How about Spring support?[ Go to top ]

    How about first-class Spring support?
  53. How about Spring support?[ Go to top ]

    No no, you have it all wrong. Spring is IOC so you need to modify it to support IntelliJ and not have your IDE muddied up with the API for the framework. ;)
  54. Please, file particular feature requests here
    http://www.jetbrains.net/jira/secure/CreateIssue!default.jspa.
    Note, that properties in your Spring bean files are alreay completable,navigatable and refactorable in IDEA 5.0.2.
  55. I, too, think Spring integration is crucial.
  56. I, too, think Spring integration is crucial.

    Spring and Hibernate / EJB3 persistence native support would be a lifesaver. Understanding OR mapping files as part of refactorings would be a major boon. Right now it has to be a major win to touch the domain model because getting all of that stuff in sync is a PITA. Similarly, but to a lesser degree, for Spring managed beans.

    Having written the barest functional beginning to an Ivy dependency plugin for IDEA, I can definitely agree that docs for the OpenAPI would be a huge win. It's way too hard to figure out how to do things, and usually involves asking in the forums (which did prove to be helpful, but I'd rather not have to ask and wait).
  57. Accessor methods should be found in Hibernate (in 5.1 eap) /Spring (in 5.0.2) xml files so the refactoring will change them correctly.
    EJB3 persistence support will be in Demetra.
  58. Hibernate plug-in[ Go to top ]

    Beto Software recently released Hibero 1.0, a Hibernate plug-in for IntelliJ IDEA.

    Hibero adds auto-completion, syntax and error highlighting, go to declaration, find usages, rename, move and safe delete refactorings, code inspections and quick fixes to Hibernate mapping files.

    For more information about Hibero's features, please visit:
    http://www.hibero.com/

    You can download Hibero 1.0 for a free 30-day trial at:
    http://www.betosoftware.com/hibero/download.html

    Hibero 1.0 is available for just $35 USD until 15 December at:
    http://www.betosoftware.com/hibero/buy.html

    Cheers
    -The Hibero Team
    Beto Software, S.L.
    http://www.betosoftware.com/
  59. Plugins[ Go to top ]

    I agree with the rest of the post about the need for better plugin dokumentation, tutorials etc.
  60. I've been a huge IntelliJ IDEA fan for many years. My current company has a mixed set of developers...1/3 of us are using IDEA and the other 2/3 are using Eclipse.

    Management (without asking me) bought me a new license to 5.0 (already have 4.5 license). Unfortunately we've had several people here evaluate 5.0 (up to 5.02) all with bad results. Most of them have moved back to 4.5.x. We've had problems ranging from any ant build script usage inside IDEA completely destablizes the product to clipboard copy/paste blowing up IDEA and requiring a reboot. We have some people who have moved over to Eclipse because of slowness/stability issues. Unfortunately the more developers we have using Eclipse the more difficult it will be for those of us who use IDEA to justify supporting two different development environments.

    I'd love to get all the great features that are listed here for 6.0...but I can't imagine I'll be able to even use them if 5.x can't be made stable.
  61. We are aware of the problems with the Ant integration. Unfortunately we can't fix them easily, so the fixes for them are planned for the 6.0 release, not 5.0.

    The clipboard problems should be fixed in IntelliJ IDEA 5.0.2. If they are not, could you please provide the details on the OS under which the problems occur?
  62. Perhaps here is an opportuntity to re-architect IntelliJ to use plug-ins that are loaded as needed. Not only would you have to document the plug-in API very well, but it may solve the performance and memory use issues I'm reading about.

    IntelliJ had the nicest interface when I last evaluated it. Unfortunately, at the time, JBuilder just offered more functionality.

    Eclipse is not a better IDE, but it does have an enormous amount of mindshare and that's the main reason I've made the switch.

    Give me something that offers a wealth of plug-ins with an IntelliJ look and feel and I will invest the money.
  63. Perhaps here is an opportuntity to re-architect IntelliJ to use plug-ins that...
    Like 50 posts here on how important plugins are, but no mention of JSR 198. The JCP seems irrelevant again. The executive committee for 198: Apache (don't grok desktop), Fujitsu, IONA (CORBA dying), Nortel, Apple, Google (don't grok J2SE desktop), Intel, HP, JBoss (don't grok J2SE), SAP, Doug Lea, etc. Who the heck is Doug Lea, and what's his experience at extending an IDE?

    Is JSR 198 compatible with SWT?

    What on earth is IDEA doing about JSR 198? Nothing?
  64. JSR 198[ Go to top ]

    We will seriously consider supporting JSR 198 as soon as at least one significant IDE extension based on this spec appears.
  65. Check this:

    http://www.theserverside.com/news/thread.tss?thread_id=37721

    "Parabuild attempts to cure the pain of broken code bases. With Parabuild, daily builds can succeed if the head of the code base is broken. Continuous integration builds provided by Parabuild ensure that new changes integrate into existing code base.

    Key Parabuild Features

     - Continuous integration builds.
     - Daily, nightly and QA builds.
     - High speed Web interface.
     - Integration with ClearCase, Perforce, Visual SourceSafe, Surround SCM, CVS and Subversion.
     - Build scripting: shell scripts, Perl, make, MSBuild, nmake, ANT, nANT, Maven, Jam and VB.
     - Multiple platform support: Windows, Cygwin, Linux, Solaris, HP UX and generic Unix, including Mac OS X.
     - Release notes from Bugzila, Peforce jobs and Jira.
     - Two-minutes installation; fifteen minutes to first build.

    Parabuild is Different

     - Uninterrupted daily builds.
     - Remote multiplatform builds.
     - Running existing build scripts.
     - Low to zero administration.
     - Searchable logs and results archive;
     - Group-based security;

    A working evaluation version of Parabuild 2.0 is available for download at http://www.viewtier.com/downloads/index.htm"

    May be we should join our forces :)

    Regards,

    Slava Imeshev
  66. SWT ??[ Go to top ]

    And what about SWT support ?? Am I just dreaming ????? I'd love to be able to design SWT interfaces... or at least use an eclipse plugin that could do so...
  67. SWT ??[ Go to top ]

    Is there a market for SWT design tools? I think those developing for Eclipse won't be willing to pay for IntelliJ...

    Regards,

    Slava Imeshev
  68. I wonder if in 6.0 we will (finally) be able to use standard GridBagLayout manager for our GUI needs? I've had to use jDeveloper instead of IDEA for many small projects where my clients insisted on providing full source code for anything but "standard" java libs. And, of course, closed-source component is an immediate no-go for open-source projects.

    I recall there was a converter plugin for 4.5, which had allowed to trnaslate IDEA GUI forms into GridBagLayout-managed ones, but I never was able to make it work.

    All this "web" things are good, but 50% of my clients still demand a plain old nice GUI for their needs :-).
  69. Small clarification: I'm not saying that GridBagLayout is king, or even that it is somehow better than IDEA's custom one. Not to start that war here, no. Its just that _a lot_ of _my_ customers demand only standard _or_ open-source components in their projects, and IDEA's layout manager doesn't fit either.
  70. Since version 5.0, our forms runtime is clearly licensed under the Apache 2.0 license, and its source code is included in the IDEA distribution. So it cannot be considered a closed-source component any more.

    And yes, version 6.0 will use GridBagLayout as the default layout manager, and will not require any forms runtime if GridBagLayout is used. The old layout manager will also be supported for those who need 100% compatibility with existing forms.