New IntelliJ Project View Experiences?

Hello all,

I already have another thread running on this forum about it, plus 1 or 2 Jira issues, but I was wondering why not more people are complaining about the new project view. How do you work on multiple modules and their dependencies? Why would anyone prefer a list of ALL dependencies of ALL modules loaded in IntelliJ, compared to the IntelliJ 8 dependency-per-module view? I know now that you can also see the depenencies by Pressing ALT+F1, select the project structure, go to the dependency tab, and go through that list on item at a time, since it's ordered by randomness, instead of, say, alphabetically? And if you then want to see if that class you're looking for is really in that library (I didn't know if I was using Junit 4.5 or 4.7 yesterday, which caused some problems for me...), you'll have to close that window, go to the external libraries list (I have around 200-300 libraries there...really manageable, even though they are nicely bound to some modules (at least, in IntelliJ 8) , and then I have to click the library open, find the classes I'm looking for, and then go back to the module I was actually working on. If I can still remember which one that was after going around my IDE in such a way. The philosophy behind this change is that some users complained (in 2005!!) that they didn't understand where their files went, and that therefore the project view should reflect the file structure. (and external libraries, apparently???).

I don't know if any of you uses Eclipse, but in Eclipse, you can choose between a Resource view (sort of IntelliJ 9 project view) and a Project View (a sort of IntelliJ 8 project view, but less powerful since it lacks modules/groups). In IntelliJ 9, we'll get the the Eclipse Resource view. My question: do you really want that?? "Nobody" in the Eclipse world even uses the Resource view!

In IntelliJ 8, you (could...) see the dependencies of the module in the project view. They are tightly coupled to the module they belong to, and the modules are nicely organized in groups. You cannot be mistaken in which dependency belongs to which module, since it's reflected in the Project View. Also, the list (per module) is around 15-20 dependencies long. This can be easily handled by anyone, since the list is so short. However, when you have around 30 modules (which I have, but usually more, 6 projects, each 4-6 modules) open at the same time, this list can grow to more than 500 dependencies in IntelliJ 9 (around 200-300 in my case because I often depend on the same dependencies).

A question to Jetbrains: if you really want to make this change you intend (or already have done), wouldn't it be better to just allow an extra 'view as' option? For example, a 'View as Filesystem', and a 'View as Project Structure' way? I guess that would already solve most, if not all, of my pains......

Thanks for reading this rant, but it's been keeping me busy for the last couple of days ;-)

Erik

PS: I've attached some screenshots again, to show the difference between IntelliJ 8 and IntelliJ 9....

PS2: You can track this issue here now: http://youtrack.jetbrains.net/issue/IDEA-53408



Attachment(s):
Screen shot 2009-11-09 at 10.36.11.png
IntelliJ 8.png
140 comments

Hello Erik,

I still don't know why JetBrains either:
1) bring back the old project view + use the current project view as a
'resource view' or something


Because adding an option is the worst possible solution to any UI design
problem.

or
2) bring back the old project view and don't hide the files which
you'd expect


Because every file must be displayed in just one place in the project view.

or
3) bring back the old project view and ask if those issues from the
year 2005 are still relevant.


Because nothing changed in this respect since 2005, and the issues are as
relevant as they were.

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0

You're right, having tried it (I never really used this much) it seems pretty useless. I asked my co-workers, they said they use it generally when there's only a single copy of the library as a form of cheap navigation, which doesn't seem like a use case worth saving.

BTW Alt-F7 doesn't work for me on a library in the project view - should that work in IDEA 8?

Cheers,
Colin

0

Hello Colin,

BTW Alt-F7 doesn't work for me on a library in the project view -
should that work in IDEA 8?


It works not in the Project view, but in the Project Structure dialog. I
guess we could make this work in the Project view as well, but it's not supposed
to work right now.

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0

We actually already have a feature which is much better suited for this task,
and the feature is Analyze Module Dependencies. Currently it doesn't show
libraries, but it's something that can easily be added. Other than that,
it's a nice fit - it's non-modal, and you can open several tabs for different
modules and switch between them easily.


Nice, I actually wasn't aware of Analyze Module Dependencies (or at least, that you could use it for individual modules, I've used it once or twice project-wide). I think the main thing it wouldn't allow you to do is see the libraries used by two modules at the same time for comparison, I'm not sure how much of a problem that would be.

Should we bother implementing that, or will "bring the things back as they

were" will still be the only answer we'll get?


I don't think it's true that that is the only answer you've had. This thread has been more heated than it should be from time to time, but changing the project view is a major change to one of the most-used parts of IDEA, and particularly removing (or drastically changing) functionality that people rely on is always going to be controversial. My main gripe (module groups) has been fixed so I'm happy, but that would have been almost enough to prevent my company upgrading to IDEA 9 - it would have made our project unmanageable (whether our reasons are good or bad is another argument, but it's not something I can change).

I think particularly it hasn't been well explained why the library change is necessary - it seems like it's essentially because of several implementation details (modules no longer have a node representing them uniquely in the content tree, and that the Maven integration adds libraries to the project rather than the module) rather than it not conceptually making sense to show them there. We always add our Ivy dependencies to the module, so for us it makes sense to have them in the project view associated with a module and that's how I think of them being located.

Either way, the EAP process is here for to you to gain feedback and for us to provide it, and I think sometimes "it worked better for me before" is totally valid feedback. Like I say, what is in there works for me now but it's not an improvement, for me at least.

Cheers,
Colin

0

>Sorry, I don't quite understand this use case. At least in our projects,
>a library is typically used in multiple modules.

Same here.

>Pressing Alt-F1 in IDEA
>8 brings you to one of the modules using the library, chosen essentially
>randomly. In IDEA 9, there's no random choice - you get to where the jar
>file locates on disk, with no ambiguity.

Why would I want to press Alt-F1 when my module already (used to) show me my modules. How does the Alt-F1 dialog allow me to see the classes in the dependency? How can I compare dependencies between projects?

>If you need to find out which modules use the library, you can do this in
>the same way in both IDEA 8 and 9.

I don't want to do that, eg I usually don't care much who uses JUnit 4.5 or 4.6. I do care, however, from a different point: I care what dependencies my module uses, not the other way around, which, in effect, might be the same, but that's usually not the use case I have. The most import thing I worry about is that people don't add the wrong dependencies to projects, and I usually do that by checking the dependencies of a module. It has happened before that our modules depend on dependencies that they should not use, like the UI depending on JPA or something.

Erik

0

> Should we bother implementing that, or will "bring the things back as they
>were" will still be the only answer we'll get?

This answer is getting a bit annoying, but also typical, for the discussion in this thread. I can't see why you are giving us such a hard time in this. I really do think that "bring it back" is the best solution here, but I think there are enough use cases here which support the old view compared to the new one/ Not impolitely meant, but maybe you could put a little more effort in understanding those needs?

Erik

0

>>I still don't know why JetBrains either:
>>1) bring back the old project view + use the current project view as a
>>'resource view' or something

>Because adding an option is the worst possible solution to any UI design problem.

Well, IntelliJ has a lot of options already, right? But without kidding, what do you mean with 'adding an option'? You already have a strange 'commander', a Grails view, a package view, a structure view, some JEE view, so why not add a resource view for files and folders (and not dependencies) and let the project view reflect the project and it's dependencies?

>> 2) bring back the old project view and don't hide the files which you'd expect

>Because every file must be displayed in just one place in the project view.

Ok, that makes sense. I'm also beginning to understand the confusion a little, why people would be confused that their libraries are missing from their projects or something. I use Maven, so I'm used to working with a directory with lib files, etc, or have them part of my directory structure. So, for me, it only makes sense that they are not dispayed in folder, but are part of the MODULE, just like in Maven. The dependencies in Maven are configured per module, not per project. That would be weird, and that's why it probably feels so weird to have this change, which is really not suitable for us.

0

When I try this, I have to press Alt+F1, choos option 7, go to the dependency tab, search through the list of unsorted dependencies, and then navigate doesn't bring me to the source, but to the project libraries, while show usages shows me that library javax.transaction.jta is indeed used in my module, plus in some other module. Then I press ESC to close the dialog, and I have to use the mouse, since the keyboard navigation stopped working after that (until I select something again).

It's hard not being sarcastic, but I really can't see how this is easier than just opening the project view, which is always open, and just open the libraries. The second option seems much easier than the alternative, which doesn't even have the same functionality (being a) ordered, b) having source attached to it c) being able to compare project dependencies. Just my 2 cents.

0

Hello Dmtry,

At least in our projects, a library is typically used in multiple modules.

That's simply not the case for us. Our libraries are kept separate. Why, for example, should JGoodies Forms be included any module other than the UI module. And even then, only within the Swing sub-module and not the Web app sub-module. When I build the data conversion module, to be used in other projects or as a standalone component, I certainly do not want a bunch of extraneous UI jar files included. Especially since the data conversion is server side and the UI is client side. In turn, why should the UI module have Xerces & Xalan in it when it does not do any XML work? That's handled by the data conversion module. These modules need to stay self contained so they can be used in other applications (i.e. projects) with minimal dependency needs. The easiest analogy I can think of is it would be like asking why doesn't Apache commons keep all the dependencies for all commons projects in a single place.

Pressing Alt-F1... In IDEA 9, there's no random choice - you get to where the jar file locates on disk, with no ambiguity.

The assumption there is that the jar exists within the project's file structure.  In our case, there would be nothing but ambiguity since the jar is in either a global lib directory or a repository. This can be the case for Maven, Ivy, Ant, and IDE configured projects. We do not, and basically are not allowed to, keep dependencies in source control. I know this policy is not uncommon within other organizations. Therefore putting them within the project's structure is not possible. Even if it was, I do not know as I would organize my project in such a way. Even so, in the end, it is not always my choice. At my company, you work with a different group of people from project to project. Sometimes you are a lead, other times a minion. For most new projects I am involved with, I push for using Maven. This alleviates some of the problems. But in the end, I am sometimes at the mercy of the team or person that set up a project; especially when dealing with legacy projects. In some cases you take over a prototype or proof or concept done by someone else where "get it out fast" was the driver, not maintainability. Finally, dependency management and project organizational skills, philosophies and ideologies differ greatly among people. On some projects I need to use IDEA to impose structure on an otherwise chaotically "organized" project. Once I have that structure imposed, I depend on IDEA to help me understand that structure. Alt+F1 was a consistent and quick way for me to see what module a dependency was defined in.

If you need to find out which modules use the library, you can do this in the same way in both IDEA 8 and 9. Press Select In | Project Structure, then press Alt-F7 on the library node to see the list of modules using it. Again, there is no ambiguity.

That's a valid point. In some cases this will provide a level of precision, i.e. lack of ambiguity, that is useful. So this could be used in place of Alt+F1 in some cases. But I do not believe, IMHO, it resolves the other situations where you want a simple graphical tree view of your project's structure.


Thanks & Best Regards,
Mark

0

I would love to see libraries added to the Dependency Viewer. I have frequently found the dependency viewer to not be very useful in situations where I am concerned with Libraries and not packages (or classes). There's basically too much detail and you can not see the forest for the tress. Having a Libraries view would be awesome. It wold be useful in many situations.

Should we bother implementing that, or will "bring the things back as they were" will still be the only answer we'll get?

I'm not sure if this question was directed at me, or to the group as a whole. In the case of the former, I apologize if I some how gave you the impression that I was not open or agreeable to a discussion of alternative solutions. Or that somehow I implied that I would only be satisfied by bringing back the old version. That was in no way my intent. I would have hoped my offering some alternative solutions, such as the alternative view in "View As", would have demonstrated that. I know some of the discussion in this thread has gotten a bit emotional at times. However, I do not believe I personally have in any way contributed to that unfortunate occurrence. In the end, my only goal is to assist JetBrains in continuing to make IDEA the best IDE there is.

0

Wow - impressive thread. I didn't follow it all.

However I would like to give some heads up for the new project view.
Our projects are quite different however: Only 1 to 3 modules, no maven.

In the old view it was very confusing to not see the library jars at the
actual location in the file system.

Also some content roots are nested inside another content root. That is also
handled much better now.

Dmitry Jemerov wrote:

Hello Mark,

>> I would agree with Colin's main point. While the new solution does
>> provide (some) module grouping of dependencies, the solution is not
>> very intuitive or user friendly. The primary use case where it fails
>> is that of simple module dependency comparisons. This is not
>> necessarily something you do 8 hours a day. But it is something you
>> might do a couple of times a day depending on where you are in a
>> project's life cycle. And when you need to fo it, it needs to be
>> simply and intuitive so as to not derail your train of thought.


We actually already have a feature which is much better suited for this
task, and the feature is Analyze Module Dependencies. Currently it
doesn't show libraries, but it's something that can easily be added.
Other than that, it's a nice fit - it's non-modal, and you can open
several tabs for different modules and switch between them easily.

Should we bother implementing that, or will "bring the things back as
they were" will still be the only answer we'll get?

0

Hi Stephen,

Great, thanks, it's good to hear some feedback from people who prefer the new view and why. So your library jars are actually contained within the module content root? I can see how it would be confusing not to see them there in that case. In our case, our jars are in the Ivy cache so they're completely outside the project. The whole nested content root thing is also something I hadn't considered, I didn't even know that was possible.

Cheers,
Colin

0

As I imagine it, your project structure more resembles the directory structure with libraries in a lib directory or something, right? And I imagine the nested roots are also nested directories? If so, that still (to me) more sounds like a resource view than a project view. I use Maven, so just like Colin, the libraries are outside my project (somewhere in my home directory in a hidden .m2 directory), and I expect them to be attached to the module (since they are module dependencies), and I do not expect the see the libraries at their location on the file system.

PS: I'm glad you like it, and I wish I could share your opinion about this change. For us, however, it's still a blocking issue.

0

Perhaps (probably) I'm being stupid here, but I've installed IU-92.65, and the Structure view still shows the structure of the file being edited - how do I get it to display the module dependencies?

0

You probably have your structure view floating. This is known problem http://youtrack.jetbrains.net/issue/IDEADEV-41796.

0

While that may be the issue Dave is referring to the way I interpreted it is that the only time you can see module dependencies in the structure view is when the module is selected in the project view.  The moment you edit a file the structure view changes to the structure view of the file.

In other words, using the structure view solution it is not possible to view the module dependencies when editing a file.  It is also not possible to see the module dependencies of more than one module at a time.

0

So I have to Close All Editors in order to see the module dependencies? and this is supposed to make life easier?

0

Nope, you have to select module node in project view.

0

Maxim, do you consider the current implementation user friendly?

0

Well after some experimentation, I've found that the Structure View doesn't change if I select the module node itself, but it does change to show the library dependencies if I select any source root below the module node.

OK, that's a bit strange, but it does the job.

Thanks Maxim, that's what I need.

0

That's weird. Can I please have a screenshot? What build you're using BTW?

0

I've been using IU 92.65, but because it keeps falling over with core errors and now the menus are messed up because I removed the CVS options from the Version Control menu (see my other bug report thread), I've decided to try IU-92.81.

If the Structure View does the same in the latest version, I'll post a screenshot.

0

I find it to be a bit awkward because the nature of the structure view is to show the structure of what currently has focus.  For example I click on a module and I see its library dependencies - great.  Then, say, I navigate into one of the dependencies and open up a source file from one of them.  Bam - my stucture view now changes to the structure of the newly opened file and I would have to go back into the project view and select my module again in order to view the library list.  And then the libraries tree is now collapsed again.

Once the file is opened I can Alt-F1 | Project View and start navigating the dependency jar from there (in the External Libraries) but again it's just awkward and doesn't really follow my train of thought.

That being said I may be able to get used to it.  One possible improvement:  Would it be possible in the structure view under "Module Dependencies" to show the library dependencies of those modules rather than the file structure?  That would at least make it possible to view more than one dependency list at a time.

0

OK, after I installed IU-92.81, when it tried to open my existing project, it complained that there were lots of project variables undefined, and displayed a dialog full of what looked like script fragments that it thought were project variable names. I closed the project and restored the project files from a monthly backup, but the same thing happened again when I opened it.

So I assumed the project was corrupted, and recreated it from scratch (nice job on automatically recognising modules, libraries, and dependencies, btw). After all that, the new project displays module dependencies when the module node is selected in the project view, as expected.

Personally, I like this new dependency view - although my personal choice would be to have a separate view for the dependencies alongside the structure view. But I can happily live with them combined in a single view.

Thanks for listening

Of course, no sooner have I installed IU-92.81 then you guys churn out another release - I'm having trouble keeping up here!

0

I also installed 92.81, but well, what's the improvement here? The dependencies are still only visible when selecting the name of the module (which I never do), and are only visible in the structure view, which takes up space, and which I therefore never use.

Also, navigating to the source of a dependency sets the focus of the structure view as well as the project view to the same dependency, which makes navigating to a different module extra hard. But I won't spend my time anymore on feedback, I've done that enough I think, and I have better things to do. So I'll either stick to IntelliJ 8 or try to switch to SpringSource Tool Suite (http://www.springsource.com/products/sts), which also looks quite promising (Integration with Groovy/Grails, Spring, Maven, JPA/Hibernate, etc).

This has been the most disappointing features in the 5 years I've been using IntelliJ for an otherwise great IDE!

0

Hi all,

I just wanted to say that I'm quite disappointed in this whole process. I hoped the project structure would be fixed, but it seems to got even worse. There seems to be no way anymore to easily view the module dependencies. Even the Alt+F1 + 9 (Project Structure) doesn't show the module dependencies anymore, but the project dependencies. Seeing the module dependencies requires you to do : Alt+F1 + 9 + go to module + go to dependencies tab + go through the list. If you close the window, you'll have to redo the described steps again. I've used IntelliJ for more than 5 years, and I absolutely loved it, which makes this change even harder for me to accept. I still don't understand why this was implemented in such a (bad) way, and why there's not a good alternative for removing the module dependency overview. Even the Analyze -> Module Dependencies doesn't allow me to easily compare module dependencies like IntelliJ 8 could. I'd love to give you money for a new release, just like I did for number 7. However, until this has been resolved, I'll use IntelliJ 8 / STS.

Erik

0

Just wanted to let you know that today, I could fix a bug in our dependency management because the project view (in IntelliJ 8) showed the dependencies, and the dependencies of one module were different from the other module. This was spotted by IntelliJ 8 and was reflected in the project structure. In IntelliJ 9, I would never have found it, since both dependencies/libraries would have been in the huge list of all dependencies.

0

Erik,

As I think you could make very good use of Dependency Rules feature (http://blogs.jetbrains.com/idea/2006/04/analyzing-code-dependencies-part-ii/).
You can restrict you dependency graph whatever you like and it will be not necessary to constantly check your dependencies "by hands".

Thanks,
Anton Makeev

0

Please sign in to leave a comment.