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
0
140 comments

Hi Anton,

I wish that was true. How could I ever come up with a rule to not allow Wicket, Echo, JSF, Tapestry, Struts, SpringMVC, GWT, etc in my Dao layer? Unfortunately, that's not possible. So I need a way to check this by hand. Whether the dependency was added by hand, or accidentally added because of (for example) a transitive dependency by Maven doesn't really matter. In IntelliJ 8, accidents like this are very easy to spot, since you'll see them right in your project view, which is almost open anyway. Now, with IntelliJ 9, I still haven't seen a comparable feature, so I still cannot switch. And to be honest, that sucks, since I really like what you've done with the rest of IntelliJ 9. The Grails, Spring, Maven integration is excellent! But I'll stick to 8 till I have a solution for this issue.

Thanks for responding,

Erik

0

Erik,

Have you looked at the Maven Enforcer plugin:  http://maven.apache.org/plugins/maven-enforcer-plugin/index.html ?

You can setup rules (for example: banned dependencies) in your pom and you can cause the build to fail if they are violated.  It's not immediatly visable in IDEA that a "bad" dependency may have crept in but if you have a continuous build environment then the errors should show up pretty quick.

0

Hi Russ,

Thanks for the link. However, it's the same problem I have as described above: I cannot specify every library in the world to be used / not used. We even develop our own libraries, which should or should not be used. I mean, we developed a commons-rest module. This module should not be used in our UI, since our UI should only talk to the service layer. However, the UI can use Joda time, it might use velocity, it can not use hibernate/jpa/toplink, it can also not use Wicket AND Echo AND JSF AND Tapestry, but should only use of of them, etc,etc. So it takes human eyes to look at these dependencies. Also, sometimes I'm using commons-rest:2.1, which doesn't have support for redirection, while I should use commons-rest:3.0, which does support that, and also supports authentication. At the moment, I can only see that my project uses commons-rest:2.1, and also uses commons-rest:3.0, but I have no idea which module uses which version of which module. In IntelliJ 8: no problem: just collapse the project view, see the module dependencies, open the commons rest 2.1: ah, no redirection support and not autentication. Open the other module, see there: ah: 3.0. Open it in the project view, open the sources in the project view, and he, a RestAuthenticator and RestRedirector class. Nice, this is the library I should use, so I change it in the Maven project, reload the project, and my project view will reflect the changes. In IntelliJ 8.

In IntelliJ 9, you don't have an easy overview of this, you cannot compare modules, and you cannot see the implementation of that library all in an easy way, so I cannot migrate to IntelliJ 9.

0

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.

Ha, just noticed this stab at me from a while ago... (Finally had time to drop by this forum after a few weeks.)  Well, I guess I am not as profesional as you are, or some other real "pros" who have time to hang out in forums for months. Not that it has anything to do with this discussion, but I have been successfully building commercial systems of various levels of complexity - using IntelliJ, specifically, since 2002 - for many years now. I do this for a living, as a free-lance consultant, and get gigs based on references and good results. I can't afford doing a sloppy job.  Now, to answer your specific question: yes I do check my module dependencies every now and then, and, surprisingly, I don't find it necessary to do it very often. I never bring my projects to the point when I have to weed through them for hours trying to figure out what is what. The key for me is to have a meaningful project configuration with minimal dependencies. Elegant project configuration and structure is as just important to me as elegant code.  Yes, from time to time I keep the dependency tree expanded for a particular module in the Maven pane - e.g. to see if everything gets properly updated as soon as I change the POM file source code. But, believe it or not, I don't very often use the dependency tree in the Project pane to do the things you describe.

0

Hmm, not that I re-read it, it looks like a stab indeed. I'm sorry about that, but it wasn't meant like that. The 'professional' remark was referring to projects which are usually quite bigger, instead of 'hobby' projects. My question is/was actually a genuine question: I'm really curious how you can work with software without looking at the dependencies. That wasn't meant as a stab, and I'm sorry you felt like it was, but the question behind the question was that I'm using IntelliJ maybe in a wrong way, therefore the question. But after re-reading it, I'm not surprised it feels like a stab. So I won't respond to the non-topic related remarks, if you don't mind.

I totally agree on the project configuration and project structure. I value that in a big way, and when I would do project by myself or with 2 people, it would not be a problem. However, the projects I work in usually range from 5 to 10+ people, and maintaining a sane project structure + dependencies becomes a little harder than, since a lot of the people I work with all have different values and meanings of 'good software'. While I value dependencies, project structures, clean code, etc, other peoples just might value working code, or code which is 100% covered by tests. My point is that when working with more people, I experience often that dependencies are introduced on a wrong level, which at the moment is hard to see.

So, I'm wondering: how do you do this things? How do you maintain your dependencies (in bigger projects) ?

Sorry again for the perceived stab, not meant that way, and it was certainly not my intention to doubt your professionalism or something!

0

Erik, sorry for taking a long time to answer your question. I haven't stopped by the forum until today. Of course, I monitor dependencies. However, I find that I prefer to see the dependency tree in a separate pane, not in the same place with my "editable" sources. Since I have been using Maven for years now - on every project - since before version 8, I have been using the Maven pane for that purpose. As you know, the Maven pane lists individual modules inside the project, and each module tree may be expanded to show the maven goals + dependencies, on the per module basis. At the same time, you have all module nodes in the same view, so you can scroll up and down the whole project to see which module has which dependencies. This is, basically, what you want, as I understand. Except, your point has been to keep those dependency trees together with the editable sources in the Project View. I agree that it is definitely better to split dependencies by module, and, ideally, to have the complete project dependency tree (with module sub-nodes) available in a single view. Those who use Maven already get that inside the Maven view. However, not everyone uses Maven, of course. However, my point is that it is probably not very "clean" and somewhat cluttering to mix editable project sources with the JAR libs in the same view. For the very reason you mention: some people tend to accumulate way to much clutter in their sources anyway, so, I welcome any opportunity to clean things up, e.g. by separating things that may be logically different. I believe, editable source and JAR dependencies should be separated. That does not mean that there shouldn't be an easy way to "jump" to "all things this module" at any given time. Perhaps, there may be a right-click menu item "Show Current Module Dependencies" available at any time (in the editor) that would open the Dependencies view with the current module expanded. But there is no reason why the libs must be in the same tree view with the sources.

I think that ideally, it would be great for everyone if there were a separate view "Dependencies", or "Libraries", that would show only the tree of the project's dependencies - with each module displayed as a separate node under the Project root. In other words, it would be similar to the current Maven view, without the maven targets, just the libs.

So, that would be my choice. I guess, my point all this time has been: avoid mixing sources with the libraries, keep the Project view for sources only (it is a useful alternative to the Packages view b/c you most often want to see your folder structure and non-Java files) and provide a separate convenient Dependencies View where the libs are also sorted on the per module basis. (And since the Maven pane provided me with just that, I, for the most part, rarely found any need to weed through the libs in the project view.) Make sense?

0

Hello everyone,

I was wondering if there's an update on this planned for 9.0.2 or something. My IntelliJ license has expired, so I can't check myself, but the reason I haven't upgraded to IntelliJ 9 is because I find it hard to see the dependencies of each modules in IntelliJ 9 in combination with jumping to the source of those libraries. I was wondering if a good alternative to the way IntelliJ 9 does it has been found already. I can see other peoples view too, with keeping libraries separated from the sources (though I find it quite handy to have them together), but having a list of ALL my module dependencies in one huge list doesn't add any value at all (which is the way it was implemented in IntelliJ 9 the last time I checked). I personally don't see the use of this 'Project Library' thing (don't know the exact name), since this list gives the false impression that these dependencies are related in any way, or that they can be accessed in my complete project (which is false, and which gives the IntelliJ 9 user, me in this case, and incorrect view of the project dependencies). Plus, the list so big right now (300+ dependencies), that's it's unmanageable.

Any update on this would be great.

Thanks, Erik Pragt

0

Anyone? I'm still interested if anything has been changed for the module support (for example, show the library contents in the maven view, and maybe automatically linking from the IDE to it, instead of the structure + project view). Any update on this would be great!

0

As far as I can see the maven view / sidebar has a list of libraries for each module. It's a dependency tree and not a list of module libraries, though.
There is now way to list the content or to show a certain library class in the source module library.

I miss the old way a lot, too. With more than a few modules it's very hard to work with libraries.

0

Hi Wallaby,

Thanks for the reply! I don't like the Maven dependency tree much, because of the reason you just mentioned (no content of dependencies), because it's sorted in a random way (not alphabetically at least), and the Main IntelliJ window doesn't jump to that view, but jumps to the structure view as well as the project view. This is actually the only reason I haven't upgraded yet, nor hasn't anyone in my current team. It would still be much appreciated if this could be fixed in some way! (and yes, reverting to the old behaviour is still an improvement over the current implementation, though I'd love to hear even better implementations)

Erik Pragt

0

Just opened another Youtrack issue for this: http://youtrack.jetbrains.net/issue/IDEA-53408 . I really hope this can be resolved in some way.

0

Hi guys,

It seems as if this issue still exists in the new IntelliJ X version (check for example this screenshot (it's from 9.0.3 btw), with regard to the Hibernate annotations, or Jetty, or Log4J for example: http://grab.by/5T1Z

Would be great if this could be optimized again

Erik

0

Couldn't agree more Erik - my experience of working on multi-module Maven projects is one of the only times where IDEA hasn't been a pleasure to work with and I ended up dropping into Eclipse (shudder) and command prompt Maven.

0

Simon, have you tried version 8 of IntelliJ? Cause IMO, that version does work correctly (project view looks better, it has the concept of modules which you can group by, and the dependencies are linked to each module).

Btw, I would recommend STS (SpringSource Tool Suite) instead of Eclipse for working on multimodule projects. It's not as good as IntelliJ, but still pretty good, and has good Maven / Spring integration. And it does support multi modules/projects correctly ;-)

0

Hi all,

Maybe I can come in on this one with a suggestion.

I get the impression that a lot of people have a lot of modules in a single project because it used to be to much for IntelliJ(circa v6-8) to have multiple projects open for a long time with a lot of dependencies to manage and a lot of indexing to do. At least that was my experience. Since v9 memory management has gotten significantly better and I often work with 2 or 3 IntelliJ project windows open for hours if not days.

I am not trying to tell anyone what to do but maybe this approach would help and maybe, like me before v9, you tend to have everything in one project cause that was the optimal IntelliJ way.

BTW, I don't particularly like that the dependencies have been merged into one list either but the maven dependency list makes things ok I find.

cheers,
Florian

0

Hi Florian,

Thanks for the suggestion. I agree on the stability of IntelliJ: it's very good. However, what I do, is that I load everything in 1 instance of IntelliJ. I do this mostly because of the following reasons:
- Switching between projects (IntelliJ instances) on a Mac is hard: you have to you CMD+`, and you have no idea which instance of IntelliJ is open
- Refactoring, find usages, etc, is harder (impossible?) over multiple projects

Any of the reasons is a reason to use IntelliJ as I do (or used to do). I have one POM with all projects, then some parent poms with the modules in it, and then the poms per module with all the dependencies. Opening the root pom will load all projects in IntelliJ, which is a really nice feature, and which used to create a very nice project structure (when using the 'group by module' option) in IntelliJ 8. In IntelliJ 9 it looks more messy, and it now creates a top level node, which does nothing.

I don't like the maven dependency list much. It still doesn't include the source code, it's sorted in a random way (which makes it hard to find the right libraries), it's not grouped and it's not linked to the main editor window, which makes navigating a pain (plus I have to use my mouse for it, which I try to do as little as possible). Because of this, I never have it open, plus it takes too much screen space (I already have the project view open on the other side of the screen), while adding little.

Erik Pragt

0
- Refactoring, find usages, etc, is harder (impossible?) over multiple projects


yup... not much one can do about that one... I just wanted to mention it because as a long-time user of Intellij(I started by using their JBuilder plug-in in the pre-Intellij days) I have developed habits that are a product of the IDE's features and short-commings. Sometime re-thinking or getting rid of the habit is the solution :)

florian

0

Our POM set-up is pretty much identical to Erik's and we appear to share a lot of the same pains
  As soon as I'm in a location which isn't restricted to IE6, I'll pop onto YouTrack and add my thoughts to the issue.

0

When a lady is conscious about her height, the smallest of http://www.sale-handbags.com/Armani-c-12.html. People who are blessed with http://www.sale-handbags.com/Balenciaga-c-36.html would not be able to relate well to the obsession of looking tall. The vertically challenged would see the world in a different way then the people who stand tall.The choice of http://www.sale-handbags.com/Bally-c-22.html is the first thing that these less than perfect http://www.sale-handbags.com/Bottega-Veneta-c-20.html would like to consider. There are certain dresses that can make these beautiful ladies look taller and http://www.sale-handbags.com/Burberry-c-29.html is true in case the wrong dresses are picked. Like for example rather than wearing the designs which are horizontal, the blouses, the skirts or any such http://www.sale-handbags.com/Cartier-c-13.html which has vertical lines should be preferred. The http://www.sale-handbags.com/Celine-c-25.html would add the illusion of http://www.sale-handbags.com/Chanel-c-3.html looking tall. Rather than going for http://www.sale-handbags.com/Chloe-c-39.html clothes, skinny clothes would add a little to the height. The http://www.sale-handbags.com/Christian-Dior-c-33.html would not only make the lady fatter than actual but at the same time would make her appear even http://www.sale-handbags.com/Coach-c-2.html. Wearing long dresses would be a bad idea as that would highlight the fact that these ladies have less than http://www.sale-handbags.com/Dolce&Gabbana-c-15.html. An evening gown touching the ground is definitely not going to add that elegance to the lady dressed for http://www.sale-handbags.com/Fendi-c-35.html. http://www.sale-handbags.com/Ferragamo-c-10.html and http://www.sale-handbags.com/Giverchy-c-24.html over the horizontal and http://www.sale-handbags.com/Gucci-c-37.html should be preferred.The hair do also contribute to make a lady look taller. One needs to let the neck show off as that would make the lady look taller. Having short or http://www.sale-handbags.com/hermes-c-34.html should be ideal for the ladies to look taller than their height.The above suggestions would add an illusion of being tall to the overall look. Wearing the http://www.sale-handbags.com/Jimmy-Choo-c-31.html would be the best way to actually stand tall. Depending upon how tall a lady needs to look, she could choose the footwear accordingly. A majority of http://www.sale-handbags.com/Juicy-Couture-c-8.html would not be considered as slipping into these would be painful. This is true only to a certain extend. A little practice and using things like shoe cushions can help ladies to add few extra inches and let go off the pain.The kind of http://www.sale-handbags.com/Kooba-c-27.html that the lady carries would also add or deduct from the tall look she wants to have. Like for example, carrying http://www.sale-handbags.com/Lancel-c-21.html which are vertically designed would add to the overall look. The Louis Vuitton http://www.sale-handbags.com/Loewe-c-19.html could be the example of one such http://www.sale-handbags.com/Louis-Vuitton-c-1.html. As the http://www.sale-handbags.com/Luella-c-26.html which are horizontally designed and has short handles or straps would make the lady look shorter than she actually is. There are not many ladies who could have the pleasure of adding extra inches to the height or to the overall illusion look of being tall with the designer vertical http://www.sale-handbags.com/Marc-Jacobos-c-30.html, as the one mentioned above. For these ladies the imitation or the http://www.sale-handbags.com/Marni-c-23.html is available to choose from.Though, when the perfect tall looks is desired every thing would count, even the http://www.sale-handbags.com/Miumiu-c-32.html that a lady is carrying. But the real difference would be made by the heels that she is slipped into.

---
Original message URL: http://devnet.jetbrains.net/message/5278994#5278994

0

Please sign in to leave a comment.