Bumpy transition to 4.0 not a good thing for IDEA
Let me start by saying that since I started using IDEA in version 2, I've thought it's the greatest desktop Java app ever written, and up til now, the most innovative and amazing IDE ever written. (And I've used a lot of IDEs over the past 20 years.)
Certainly 4.0 has a lot of great features in it. However, I have to say that the transition to 4.0 is uncharacteristically rocky, and I'm afraid this may really hurt IDEA's future.
Transitioning to v 3.0 was completely painless. Moving my projects to 4.0, however is taking MANY HOURS (see below). My fear? the poor experience of moving to 4.0 is going to drive a lot of users to try Eclipse, which I assume is the main competition. Purely as a business decision, the time & aggravation spent moving to 4.0 makes it worth my while to go see if Eclipse has improved since I gave up on it a year or so ago as not being "ready."
I actually feel bad for Intellij, because they've really earned their stripes, and then the Eclipse steamroller shows up and basically copies all the innovative IDEA features. If there's justice in the world, someone should buy Intellij for a billion dollars and make them rich, before Eclipse takes over the world.
Back to the 4.0 transition. First, various project settings simply didn't get carried over (I've seen other posts saying the same thing.) Things like code styles, color schemes, etc. This is huge, since there are so many settings to keep track of, the last thing I want to do is go through all the settings pages and try to remember what my "normal" settings are, and which ones were carried over and which ones weren't. This isn't major, but it sure is aggravating.
Secondly, the new "module" concept I guess is fine for more complex project configurations, but what percentage of cases use it? We already lay out our own modules, one project-per-ANT file, with no "embedded" modules. The poor documentation makes it very confusing to figure out what this feature really does. Content Roots? Source Path designations? The biggest barrier to using any IDE is figuring out what is needed to configure a project, and IDEA just got a lot more complicated. Worse, it can be dangerous - as I found out the hard way, if you deselect the "Source" folder designation in the very confusingly designed Path / Content Root dialog, everything seems to work the same way except major menu items are disabled (like "Reformat Code") with no way of knowing why! Ok, perhaps this just proves my stupidity, but it took me a long time to figure out why all these features were disabled. My stupidity didn't get in the way when moving to 3.0.
More serious is the loss of "local" mode for CVS users, with no transition plan. Maybe there are only a few of us, so Intellij could afford to just drop us. There are a lot of "gotchas" setting up CVSNT, and certainly a lot of time involved that I wasn't expecting to have to spend, since all of a sudden you're dealing with (Windows) networks, permissions, etc. Worse, I see that I wasn't the only one that ran into the problem that IDEA would connect properly to the CVSNT server ("test connection" would work, and "check out", etc.), but when you'd do more significant commands, you'd get "invalid root" errors, with no explanation. Most of my time has been spent resolving the CVS issue.
I should add that moving to CVSNT also exposed some real errors with 3.0's local-mode CVS support. Many directories that I had previously moved/deleted (and committed) have all re-appeared, so I'm having to go "fix" all my projects. Ugh.
Tonight I ran into yet another silly problem. I tried to run my JUnit tests to make sure I had everything right, and bang, an exception: "can't find class junit/textui/ResultPrinter". Huh? No other explanation? Where the hell did that class come from? How could they release a product that breaks everyone's tests? (Or at least, everyone who has been using a standard Junit library.) Now I have to use a custom IDEA Junit library? Whose brilliant idea was it to put a custom IDEA class in the standard "junit/textui" package? Sheesh! At least call it "junit/intellij" or something so I know where this is coming from.
Having to include a custom IDEA library in my project classpath just sucks. It screws up my ANT files (or makes my ANT files different from my IDE configuration), and doesn't let me upgrade to use standard Junit releases (with the corresponding API documentation, etc.). Just how did Intellij expect me to figure this out, other than searching this forum? Do they really think it's acceptable to be so intrusive in our configuration?
I'm sorry to sound like a whiner, and you're probably thinking I'm just an idiot, but please remember how much I've loved IDEA in the past. These problems just seem so uncharacteristic for Intellij. I'm really regretful that they've released a product with such a horrible initial experience, not just because they're wasting many valuable hours of mine, but I think it's really going to hurt them economically. IDEA's loss is Eclipse's gain.
Please take this in the constructive spirit in which it is intended...
请先登录再写评论。
Hi Robert,
On 2004/02/20 13:34, Robert Tuck wrote:
> Tonight I ran into yet another silly problem. I tried to run my
> JUnit tests to make sure I had everything right, and bang, an
> exception: "can't find class junit/textui/ResultPrinter". Huh? No
> other explanation? Where the hell did that class come from? How
> could they release a product that breaks everyone's tests? (Or at
> least, everyone who has been using a standard Junit library.) Now I
> have to use a custom IDEA Junit library? Whose brilliant idea was it
> to put a custom IDEA class in the standard "junit/textui" package?
> Sheesh! At least call it "junit/intellij" or something so I know
> where this is coming from.
>
> Having to include a custom IDEA library in my project classpath just
> sucks. It screws up my ANT files (or makes my ANT files different
> from my IDE configuration), and doesn't let me upgrade to use
> standard Junit releases (with the corresponding API documentation,
> etc.). Just how did Intellij expect me to figure this out, other
> than searching this forum? Do they really think it's acceptable to
> be so intrusive in our configuration?
The junit.textui.ResultPrinter class just comes from the standard junit
3.8.1. This class is not present in junit 3.7, but the upgrade should be
painless. The (imo) excellent IDEA junit integration apparantly requires
a specific junit version, which they supply with idea. Not a bad thing
in my opinion. Just let ANT also use junit3.8.1.
In IDEA 3.0 I didn't understand why anyone would use the IDEA junit
integration as it hardly offered anything more than what the standard
junit gave me from the command line. But the new integration in IDEA 4
is really nice.
Bas
Robert, regarding the project setup you might be right. It became much
more complicated. I'm sure, there is the possibility to hide the
multi-module complexity for simple applications.
If you are serious developer (and I guess you are because you are using
IDEA), then I never would use "local" mode for CVS, because it easily
can mess up the repository (see also
http://www.devguy.com/fp/cfgmgmt/cvs/cvs_admin_nt.htm#faq). Independent
of this, IDEA has now an built-in CVS client which runs without any
external CVS executable (except the CVS server). This allows some cool
features (e.g. repository browser) you would not have with the CVS
executable. But the problem is, that to manage the repository directly
(as the "local" mode of command line CVS does) would require CVS server
functionality, which is much more difficult to implement then the client
functionality.
Hmm, is this now a problem of IDEA or CVSNT?
Friendly,
Tom
In article <c15548$lq1$1@is.intellij.net>,
"Thomas Singer (MoTJ)" <nomail@nodomain.com> wrote:
I often have simple project configurations (even on big projects), but
most IDEs I've used, including IDEA, want me to do a lot of work to
configure the project.
IDEA is very smart in very many ways. I wish it were smarter about
creating projects. Instead of asking me a million questions in a wizard,
I wish it would ask me exactly two questions* and figure out the rest
from there without any more dialog boxes. If it guesses something wrong,
I should be able to fix it from the project pane.
*I'll leave it as an exercise to the reader to guess which two questions
it should ask.
Hmm, is it really sooo difficult to set up a project in IDEA ?
I don't think so. It usually does not take me more than about 5 Minutes, which is quite acceptable (single module project). The UI for project setup is - after lots of discussions - quite good.
In comparison with JBuilder and Eclipse, I find project setup in IDEA much easier and more comprehensible. CVS setup works more or less without hassle, whereas in Eclipse, I could not figure out, how to do it within one hour. Maybe I am spoiled by the easiness of IntelliJ.
The only problems I have, is to get branch merging working. The merge window shows always three identical versions of a file, despite a merge conflict exists. Don't know, maybe this is a serious bug in the cvs client implementation.
Best regards
Thomas Gülden
Munich, Germany
In article <c15548$lq1$1@is.intellij.net>,
"Thomas Singer (MoTJ)" <nomail@nodomain.com> wrote:
Now here I must disagree. Local mode can be very useful on a machine
that is not to have any open network ports. It is fast to set up, fast
to access, and it works pretty well. For cvs on my local machine, it is
quite effective for my personal projects not yet moved to corporate cvs.
I did transition to ssh, but having to create a passphrase-less key file
did not fill me with joy, nor did having to open port 22.
Scott
In article <40361382.1040505@no.spam.please.carp-technologies.nl>,
Bas Leijdekkers <leijdekkers@no.spam.please.carp-technologies.nl>
wrote:
I concur - I recently revved most of my projects to junit 381, and they
are working just fine. I usually have both ant and IDEA working on my
projects, as it is easier to get metrics and code coverage testing with
an ant buildfile, but IDEA is a better environment to generate code and
unit tests in.
Scott
In article <32048697.1077305274217.JavaMail.itn@is.intellij.net>,
Thomas G?lden <no_mail@jetbrains.com> wrote:
5 minutes is a lot if:
- you're just evaluating IDEA
- you have to keep re-creating your projects due to problems in the EAP
(this might be considered the price of participating in the EAP though)
- you want to browse a project you're not working on so you want to
quickly set up a project
- you want to create a quick project to test a few things out (though
for this one, you can usually use IDEA's defaults and it is pretty quick)
- you're temporarily working on a machine you've never worked on before
and you forgot to copy your project to the network
Erik Hanson wrote:
>>Hmm, is it really sooo difficult to set up a project in IDEA ?
>>
>>I don't think so. It usually does not take me more than about 5 Minutes,
>>which is quite acceptable (single module project).
5 minutes is not enough for anything, sorry. Try to setup something in
Eclipse in 5 minutes... fat chance.
R
The five minute estimate is far too long. I just downloaded a project here from our CVS tree, and had a working single-module, plain-Java IDEA project in sixty seconds. The only thing that wasn't automated was setting the libraries (searching the project directory for zips and jars and asking if you want them included as libraries would be nice). Other than that, I just chose the defaults in the project setup wizard, and it worked. Will a web or EJB project be more difficult? Yes of course it will. There's simply a lot more to configure on such projects. I'm frankly not sure just how project setup could be made any easier.
--Dave
I just really have to agree with the confusing project configuration, the
content roots, the source paths, and all that. The concepts are poorly
explained to begin with, and the dialog design is just down-right confusing
on top of everything. I mentioned this several times during the EAP, but
never really got any real response that anyone thought it was a problem. I
seriously think it is.
"Robert Tuck" <no_mail@jetbrains.com> wrote in message
news:22380263.1077280447067.JavaMail.itn@is.intellij.net...
thought it's the greatest desktop Java app ever written, and up til now, the
most innovative and amazing IDE ever written. (And I've used a lot of IDEs
over the past 20 years.)
>
that the transition to 4.0 is uncharacteristically rocky, and I'm afraid
this may really hurt IDEA's future.
>
4.0, however is taking MANY HOURS (see below). My fear? the poor
experience of moving to 4.0 is going to drive a lot of users to try Eclipse,
which I assume is the main competition. Purely as a business decision, the
time & aggravation spent moving to 4.0 makes it worth my while to go see if
Eclipse has improved since I gave up on it a year or so ago as not being
"ready."
>
stripes, and then the Eclipse steamroller shows up and basically copies all
the innovative IDEA features. If there's justice in the world, someone
should buy Intellij for a billion dollars and make them rich, before Eclipse
takes over the world.
>
get carried over (I've seen other posts saying the same thing.) Things like
code styles, color schemes, etc. This is huge, since there are so many
settings to keep track of, the last thing I want to do is go through all the
settings pages and try to remember what my "normal" settings are, and which
ones were carried over and which ones weren't. This isn't major, but it
sure is aggravating.
>
project configurations, but what percentage of cases use it? We already lay
out our own modules, one project-per-ANT file, with no "embedded" modules.
The poor documentation makes it very confusing to figure out what this
feature really does. Content Roots? Source Path designations? The biggest
barrier to using any IDE is figuring out what is needed to configure a
project, and IDEA just got a lot more complicated. Worse, it can be
dangerous - as I found out the hard way, if you deselect the "Source" folder
designation in the very confusingly designed Path / Content Root dialog,
everything seems to work the same way except major menu items are disabled
(like "Reformat Code") with no way of knowing why! Ok, perhaps this just
proves my stupidity, but it took me a long time to figure out why all these
features were disabled. My stupidity didn't get in the way when moving to
3.0.
>
plan. Maybe there are only a few of us, so Intellij could afford to just
drop us. There are a lot of "gotchas" setting up CVSNT, and certainly a lot
of time involved that I wasn't expecting to have to spend, since all of a
sudden you're dealing with (Windows) networks, permissions, etc. Worse, I
see that I wasn't the only one that ran into the problem that IDEA would
connect properly to the CVSNT server ("test connection" would work, and
"check out", etc.), but when you'd do more significant commands, you'd get
"invalid root" errors, with no explanation. Most of my time has been spent
resolving the CVS issue.
>
local-mode CVS support. Many directories that I had previously
moved/deleted (and committed) have all re-appeared, so I'm having to go
"fix" all my projects. Ugh.
>
tests to make sure I had everything right, and bang, an exception: "can't
find class junit/textui/ResultPrinter". Huh? No other explanation? Where
the hell did that class come from? How could they release a product that
breaks everyone's tests? (Or at least, everyone who has been using a
standard Junit library.) Now I have to use a custom IDEA Junit library?
Whose brilliant idea was it to put a custom IDEA class in the standard
"junit/textui" package? Sheesh! At least call it "junit/intellij" or
something so I know where this is coming from.
>
sucks. It screws up my ANT files (or makes my ANT files different from my
IDE configuration), and doesn't let me upgrade to use standard Junit
releases (with the corresponding API documentation, etc.). Just how did
Intellij expect me to figure this out, other than searching this forum? Do
they really think it's acceptable to be so intrusive in our configuration?
>
idiot, but please remember how much I've loved IDEA in the past. These
problems just seem so uncharacteristic for Intellij. I'm really regretful
that they've released a product with such a horrible initial experience, not
just because they're wasting many valuable hours of mine, but I think it's
really going to hurt them economically. IDEA's loss is Eclipse's gain.
>
>The UI for project setup is - after lots of discussions - quite good.
A UI that takes lots of discussion to figure out is by definition NOT good.
The project setup dialog is very difficult to figure out. If I have an
existing project I want to use IDEA to work on, it's usually a good 10
minutes or more of frustration and trial and error to figure out how to get
IDEA to recognize all the classes, the tests, the sources, etc. It's a
pain, and it's completely unintuitive compared to 3.0, imho.
Something that has been confusing to several people trying out IDEA 4
for the first time is how explicit compilation works related to issue
#27876. The new way that explicit compilation works (CtrlShiftF9) is
causing confusion and pain when you set up a new project then start
trying to compile files or directories individually. I know that once
you grasp the metaphor, things become reasonable, but the metaphor is
Java counterintuitive and a problem for new folks. I think something
ought to be done to make this special compilation behavior more obvious
to somebody new as I have just suggested on the closed bug.
See: http://www.intellij.net/tracker/idea/viewSCR?publicId=27876
Thanks,
Jon
Well, five minutes included a fair amount of tolerance. It usually is a lot quicker. Also between different builds of the EAP most of the time projects were taken over smoothly and settings like code style were preserved all the time (well except maybe in three builds, where there was a problem). Given that many builds during the EAP, I think the IntelliJ developers did quite a good job on this issue.
Project setup time surely increases with the degree of complexity in a project. However, in most other IDEs setting up a project takes much longer for easy projects, because the process is much less comprehensible there.
And project setup is a task, many do not do so often. So spending 5 Minutes on this, is not really unaffordable.
Thomas
Munich, Germany
Hi Scott,
You are right for single person usage of CVS. But how often this
happens? And, how would you compare the benefits (little bit easier
setup) compared to the effort to implement a full CVS server (which
would be needed for the local mode)?
Tom
It seems to me this metaphor is exactly the same as if you called javac from the command line with the single source file as a parameter. How is the IDEA implementation counter-intuitive?
If you changed the current behavior, THAT would be counter-intuitive.
Not true! That's the whole point: javac with or without the -d option
determines all dependencies and will compile any classes on which the
specific source is dependent if that class is absent or changed.
Rob Ross wrote:
Huh? What are you talking about? -d is a flag for "directories", and has nothing to do with dependencies. Javac only compiles the files you explicitly tell it to, it doesn't deal with any dependancies. That's why there are build systems, like make or ant to take care of this for you.
It is the case that javac does take into account dependencies. You need
to stop arguing and try it yourself.
Friendly,
Jon
Rob Ross wrote:
Almost all the responses here missed the point.
An experienced developer who loves IDEA had a lot of trouble with the upgrade to 4.0. This indeed is a bad thing for IDEA and I hope somebody from IntelliJ product management wakes up and understands this.
Joey
In article <c17t1o$2qu$1@is.intellij.net>,
Thomas Singer <idea@NOregnisSpam.de> wrote:
Hi, Thomas,
I have used cvs to store local projects for the last four years. Local
history might someday become a replacement, but my word processor does
not have it, nor does my usual XML editor. Until they do (or operating
systems start to store revisions like VMS did in the 80s), local history
only helps me save my Java code. Cvs saves everything I care to check
in.
As far as the comparative effort - I know a lot of people here who use
local cvs until they are ready to release a project for others to see.
Some, like me, will set up ssh-accessed cvs. Others will choose a tool
that does not force them to dink around. I suspect that the "little bit
easier setup" and "smaller security risk" would be worth it to people
like me. I do not know how many of us there are.
To bring this back to the original focus: if a developer used this
feature in 3, or in Eclipse, or in XCode, or in BBEdit, and then tries
4.0, they either burn cycles needlessly to change how their archive
works, or they use a tool other than IDEA 4.0. JetBrains gets to make
the call about how much time these customers are worth, but they should
be aware that dropping local cvs does frustrate some users.
Scott
I agree with parts of this:
1. I wish the wizard would ask you to search for .jar/.zip files which are located underneath your content root
2. For that matter, why can't you just tell it *.jar, or *.zip, and have it compute the jar list for every compile? That would be nice
3. The Paths configuration screen is entirely confusing. For one, it took several tries to add a new Library to it. More importantly, why is a little circular icon there for removing a source directory. Especially with NO CONFIRMATION dialog? Should it be at least a red X or something that indicates to you it's going to remove something? And the right hand side of that dialog is total confusing as well. Good luck explaning to the visually impaired how to tell which directories are source paths, excluded, etc....
I also agree. The new 4.0 project is a major improvement in terms of
functionality of project layout but was a real pain to set up - and I
count myself as an experienced IDEA user (been using it since the "renamer"
days!).
My really big gripe (I have smaller ones :)) is that in 3.0 you could easily
declare multiple source paths, compiling to multiple output directories with
multiple classpath entries. This was quick and easy to set up - but of
course had the distinct disadvantage that module dependencies weren't
actually expressed (it was easy to break the command line build!).
However in 4.0 - and I simply can't understand why they did this - a module
can only refer to two source directories (source and test). Why only two?
Why not just multiple? That way you could easily continue setting up
projects as you did in 3.0 (and automatic 3.0 project conversion would be
much simpler) until you required the additional 4.0 multiple-module
complexity.
In addition why, when you declare a module's dependencies doesn't it also
"inherit" the library/classpath entries. Surely by default if module B
depends on module A it will also depend on module A's libraries. Maybe there
are cases where this isn't the case but the default should definitely
include the libraries. This caused me much grief and additional set up. I
now have 14 modules and 14 completely separate project libraries (one per
module) with mirrored module and project library dependencies - this just
shouldn't be necessary!
All of this would definitely have put me off if I was evaluating IDEA. In
comparison Eclipse pretty much got the settings right first go with only
minor tweaking :(
Anyway - IDEA still rocks (in case you think the above is too negative!).
After a few hours of set up I've not had to touch the project. Now if only
they could get the split of project files right (it still doesn't work well
sharing project files!).
Cheers,
TicH
I agree entirely. As a long time open-source developer I use local CVS on my
machine at home to check in given "snapshots" and organise my development
much as I do at work. I really wouldn't want to have to set up a CVS server
which ran all the time and would much prefer to continue with local CVS. Oh
well - back to command-line tools and Araxis Merge ;)
Cheers,
TicH
Richard Kent wrote:
> I really wouldn't want to have to set up a CVS server
> which ran all the time and would much prefer to continue with
local CVS.
> Oh well - back to command-line tools and Araxis Merge ;)
On Windows, installing CVS NT would take you 15 minutes, only ONCE.
Download, print the howto, install as detailled in the how-to, and you
have your "local"-ly running CVS server. Next time you reboot, it will
still be there, as a service.
15 minutes, or
0 minutes :
open a sourceforge account: with IDEA's embedded ssh, it's a no-brainer.
15 minutes: the time it takes you to read/write/sent a dozen messages.
Alain
Does Eclipse supports local CVS mode? This would be very new.
Tom
And if you have a personal firewall running (and you definitely should
have one running!), then there is no security problem any more.
Tom
A module can have any number of source paths - just set them up as separate content roots. You can only have one output path though - but I've never understood why you should need more than one.
In general I'd say a module should never inherit another modules dependencies. The module should be a black box with well defined interfaces between other modules. It shouldn't matter what libraries a module has - isn't that implementation details? Sure there may be libraries all modules need (logging?) which should be set up as project libraries.
The little circular icon is actually a minus button - but it's too small to really see that.
I added a feature request for idiomatic classpath discovery but the idea seems to go against the grain of the new per-module/per-project/global libraries. I never use these and I suspect most others don't either...
http://www.intellij.net/forums/thread.jsp?forum=15&thread=75322
Thomas Singer (MoTJ) wrote:
>> To bring this back to the original focus: if a developer used this
>> feature in 3, or in Eclipse, or in XCode, or in BBEdit, and then tries
To answer this... Snould an existing feature be yanked? Generally not.
Is there reasons to yank features? Always. Should local have been
removed? At the advantage of having a much smoother CVS Implementation,
and the low cost of installing a CVSNT server locally, yes.
Keeping features which are hard to maintain in a product, when there is
a much better solution in the first place, is a sign of bad engineering.
I'm glad JetBrains can make those tough decisions, because they do
cause criticism. In the long run, it's better for the product. The
product hasn't lost anything, it's gained very good CVS integration
which will grow, and really didn't lose anything.
Not in M7 it doesn't.