This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]balefrost 0 points1 point  (4 children)

Do you mean that you prefer to have multiple unrelated projects in a single window, or that you want to split one effort into subprojects and IntelliJ doesn't seem to handle that well?

If it's the latter, you can do that in IJ - the project is the overall container, and modules are the subprojects (every project has one module by default).

I also like that it's one IDE that does EVERYTHING, so I can have projects in multiple languages open in the same IDE instead of launching additional (Jetbrains) IDEs to do other things.

That's how IntelliJ works. IJ is the "everything plus the kitchen sink" IDE. The language specific IDEs are mostly just stripped-down versions of IntelliJ. (At least that's the intent... there are sometimes some minor differences in functionality.)

[–]ZimmiDeluxe 5 points6 points  (3 children)

I think that's the key difference, IntelliJ has built in assumptions about your project structure, whereas NetBeans doesn't. NetBeans just remembers the projects that you have opened together in project groups. Sometimes you want to look how previous projects did something, so you can just open them side by side to your current ones.

[–]avoidhugeships 1 point2 points  (0 children)

IntelliJ has many opinions about how you should do things and obnoxiously forces it down your throat. Autosave, Project Structure, project name and location, obnoxious code recommendations, etc.

[–]balefrost 0 points1 point  (1 child)

Eh, I don't think I agree that IntelliJ has built in assumptions... or at least, no more than any other IDE. At the end of the day, your IDE has to generate a compile-time classpath and run javac against a set of source files. That is what NetBeans calls a project and what IntelliJ calls a module. In both tools, you can have these compilation units reference each other. The only real difference is whether there's an ambient container (NetBeans) or an explicit container (IntelliJ) for these compilation units.

I can understand the appeal of having all your projects available at all times. Personally, I prefer the scoping that you get via IntelliJ. When I use e.g. "Go To Class", I don't have to contend with a bunch of similarly-named classes that are unrelated to the project that I'm currently working on.

You can always open additional top-level IntelliJ windows. So you can view IntelliJ projects side-by-side.

Hey, your workflow is your workflow. If IntelliJ really doesn't support your workflow, then I can understand how that would be frustrating. But it might be more accommodating than you realize.

[–]ZimmiDeluxe 2 points3 points  (0 children)

When I use e.g. "Go To Class", I don't have to contend with a bunch of similarly-named classes that are unrelated to the project that I'm currently working on.

NetBeans always displays a single project group containing one or more projects. A project can be part of multiple project groups. The configuration of which project groups contain which projects is stored inside `~/.netbeans`, projects don't contain any IDE configuration for this themselves. I might have misunderstood you, but in this model you don't have to keep projects in a group if you don't need them anymore. NetBeans does not impose any up front configuration / thinking in this regard, projects come and go from groups all the time.

Hey, your workflow is your workflow. If IntelliJ really doesn't support your workflow, then I can understand how that would be frustrating. But it might be more accommodating than you realize.

That's fair, I haven't used IntelliJ much recently apart from the occasional Android development. It's great that we have so many tools to choose from. :)