IDEA 6.0 and team development

Apologies in advance to anyone who doesn’t want to hear any more “What I want for IDEA 6.0” threads, but I’m afraid the time has come. I’ve been meaning to write this for a while, but the need crystallized when I had to have three separate conversations with people about whether to purchase 5.0 licenses. I’m sad to say, I was eventually beaten back to defending the position “If you develop for the web, 5.0 is very strong, and in some ways amazing. If you just develop server-side Java, 5.0 has some nice usability improvements, a few cool features, it’s more performant, and there’s a bunch of new inspections. No real 'wow', I'm afraid. I personally think it’s worth pure Java developers paying for, but I could see it being a difficult sell”. This was, as you may imagine, somewhat sad.

Part of the issue is that IDEA 4.5 was in many ways pretty close to being a perfect tool for single-programmer pure-Java development. There just wasn’t a lot of room for discontinuous improvement in terms of functionality. For 5.0, JetBrains decided to relax the “pure-Java” clause of that sentence, providing features for Java developers who also built web pages. For 6.0, I’d like to see JetBrains relax the “single-programmer” clause. Enterprise development is a team sport, and it’s time the best development tool in the world recognized it.

(Yes, I know that a lot of “teamware” has been sold which turned out to be worthless crap. It is a measure of how much I trust JetBrains that I believe they won't do this. They’ve always understood actual developer work patterns at least as well as they understood compiler and debugger internals.)

Here’s some examples of the “team-aware” functionality I want to see:

Deep understanding of version control branching: I want to be able to easily understand and navigate through the various branches of my project’s source control tree. I want to be able to open files from multiple branches either in one project window or open different branches in different windows, with clear visibility of cross-branch relationships and easy cross-branch manipulations. Working on multiple branches will never be easy, but it can surely be made much easier by someone who understands how developers actually use version control systems. No one’s ever managed to do this well before, but I have faith that if anyone can do it, it’s JetBrains.

Collaborative tooling: For every minute of the day I spend coding, I spend another looking over other people’s shoulder at their code, or having them look over their shoulder at mine. Help me make those minutes pleasurable too. Allow me to send files and stack traces to peers, Allow me to share editing or debugging sessions. Let me know what files my coworkers are modifying, before they check them in, so that we can avoid stepping on each others toes. Let me know they are working on something else entirely, so I don't run over and bug them. And yes, no matter how vulgar it may be, let me IM them in a code-aware editor. Presentations on what NetBeans and JDeveloper are working on in this area were given at JavaOne, and actually look pretty useful and impressive. I’m sure you guys can do better. (Note: If you offer http as a transport layer for this, it’ll both alleviate firewall worries and give you a reason to build some kick-ass web services support).

Package up refactoring sequences as migrations. Not every collaboration is so close as to be in the same project. If I can package up a sequence of public signature changes and send them to one of the projects that depends on me in an e-mail, it would enable them to automatically migrate to new versions of my stuff. Third-party libraries could have automatic upgrade paths for their users.

“Best practices” community host site: Similar to the plugin manager, this would enable smaller customizations to be shared from a JetBrains hosted site. Customizations like file templates, live templates, macros, structural-search-and-replace templates, and migrations sequences could be uploaded by community members to this site, and available for downloading and automatic installation by anyone else. Network effects, empower your community, yadda, yadda, yadda.

Remote libraries: Allow me to specify URLs for library content locations, so that a team’s dependent libraries can be managed centrally. This could be a maven repository, Ibiblio, or just an ftp site. Manage fetching, versioning, and caching libraries in the background, so I don’t have to think about it. Someday we’re going to laugh when we see “lib” directories in Java projects, and cry when we have to maintain code that has them.

Resource and library clash analysis: Picture a global inspection that reports every possible class or resource name clash, so that you can have an easy way of seeing that the two XML libraries you indirectly depend on won’t work together. Big projects depend on a lot of stuff, and there’s often no single person in charge of managing all rhe dependencies. Show me that I’m about to step into JAR hell before I have to spend hours debugging classpath issues.

“Runtime-only” libraries. Big projects often have to import a bunch of libraries due to indirect dependencies, but those libraries shouldn’t be actually referenced in the project. Allow me to indicate that while some fool of a library developer decided to depend upon commons-lang, my code absolutely won't use it, so don’t complete, navigate to, or auto-import from commons-lang classes. The module system should make life easier for users, not just be a way of representing complex builds.

Patch creation and application. Obviously.

Directory-level diff and merge. Obviously.

For the last few years, IDEA has helped me to be the best and happiest developer I can possibly be. I honestly don't see how it can get noticably better at that task. It's time for it to help build and nurture the best and happiest development teams that can possibly be.

--Dave Griffith

30 comments
Comment actions Permalink

This all sounds okay, but I don't think I'd use much of the advanced
features you suggest. You say you don't see how IDEA could get
noticeably better at improving coding. I think there are miles and miles
to go before this is the truth (if it will ever be true).

- There are many abstract refactoring tasks that I perform all the time,
which a very smart IDE could perform for me, better and faster, in a way
that we could all use and benefit from.
- Language API support could be improved 100x.

To me, these things are more important than what you suggested. I don't
want IDEA to turn from editor expert to slightly out of date editor,
esoteric team software.

0
Comment actions Permalink

Dave Griffith wrote:

If you just
develop server-side Java, 5.0 has some nice usability improvements, a
few cool features, it?s more performant, and there?s a bunch of new
inspections. No real 'wow', I'm afraid. I personally think it?s
worth pure Java developers paying for, but I could see it being a
difficult sell?.


New refactorings, new inspections, new intentions, improved usability,
@Nullable and @NotNull annotations, plugin Modules and word completion
are what make me buy IDEA 5.0. Subversion integration is nice too. I'm
actually most impressed by the @Nullable and @NotNull annotations, they
really made me see the power of annotations when used correctly.

Deep understanding of version control branching:

> Collaborative tooling:
> Package up refactoring sequences as migrations.
> ?Best practices? community host site:
> Resource and library clash analysis:
> ?Runtime-only? libraries.
> Patch creation and application.
> Directory-level diff and merge.

Yes, I want it all. Most of these would be very useful even for a lone
developer.
The only thing that makes me a bit scared is remote libraries. I
wouldn't want my project to depend on the availability of some remote
server or the internet for that matter. On the other hand it would be
nice if IDEA watched some directory I specified and picked up libraries
automatically. Whenever this directory is then updated from version
control, my project files would then be automatically modified (after I
confirmed) to include or exclude new libraries as needed. Hmm, that's
another item for my plugin ideas list.

Bas

0
Comment actions Permalink

+ I'm
actually most impressed by the @Nullable and @NotNull annotations, they
really made me see the power of annotations when used correctly.+

Agreed. These provide easily the biggest "wow" factor for server-side Java programmers in this release. Props to Keith for presenting these and providing the initial push.

+The only thing that makes me a bit scared is remote libraries. I
wouldn't want my project to depend on the availability of some remote
server or the internet for that matter. +

Unless you specifically tell it not to, IDEA is already copying your library jars to a secure, undisclosed offsite location, and then using the copies to build and run against. If you were using a remote library and were off-net, IDEA would silently default to using your last download, possibly giving you some "last download time" marker if you looked at the library in Settings/Modules. Hell, the internal references for library locations are already URLs, it's just that only "file://" and "jar://" protocols are supported. Add "http://" and "ftp://" and a small UI to support them, and this feature request should just work.

--Dave Griffith

0
Comment actions Permalink


+- There are many abstract refactoring tasks that I perform all the time,
which a very smart IDE could perform for me, better and faster, in a way
that we could all use and benefit from.+

I'd love to hear them. My automatable refactoring wish-list has something like six things on it, and only one of those shows up often enough to really feel the lack (enhancing "extract method" and "inline method" with gaurd and tail extraction/inline, if anyone at JB is listening).

- Language API support could be improved 100x.

I wouldn't say 100x, but improvements are needed. However, this helps pure Java programmers very little, by definition.

--Dave Griffith

0
Comment actions Permalink

Dave Griffith wrote:

If you were using a
remote library and were off-net, IDEA would silently default to using
your last download, possibly giving you some "last download time"
marker if you looked at the library in Settings/Modules.


The thing I'm afraid of is that I couldn't build my freshly-updated-from
source-control-project anymore, because it now depends on a new version
of amazing-but-often-changed-library, which I can't get at because the
remote library server is down (for example). All libraries in all my
projects are checked into version control for this reason.

Bas

0
Comment actions Permalink

Dave Griffith wrote:

+- There are many abstract refactoring tasks that I perform all the
time, which a very smart IDE could perform for me, better and faster,
in a way that we could all use and benefit from.+

I'd love to hear them. My automatable refactoring wish-list has
something like six things on it, and only one of those shows up often
enough to really feel the lack (enhancing "extract method" and
"inline method" with gaurd and tail extraction/inline, if anyone at
JB is listening).


A few off the top of my head:
- Enhanced extract method.
- Extract bean. (convert parameters to bean, and for multi return values
in extract method)
- Extract statement / inline statement (for example if I call a method
in an if and an else, I could extract it to be called after the if/else,
using variables to store the parameters which are assigned in the branches)
- Pull statement in / push statement out (into / out of method)
- Extract class / move members (not just methods) to another class.

- Language API support could be improved 100x.

I wouldn't say 100x, but improvements are needed. However, this
helps pure Java programmers very little, by definition.


I think most Java programmers could use a few DSL's, if given a smart
editor for them.

0
Comment actions Permalink

For me the biggest problem with IDEA is not any lack of features, but rather a very noticeable lack of a thriving plugin pool. And in the end if I switch away it will be primarily because a lot of tooling is only getting written for the Eclipse platform.

When I talk with companies who write plugins and ask them why they don't support IDEA, the most common responses I get are that IDEA's plugin API is 1) very complex, 2) purely documented, 3) not stable. And, naturally, they cannot develop in such environment.

Look around and see how many abundant plugin projects are there. Where is a working subversion plugin (yeh, I know it's in 5.0, but we should've had it a year ago)? Where is a finished Maven plugin? Where is a finished Jira plugin? Why Hibernate implemented their tooling as an Eclipse plugin and not in IDEA?

I'm going to give IDEA one more version to get the third-party plugin community in shape. If it will not have happened by 6.0, I'll have no choice but to switch.

0
Comment actions Permalink

Dmitry Beransky wrote:

Where is a finished Jira plugin? Why Hibernate implemented their


A finnished Jira plugin is NOT the result of a poor plugin API. Its a
result of me getting lazy, putting my back out, getting a life and
reading more books, spending more time with friends etc.

The Jira plugin was written to scratch an itch, we've not upgraded our
JIRA install from 2.6 (which is a driving force in me not really
changing alot of functionality for newer vesions of jira), and mostly -
the repository is on a server machine I don't want to give joe-random
public access to (this may be changing thou).

0
Comment actions Permalink

I am on record as saying that a fully documented and stable open API is the most important and easiest thing JetBrains could do to improve their product. I'm also on record as saying that the vast majority of developers don't care about plugins, and indeed never install one. I stand by both those statements. I am great. I contain multitudes.

--Dave Griffith

0
Comment actions Permalink

Dmitry Beransky wrote:

For me the biggest problem with IDEA is not any lack of features, but
rather a very noticeable lack of a thriving plugin pool. And in the
end if I switch away it will be primarily because a lot of tooling is
only getting written for the Eclipse platform.


You say lack of features is not a problem. If IDEA has all the features
you want, why do plugins matter? I don't disagree that the plugin
support needs work, but you said a funny thing.

Look around and see how many abundant plugin projects are there.
Where is a working subversion plugin (yeh, I know it's in 5.0, but we
should've had it a year ago)? Where is a finished Maven plugin?
Where is a finished Jira plugin? Why Hibernate implemented their
tooling as an Eclipse plugin and not in IDEA?


It wouldn't make sense for a huge project like Hibernate to write a
plugin only for IDEA. Then, to use Hibernate effectively, developers
would need to buy IDEA, so effectively Hibernate would cost $500,
instead of being free.

0
Comment actions Permalink

I'm in the "need more plug-ins" camp. However, I think some of those
plugins should come from Jetbrains. Eclipse has better Spring and
Hibernate support because of third-party plugins. For server-side guys
like myself, first class Spring and Hibernate support would be more
important than say CSS support(which is impressive mind you).

I do web apps, but given a choice between Spring support and CSS
support, the Spring would give me bigger bang for the buck.

--
-


David H. McCoy


-


0
Comment actions Permalink

For a start at collaboration, have you tried the IDETalk plug-in (http://idetalk.com/) ?

It's somewhat limited, but very useful in what it does.

0
Comment actions Permalink

IDETalk is certainly a good start, and I do use it on a couple of projects. It's also a good indication that there's a lot more work still to be done, and a lot of value still to be acheived.

--Dave Griffith

0
Comment actions Permalink

In article <dcg9l6$cl9$1@is.intellij.net>,
Keith Lea <keith@cs.oswego.edu> wrote:

Dmitry Beransky wrote:

For me the biggest problem with IDEA is not any lack of features, but
rather a very noticeable lack of a thriving plugin pool. And in the
end if I switch away it will be primarily because a lot of tooling is
only getting written for the Eclipse platform.


You say lack of features is not a problem. If IDEA has all the features
you want, why do plugins matter? I don't disagree that the plugin
support needs work, but you said a funny thing.


I suspect he means, and I know I mean, that the features I want from the
core IDE are quite good. That said, there are minority features that
are not in IDEA, and that would add a bunch. Those features are
probably of interest to enough people to be worth implementing, but are
not of enough interest to go in the main IDE. Certainly, I can think of
a lot of things that most users would not want to pay the memory and UI
footprint for, but that would help me a fair amount. IDEA uses plugins
for such optional things, especially if they need to be maintained by
others outside JB, so that is why a thriving plugin community is a good
thing, at least to me.

For me, Hibernate and Tapestry are important tools, and the existence of
Eclipse plugins makes me look at the Other Side every now and then.

Look around and see how many abundant plugin projects are there.
Where is a working subversion plugin (yeh, I know it's in 5.0, but we
should've had it a year ago)? Where is a finished Maven plugin?
Where is a finished Jira plugin? Why Hibernate implemented their
tooling as an Eclipse plugin and not in IDEA?


It wouldn't make sense for a huge project like Hibernate to write a
plugin only for IDEA. Then, to use Hibernate effectively, developers
would need to buy IDEA, so effectively Hibernate would cost $500,
instead of being free.


Yes and no - if enough Hibernate folks use IDEA, they would probably
write a plugin just to make their own lives easier. Sure, adding a $500
required component to Hibernate isn't going to happen, but adding a $500
optional one might just, especially if it makes some Hibernate dude
happy.

Scott

--
Scott Ellsworth
scott@alodar.nospam.com
Java and database consulting for the life sciences

0
Comment actions Permalink

I am on record as saying that a fully documented and stable open API is the
most important and easiest thing JetBrains could do to improve their product.
I'm also on record as saying that the vast majority of developers don't care
about plugins, and indeed never install one. I stand by both those
statements. I am great. I contain multitudes.


I agree with statement 1. Plugins are important if JetBrains can't
write them.

That said, they NEED to clean up the interface and the various usability
issues, the inconsistencies in user interface such as the crazy popup
progress bar, the fact that a lot of the refactorings, search etc...
happen in the foreground and lock up the IDE half the time while
something is going on, and often you don't know what's going on. There
is a serious need to have some type of a threading queue to improve the
IDE's performance and not have the constant jitering when typing in a
jsp file, or a java file for that matter (depending on what's going on
in the BG.) This stuff needs to be 5.5 improvements, not 6.0. We need
that sooner than later.

I have honestly also reached a point in idea where I think improving the
current feature set is sufficient. Improving in the sense of polishing
what's there. I am not entirely sure I agree with everything you said
in your original statement, I think it would push things a bit too much
for me.

I WOULD be interested in tools which make collaboration over the network
feasible and useful such as Code Sharing on screen and Chatting while
describing code and working on code. To be more specific, I would like
to see tool to help Agile development, specifically remote pair
programming, manage continuous testing, help with TDD where when you
create a new class it might create the test class as well, and as you
write code, it would somehow help you also write your tests at the same
time.

What I don't want to see is IDEA 'helping' me save my libraries to some
remote server which will be down one of these days and cause havoc when
I can't get a needed library.

I do wholeheartedly agree that we need patch creation of file and dir,
and patch application on file and dir. I'm disappointed that jetbrains
felt that this could be dropped off the list since this is something
many have asked for for a while.

One thing that was not on your list which I'd like to see is the help
with creation of web services; Both client and server side. There is a
lot of repetitive work there, and they could easily knock that off the
table for us.

Best.
R

0
Comment actions Permalink

For what it is worth, I stopped using IDEA and started using Eclipse for the very reason that no major plugins (e.g. Hibernate, Tapestry) exist for IDEA. Sure, there is a Hibernate plugin for IDEA, but it is very outdated. I see that now 5.0 has Subversion built-in, the only thing that I really need is a Hibernate and Tapestry plug-ins. If they exists, then I will definitely switch back :-). The huge benefit for having these plug-ins (for me anyway) is the ability to generate the initial files (e.g. hbm.xml for Hibernate and .page for Tapestry). That's a huge time saver for me.

I am seriously considering using both IDEs but that's just too much work to try to keep two IDEs in sync.

I also want to make another observation. So far, all the plug-ins for IDEA (besides the commerical ones) are someone's pet project. Nothing wrong with that and I commend them for their efforts. But usually, someone releases something and its looks promising, but very quickly, it gets outdated and no improvements are made. Basically, you cannot rely on these plug-ins. A good example is the couple of Perforce plug-ins donated by a couple of developer a while back. They kind of worked but quickly after, they were outdated and the bugs were not fixed. I think IDEA or a commerical vendor needs to take up the task to build these plug-ins for the major frameworks. The Hibernate or Tapestry group will always focus their resources on the most popular IDE (e.g. Eclipse).

BTW, I am even willing to pay for a commerical Hibernate or Tapestry plug-ins. Any taker?

Ben

0
Comment actions Permalink

Mark, but the main reason there is no alternative to your plugin, IMO, is that it's not trivial to write and then to maintain one.

0
Comment actions Permalink

Keith, to clarify what I was trying to say:

If IDEA has all the features
you want, why do plugins matter?


I'm happy with the basic Java IDE related feature set that IDEA offers. The plugins are needed for integrating third-party products and frameworks (i.e. tooling).

It wouldn't make sense for a huge project like
Hibernate to write a plugin only for IDEA


I cannot reasonably expect the IDEA team to write and maintain a plugin for Hibernate. On the other hand, JBoss is in such position. Yet they chose to support Eclipse. Versant's JSR-220 tooling was developed as an Eclipse plugin even though the stand-alone version of their tool is based on Intellij framework. This is sad and ironic.

I'm not complaining about JetBrains not developing enough plugins. What I'm complaining about is they do not facilitate and promote third-party plugin development.

0
Comment actions Permalink

I agree 1000% with Dave's thoughts..in fact that is what I came to the forum to discuss, and as there is already this thread.

I am not a huge Eclipse/JBuilder fan, but read a recent article about JBuilder's new collaboration tools, and I was impressed to say the least. This is close to a 'killer ap' for use as we are a very distributed team and try to do as m uch agile stuff as possible. We have tired to do session via NetMeeting and related tools, but it just doesn't work well. The ability to share code-editing tokens, chat, debug traces, etc. would be enormously beneficial to us.

But to do that I would have to give up IntelliJ!! Plus Borland wants like $3k I think for the tool that supports this. Yea, right, that's going to happen..

If IntelliJ could do this that would be the coolest thing in IDEs since code-completion and would be a very easy upgrade sale into my company -- not to mention we would probably very quickly go from having a few of us use IntelliJ (we have a liberal tool-usage policy at my company, the hard part is getting someone to pay for a license) to a large part of the company...To play with eveyone else in the team programming sand-box an intenral developer would also have to be using IntelliJ.

So JetBrains, what about it? Please?

references:
http://www.theregister.co.uk/2005/09/19/jbuilder_2006_prev/
http://bdntv.borland.com/jbuilder/2006/jb2006_p2p.html

0
Comment actions Permalink

Have you tried the IDEtalk plugin ?
I am the only IDEA user at my site, so I haven't tried it myself, but from what I have read,
it has most of what you are asking for...and it's a free plugin!

0
Comment actions Permalink

The problem with IDETalk for us is it doesn't work over our VPN and, I
believe, over the internet in general yet.

"Tim Haley" <ymaraner@yahoo.com> wrote in message
news:dgovuk$grn$1@is.intellij.net...

Have you tried the IDEtalk plugin ?
I am the only IDEA user at my site, so I haven't tried it myself, but from
what I have read, it has most of what you are asking for...and it's a free
plugin!



0
Comment actions Permalink

No I will definetly have to. On first glance it seems close, but not quite, and as noted it only works on LAN right now. If you watch the Borland video, the whole thing is very seemless. You can pass editing tokens back and forth, watch live-navigation, etc.. so my first hunch is that it is much more full-featured. Still, I will definetly take a close look.

0
Comment actions Permalink

you want the IDEA being more and more large? if the new feature seldom used for 98% java programmer, you sold it to whom? more functionlity more complex and less smart, I think IDEA is the best intelligent IDE, if it keep this, that is good and enough.
this features should be consider first: do j2me development as good as the Jbuilder and Netbeans. Now no other IDE is as bad/poor/stupid as IDEA to develop j2me.


0
Comment actions Permalink

You do realize, of course that any J2ME integration at all probably is "a new feature seldom used for 98% java programmer". That looks likely to change, but for now team programming is vastly more common that J2ME programming.

you want the IDEA being more and more large?


As long as they can keep the design coherence, ergonomics, and performance, then yes, absolutely, I do want IDEA to get more and more large. I would hardly have spent time coding up all those inspections and intentions if I wanted anything else.

--Dave Griffith

0
Comment actions Permalink

idea + cvs/subversion is enough for team development. the j2me development should be very popular while there are more wireless applications. the IDEA is not the best tool to develop j2ee, and it is the best tool to develop j2se, but there seems not many development of j2se, now hope you catch the chance to be the best tool to develop j2me.

0
Comment actions Permalink

I think the point that he is getting at is that there are not that many
j2me developers. I myself have never met one in the flesh, not even at
a conference. There is just not as many jobs for j2me as there are
other java jobs. As such, the number of potential sales (we are talking
about a business here) is greater with team development than there is
for j2me support.



Evans Zhang wrote:

idea + cvs/subversion is enough for team development. the j2me development should be very popular while there are more wireless applications. the IDEA is not the best tool to develop j2ee, and it is the best tool to develop j2se, but there seems not many development of j2se, now hope you catch the chance to be the best tool to develop j2me.

0
Comment actions Permalink

If these more specialised apects of functionality could be made optional (e.g. as plug-ins), you could choose your functionality / footprint compromise.

An extended IDETalk style plug-in is what I'd like to see.

0
Comment actions Permalink

Evans Zhang wrote:

idea + cvs/subversion is enough for team development. the j2me
development should be very popular while there are more wireless
applications. the IDEA is not the best tool to develop j2ee, and it
is the best tool to develop j2se, but there seems not many
development of j2se, now hope you catch the chance to be the best
tool to develop j2me.


I think you overestimate the importance of J2ME. J2SE and J2EE are BIG.
Bigger than you can imagine. I work on a product which analyzes the
performance of J2EE systems. We have a lot of customers and we are not
the only company who makes a product like this. They're all big
companies and institutions with big systems worth lots of money.

Compared to that, J2ME is small fry.

I definitely think that IDEA 6 could add some more team-oriented
collaboration features that would be very useful for distributed
development teams.

Ciao,
Gordon

--
Gordon Tyler (Software Developer)
Quest Software <http://www.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: (416) 933-5046 | Fax: (416) 933-5001

0
Comment actions Permalink

>idea + cvs/subversion is enough for team development.

It's been good enough so far, but there are significant opportunities for valuable improvement. I listed about a dozen of them in the original note. Many of IDEA's competitor products are already pursuing these opportunities.

>the j2me development should be very popular while there are more wireless applications.

A quick and utterly unscientific browse of job sites and bookstore shelves puts J2ME usage at something like 1/30th of J2SE+J2EE usage. It's growing, sure, but still very tiny. It's fine for you to think that IDEA should have more J2ME support. Thinking that while complaining about addition of features which will only impact a small fraction of users is simply hypocritical.

--Dave Griffith

0
Comment actions Permalink

That's a very valid point. Since this is such a great tool, organizations must be given the privilege of using it as a team

______________
agile development methodology

0

Please sign in to leave a comment.