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

Anton, thanks for the feedback. I think we have a misunderstanding in our language.

This is how I work:

I work on different projects (let's say petstore, bookstore and computerstore, and a store-util). These project are all open in the same IDE instance, so I have IntelliJ open only once. All these projects consists of multiple (maven) modules. For example: I have a petstore-dao, petstore-domain and petstore-ui module. All shops can be released and developed independantly, but it's easy to open them all in the same IDE, so that you can easily refactor them, and put commons functionality in the 'store-util' project (which is also split in e.g. store-util-xml, store-util-ui, store-util-dao) All these modules have their own dependencies. For example, the petstore-ui depends on Wicket 3, while the computerstore-ui depends on Wicket 4, and the bookstore also on Wicket 4). Some of my collegues wanted to bypass the dao layer, and decided to add hibernate to the UI layer. In IntelliJ 9, I cannot see in the project view that someone added a dependency for hibernate on the UI. I will also not go to the Alt+7 project view, since, well, why should I? I have no business there, since I manage my dependecies through use of the POM, and Maven takes over the rest. Since this library is now added to the long list of external dependencies, there's no way for me to see that someone made that change. In IntelliJ 8, however, since the dependencies are per module, I only need to collapse the dependencies, which happens a lot automatically when going into the source of dependencies, I often see the rest of the dependencies, and see that something is wrong. This is therefore quite important to me, since it impacts the design of the software.

So, these maven libraries are certainly NOT project libraries. They are not shared accross modules, unless these modules depend on each other (and the petstore doesn't depend on the bookstore, it depends on some of the store-util modules. Eg, the petstore-ui could depend on store-util-ui, but not on store-util-dao).

>> You wrote
>> If I have 2 times version 4.5, and two times version 4.6, They will end up two times in the external dependencies, but I have no idea which modules uses which library.

>That is not the case, since Maven libraries are configured as project libraries and shared across modules. If you have dependencies on junit 4.0 from several modules, you'll see only one library in the External Libraries.
>What you are describing are two use cases.

This is not true. If I have a class (say HomePage.java), I cannot use the Hibernate classes. These hibernate classes are not a project library, they are connected to a module. But maybe a module for me is a project for you, I'm not sure.

>First, you need to see that are the dependencies of a particular module, and, as Maxim suggest, you could see them in the Structure View.

Well, like I said above, I never visit the structure view, nor did I ever needed to do that, since Maven manages all my projects. I don't see the point why I should go there.

>Second, you want too see, for instance, where some class is located and that are its neighbours; you can use good old Select In Project View - the library in the External Libraries will be selected and expanded, showing the content.

Then I have to use two dialogs: first use the Structure View (which I don't use), and close the screen to see the external libraries.

>These are really separate tasks and probably it will be easy to get used to and convenient to use  Structure View for list dependeices and External Libraries ro browse classes in a library.
>What do you think?

I think that I need to show you how my dependencies work, and how I develop. Is it possible to chat about this? In a last attempt, I've created a screencast. Can I upload it somewhere?

0

Moshe,

I didn't say 'project dependencies', it was 'Project Libraries' that is an IDEA's term.
All maven dependencies are configured as Project LIbraries to allow them to be configured in one place.

0

I think the confusion comes from 'shared between modules'. Cause in my experience, they are not shared. At least, you cannot use dependencies in a module if they are declared by another module. So I don't know what the concept of 'sharing' means in your terminology. For me, 'shared' means 'other modules depend on the library. And that's not the case. But this (visual) separation of modules is lost in IntelliJ 9.

0

I think the confusion comes from 'shared between modules'. Cause in my experience, they are not shared. At least, you cannot use dependencies in a module if they are declared by another module. So I don't know what the concept of 'sharing' means in your terminology. For me, 'shared' means 'other modules depend on the library. And that's not the case. But this (visual) separation of module dependencies is lost in IntelliJ 9.

0

> Indeed, the only response I hear is "get it back where it was" stuff. But it isn't very productive in finding the way out and coming up with an instrument everyone will find useful, clear and consistent.

I think everyone agrees that everyone find the IntelliJ 8 solution good, great and perfect. Why did you change it?

0

>>That is not the case, since Maven libraries are configured as project libraries and shared across modules. If you have dependencies on junit 4.0 from several modules, you'll see only one library in the External Libraries.
>>What you are describing are two use cases.

>This is not true. If I have a class (say HomePage.java), I cannot use the Hibernate classes. These hibernate classes are not a project library, they are connected to a module. But maybe a module for me is a project for you, I'm not sure.

Please read about types of libraries in IDEA so that we could use and understand the same terminology (hope that doesn't sound offensive 8):
http://www.jetbrains.com/idea/webhelp/libraries.html


> I think that I need to show you how my dependencies work, and how I develop. Is it possible to chat about this? In a last attempt, I've created a screencast. Can I upload it somewhere?

Yep, mail me at Anton(dot)Makeev(at)jetbrains(dot)com.
Actually I understand you and the problem. The point is that there are aspects of InteliJ and project possible configuration because of that we haven't come up a straightforward solution yet.

0

Hi Maxim,

I must admit I've not used v9 enough to be able to judge this (I use it at home, but always on much smaller projects, and often not in Java). Could you display modules as tree nodes (with groups), and when the modules are expanded show the directories representing content roots, source folders etc under that, as well as the libraries used by that module? It seems like the main confusion for people from the YouTrack JIRAs was that not all folders were displayed in this view, maybe this would help?

Cheers,
Colin

0

Colin,

Is that true all of your module's content roots don't dominate each other? I.e. none of the content roots physically, in a file system sense, contains another?

0

Hi Anton,

It would also be useful to hear a well-formulated description of that motivated these changes from Jetbrains side.
The change in library presentation in the Project view is not just a simplification, it removes essential visual grouping (from library to module).

0

What about making this a choice (eg not allowing mixing)?

0

Hi Maxim,

In our case, that's true - I actually didn't think IntelliJ even allowed that.

Cheers,
Colin

0

Agreed. I'd make the same argument about the module groups, too - it removes what is for us a vital project organisation tool. I'd be interested in hearing more about the reasons for the change too.

Cheers,
Colin

0

Well, what we've been doing is optimizing very different case, very modules nest each other (IDEA project itself is configured that way, there's only one top level umbrella module). Old project view used to exclude nested module's content root and move it to the top level. These leads to very unpleasant experience walking through the file structure where can't find certain directory, while you're absolutely sure it must be there.

Anyway, in nearest EAP a compromise structure for project view is implemented: top level modules are shown at top level or grouped into module groups if there are any but nothing is excluded from their contents and nested modules appear inside parent's module file structure instead of top level.

Hope everyone will like it.

0

Hi Maxim,

That sounds great, for our use case at least. I'll give it a try when the next EAP is out. Thanks!

Cheers,
Colin

0

I can't really imagine how this will work at the moment, but I'll definitely try out the next EAP, and hope to provide some solid feedback then.

0

Good to see some progress on this issue.
Cheers,
N.

0

I just wanted to say that I really like the solution implemented in the latest build - IU-92.65. Hope this puts an end to this [ridiculous] heated discussion. Now everyone who can't live without seeing a permanent list of module-specific external libs in their project view can have a pleasure of viewing it all day long in the Structure pane that can be made visible and docked in the same column as the Project view. The content of the Structure pane shows the external library dependencies for the currently selected module in the Project view and changes dynamically as you select another module. Seems very logical and organized. Great job, Maxim! Thanks.

By the way, for the rest of us - those who actually spend more time working with their source files rather than gazing at the lists of jars - perhaps, at some point, it would be nice to be able to hide (via configuration) the global "External Libraries" and .iml files (or any type of non-source files) from the Project pane all together?

0

Hi constv,

Thanks for posting this, cause now I at least know there's a new EAP. I've tried it out (ofcourse, after hacking up the Info.plist again....), and you know what I think of it, I guess.

I was really, really, really looking forward to it, but once I ran IntelliJ, I thought I was running the old version. Now I see the solution....and...well, let's put it this way: I'll stick to IntelliJ 8. Or STS.

This implementation matches this discussion, I think, as constv nicely worded it: ridiculous.

How can I ever compare the modules now? I have to write down the dependencies of one module, and then go to the other module, and compare it by hand?
If I jump to the implementation of a class, I go the huge list of dependencies. Argh!!!
If I go through the list of dependencies per module, scroll down, switch to a different module, and go back, I have to scroll through the list again!
If I don't click on the name of a module, I don't see the dependencies!
If I go the implementation of a dependency of the module, but the 'external dependency' list as well as the 'structure view' show the dependency, and I have to navigate all the way back (with a mouse!! I though IntelliJ was keyboard friendly?????) to the modules! This makes comparing modules even harder!

I really hope some people are happy, cause for me, this doesn't solve anything, and makes IntelliJ as unusable as the other EAP's. IntelliJ team: I hope you give it a last chance to fix this.


Erik

Constv, how can you work professionally with software without looking at your dependencies? I hope you'lll spend a little more time on using and and see if the 'see it all day' is really true. I've used IntelliJ for an hour now, and yes, sometimes I see the module dependencies. Usually I don't. So thanks for the hard work, but a shame it's implemented like this.

0

Ha, I just started up IntelliJ 8 again, and it's amazing to feel what IntelliJ does to my mood compared to number 9. Incredible!

0

Colin, Dave, Nathan,

What do you think of the new solution? I've already posted that I don't like it (at all), since the dependencies are hard to make visible (they are only visible when selecting the module in the project view. How often would you do that??), they make navigation incredibly hard (when looking at the source of the dependency in the structure view, the project view also goes to the external libraries) and I can't compare module dependencies this way, since only the dependencies of one module are visible at the time, so I have to write the dependencies down or something.

Whay do you think?

0

I also tried the new EAP:

Moving the module to the top level is better for me, since I have few modules.

However the fact that dependencies are not yet like they were in version 8 still does not solve anything. I usually not use the structure view. I keep it closed so I have more space for the project view. If I move it to the right side, it competes with the maven screen on the same space.

I think the place for dependencies is on the project view. Since once you are on a source file, the view that can stay synchronize to your location is the project view. So it makes much more sense to have the dependencies on the same place. (if you see error for dependency on the current file, you can jump to the dependencies to see the cause)

Anywhere else the dependencies will be placed will be less user friendly. And I don't see why instead of doing the right thing you put the dependencies in maven and structure where it does not belong.

0

I think the place for dependencies is on the project view. Since once you are on a source file, the view that can stay synchronize to your location is the project view. So it makes much more sense to have the dependencies on the same place. (if you see error for dependency on the current file, you can jump to the dependencies to see the cause)

Anywhere else the dependencies will be placed will be less user friendly. And I don't see why instead of doing the right thing you put the dependencies in maven and structure where it does not belong.


+1, I totally agree on this. The project view is the perfect location for the dependencies (I guess that's the idea of a 'project' right?)

0

I've been pretty busy so I didn't get long to play with this, but here's my thoughts:

1. Our main use case (module grouping) is fixed - this was my main complaint.

2. I agree with Erik that the dependency view is, well, strange. I think it overloads the structure view pretty heavily, and the fact that you can only see dependencies for one module at a time and then only when you have the module selected is not very intuitive or ergonomic. I guess I have trouble visualising how nested modules would work, so I still don't really understand what the problem with having this in the actual project view is - intuitively, that seems like the place for that information. I don't think this would be a huge problem for me but I can't really see it as a positive change.

3. I asked around our office a bit, and nearly everyone (except me, now I feel like I've been missing out) used Alt-F1 (open in project view) on a library class to jump to the library in the project view and see which library and module that class was actually being obtained from. How would this work in the new view? It'll just jump to the long dependency list, and I won't be able to tell which module is actually providing it, is that right? Is there some way they could achieve the same effect?

constv wrote:

By the way, for the rest of us - those who actually spend more time working with their source files rather than gazing at the lists of jars - ...


If you're concerned about the quality of the "ridiculous" discussion you could always try contributing to it by not being sarcastic and inflammatory. But I agree that a checkbox to hide "virtual" artifacts from the project view might work well. The best compromise I can think of would be to display dependencies etc under the module in the project view as Idea 8 did, and be able to hide them if required (probably with a button like the "flatten packages" etc ones). But then you're pretty much just going back to the v8 way of doing things with an extra option.

Maxim, can you explain a bit the rationale for this change? I don't understand how it helps the nested module case (i.e. the case of how you develop IDEA itself). From what I saw in IDEA-25835, you added links to IDEA-872 & IDEA-3556 as examples of what people found confusing, but they were both a very specific case - it sounds like when a directory was added to the classpath it was hidden from the module view and places under the Libraries node. It seems like simply fixing that case might be easier than a wholesale change in how the project view works.http://youtrack.jetbrains.net/issue/IDEA-3556

Cheers,
Colin

0

I don't really know what 'new solution' you are referring to - this thread has become very long and I haven't kept up with every contribution (I wish JetBrains would use more user-friendly forum software that allows an outline view of a thread and configurable ordering, e.g. MyBB or vBulletin).

I would be happy with the option to use a version 8 style project view, or alternatively, an additional structure view (like the class structure view) that sits on the left below the project view and shows the dependencies of the module currently selected in the project view.

As long as I can see the module dependencies (especially library files) in a non-modal view that doesn't interrupt my editing, I'll be happy.

0

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. Here are some example use cases:

1) Legacy Applications
We are often called upon to either support or update a legacy application. These applications were written when most developer's thought Java was something you got at Starbucks. Ant and Maven were not even twinkles in their creators eyes yet. Even the more "modern" applications that use Ant or a shell script lack any sort of true dependency management.  When working with these applications, the first thing you try and do is to organize them better (i.e. modularize), get them into a build system, remove unused dependencies, and consolidate used dependencies. This results in the frequent need to compare and contrast the dependency graphs of various modules while editing the build files (build.xml or pom.xml). This could be done in IDEA 8. But cannot be done in 9, even with the new solution.

2) Early stages of an application
During the early stages of application development, you are still flushing out how you want to organize/modularize your application. Dependencies get add, removed, and moved frequently. Being able to compare them quickly is very necessary. Think Agile.

3) General inter-team development
When working on a module, I decide I need to use the xstream API. When I go to add it, I first want to see if any other modules -- which I am not responsible for and therefore not very familiar with -- are using it so I can decide whether to declare the dependency in my module, or at a higher level. And if it is needed at a higher level, I need to determine how high. Granted this use case can be done to a degree with the new view in the Structure tool window, but it is cumbersome, especially since I cannot see the dependencies listing while editing the build file.

4) Refactoring & project cleanup
Every so often it is desirable to cleanup a project. Part of this is removing duplicate dependencies from child modules and placing them into a higher level common parent module. Being able to see the dependency tree of multiple modules when doing this is paramount. This process is often done to catch things that were not caught when doing # 1, 2 or 3 above.

5) Use of shared modules
As Erik pointed out above, it is not uncommon to have a module, or group of modules, that is shared by multiple projects. Having the ability to easily compare and contrast modules' dependency set in such a case is imperative.

6) Quick finding of dependency ownership
I also, like Colin's coworkers, use Alt+F1 to fine the dependency's placement. In IDEA 8 I could see what module it belonged to. In IDEA 9, I cannot. This, IMHO, is a huge loss of functionality.


If the view from IDEA 8 cannot be returned, can a new view under the Project tool window's "View As" drop down be added? A "dependency Tree" which shows the dependencies broken down by modules. The "packages" view currently does this. So I would have to assume it could be done for a dependency list. Colin's suggestion of a toggle to turn the viewing of dependencies on and off might also be useful.

I have not followed this thread in its entirety. But it seems the primary difference of opinions come from the simple fact that different people organize there projects differently. The two primary areas of differences are 1) Whether the file system or the build tool provides the primary structure. 2) And whether the project uses a hierarchical or a flat structure. There is then some intersection between the two points as people set up there projects. The bottom line is that all of these methodologies, whether we personally agree with them or not, are in high use. IDEA, being a premiere IDE, needs to support all of them, IMHO.

0

To summarize:

JetBrains implemented a new file structure as a replacement of the project structure. People (me) can't work with it for the following reasons:

1) the concept of groups is gone

2) the dependencies + dependency source per modules is gone

The current 'solution' is to re-use the class structure window to sometimes show the module dependencies. I say 'sometimes' because:

1) The structure pane takes up screen space, so (for me at least) it's never visible.

2) the module dependencies are only show in the structure pane when the module is selected. This means that:

    a) opening a class in a module dependency is a pain, because the external dependencies, as well as the module dependencies view the same class contents. This means losing the focus on the current module, and having to scroll all you're way up (in a different window), to the module you were looking at, and repeating this process for each dependency.

    b) since there is only one structure pane, and only the dependencies are shown of the selected module. Therefore, comparing module dependencies is not an option.

So, in my opinion, this 'solution' is not much different from the modal screen, and is certainly not usable at all.

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

or

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

or

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

Erik Pragt

0

I did just realize that for #6, Alt +F1 > Project > Packages can be used as an alternative. It at least tells me what module the dependency is in. But not which actual dependency (i.e. jar). And for APIs that break down their distributable into multiple jars, like Spring, that ends up being basically useless.


0

Hello Mark,

6) Quick finding of dependency ownership
I also, like Colin's coworkers, use Alt+F1 to fine the dependency's
placement. In IDEA 8 I could see what module it belonged to. In IDEA
9, I cannot. This, IMHO, is a huge loss of functionality.


Sorry, I don't quite understand this use case. At least in our projects,
a library is typically used in multiple modules. 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.

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.

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


0

Apart from all these points, the way that IDEA 8.0 shows dependencies in the project view is quite similar to Eclipse and NetBeans.

While being similar should never be an explicit feature, diverging too far from what people are used to creates an additional hurdle for 'switchers'.

-tt

0

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?

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


0

Please sign in to leave a comment.