I just created a project, and I notice immediately that I can't seem to right-click on my src folder and create a logical file group/folder within the project view.
In many IDEs, I can arbitrarily organize source files in groups/folders. These grouping help me organize my business process and data access layers appropriately.
How do I do the same in IntelliJ?
I'm not sure what the exact equivalent to what you're thinking is, or if there even is one.
IntelliJ has a notion of "scopes". Under the Project/navigation view, click the configure dropdown and choose "Edit Scopes...". From this window, you can define a pattern to include certain files from your project.
For instance, all of my DAOs are in packages called my.company.<feature>.persistence. I create a scope called "DAOs" with the pattern src[myProject]:my.company.*.persistence.*. Now when I choose "DAOs" from the Project view dropdown, I see a filtered view of the project. I haven't found a way to show that filtered view alongside other scopes at the same time, however.
These scopes can also be shared, and they can be used to narrow down searches. They are similar in many ways to Eclipse's working sets.
Many scopes are defined implicitly, like Test and Production, Changed Files, VCS changesets, etc.
Related
I have multiple projects that I want to share a similar .clang-format style, but I also want to be able to make minor tweaks between each project so they can be slightly different from one another if needed. Currently each project just has the same .clang-format file copied and pasted into its own repository, but it feels wrong because all of the style options are just duplicated from project to project and if I need to change one option I need to go across all projects and manually change it in all of them.
I would like to create my own style that can be used with the "BasedOnStyle" option (See here for more info). That way I can specify that I want all of these projects to be based on the same custom style that would be kept in a shared location, and then I could easily override any project specific options on a per-project basis.
As far as I can tell, there doesn't appear to be any way to create your own style and save it so other projects can be based on the same style. I feel like this is something a lot of users would need (for example if a company wanted to define their own master style that all projects should follow there doesn't appear to be a good way to do it).
Has anyone else run into this problem and found a good solution?
I reached out to the llvm-dev email list and got a response. A feature request is in the works to do something similar to what I want, but not exactly the same. Either way, this should be suitable for my needs when it becomes available.
https://reviews.llvm.org/D93844
I am working with a big project on my IDEA with many modules. I would like to compare files and directories in the project view. Scrolling each time just to select the files for comparison is tedious. I am not using scroll from source so what I wanted to have is two views of the project, each one is scrolled to different files.
Is there a way to achieve that? Or any other alternative?
The closest you can get is the favourites view where you can drop individual files into a list and then compare them without having to scroll around the project view. Unfortunately that is only any use if you are comparing the same sets of files each time.
Unfortunately there is no out of the box way to do that, IDEA can run multiple instances, each with a different project, but switching is kind of painful.
One workaround is to import multiple maven projects as a modules of one project as described in this question.
There is an issue for that feature in the JetBrains issue tracker, it is interesting to read the conversation history there. Currently it seems JetBrains do not plan to implement this feature anywhere in the future.
...it makes no sense in IDEA. Unlike other platform-based IDEs, IDEA
supports multi-module projects, and all the contents displayed in a
single frame are modules of a single project. Introducing an extra
level of hierarchy above that would be unnecessary and extremely
confusing.
...
We don't have any plans to provide any other solution for this. The
1:1 correspondence between projects and frames is essential to the
internal design of IntelliJ IDEA: by definition, a project is the set
of code opened in a single frame. There is no way to change this
without rewriting the whole IDE, which we don't plan to do.
There was such view in intelliJ called Commander. Since last versions it's not shipped together with intelliJ, but you can install it as a plugin.
I think it will be helpful for your case.
So far I have two short questions:
1) What precisely are the benefits of creating custom nature?
2) Is it possible to somehow programmatically read files in [project]/.setting or [workspace]/.metadata/.plugins?
I'm using Eclipse Helios (3.6).
Ad 1. I've read that you can't have two natures ofthe same set, that you can use it to associate certain perspectives/tools (ex. builder) with it but well.. anyting else I can't do easily without nature? Ex. I can easily add a builder by modifying an IProject variable.
Ad 2. I tried to find a way to read project specific settings or plugin settings but failed. No specs, different file types, inconsistent XML tags... Is it at all possible without parsing them manually?
Thanks for your help!
Paweł
Think of a nature as a flag. All project-related functionality in Eclipse is triggered by natures. Project properties pages, context menu items, etc. appear based on presence of natures. Third parties can check for presence of nature to tell if the project is of certain "type". A nature also has install/uninstall methods. This gives you a convenient place to implement all actions that need to happen on the project when your technology is enabled. Why is that convenient? Because a third party can simply add the nature without knowing what else is necessary to configure and your code takes care of the rest.
Plugins write to [project]/.setting or [workspace]/.metadata/.plugins locations in different ways. The file formats are never documented as they aren't meant to be manipulated directly. Some plugins re-use the common ProjectScope and InstanceScope classes to read/write the data. Some read/write on their own. I would start with what information you are trying to read, figure out which plugin it belongs to and then see if there is public API in that plugin for accessing that information. Reading these settings directly is almost never going to be the correct approach.
An iPad project I have been working on has become bloated with a huge number of files. The application is a prototype and we are considering ways to prevent this when we rewrite it.
One of the members of our team suggests dividing all of the components into separate Xcode projects which will be included in a master Xcode project.
Is this a good idea? What are the reasons, if any, to avoid dividing features/components/controls into separate Xcode projects?
You can add a subsidiary project file to a master project file in Xcode. Just choose "Add File" and add it. When Xcode builds the master it will build the subsidiary as well if needed.
I use a similar system. I often break a project into sub projects just so I can focus on and enforce encapsulation. I write the data model first, then add the app delegate, then specific UI elements. I add each project to the next in turn. This also allows me to go back and change things without as much risk of breaking.
Really, a properly designed objective-c app should be easy to decompose into multiple project. Ideally, all the components are so encapsulate that they don't need any others save the data model.
We have put some of the code in its own project, building a framework which we link against at some of the other projects. It's sometimes annoying that you won't see the implementation files of the framework code right away in another project (by cmd+clicking or cmd+shift+D, or whatever you do normally to navigate). Xcode will only show you the header, you'll have to open the other project and find your file there manually. Not a big deal, but if you look up the code often, it will bother you.
A real problem is that you change the scope of some operations. Stuff like "Find in project" will work on a different file set, which might not be what you want sometimes (trying to find where this method is called / key is used in your whole code, or something); well, there remains Finder / find, so it might be okay. Refactoring is not - all the renaming stuff just breaks, as it will change only the code of the current project, but not of projects referencing this one. If you change interfaces often, better avoid splitting up the project.
A good thing is that you will get less conflicts on your .xcodeproj files (if stored in a shared repository) as someone removing a file from project X won't create a conflict with someone else adding a target on project Y, which where previously the same .xcodeproj (not exactly sure this is a conflict case, but there definitely are some).
Now with Xcode4 you can create a workspace and add all your projects there. Only for documentation purpose :)
To view and modify subproject implementation files, you should add the sub projects directly into the main project.
1 step - Drag and drop the .xcode project files to main project.
2 step - Go to main project TARGETS - > Build Phases. Add subproject target in Target Dependencies. You can also add binary files in Link Binary With Libraries.
3 step - Add subproject source path to main projects header search path.
Go to main project - > Build Settings - > Header Search Paths (e.g $(SRCROOT)/../CoconutKit-master/CoconutKit/Sources )
An Xcode project can have any number of build targets within it, and you can arbitrarily group source files into folders. What makes you think that multiple projects are necessary?
Can somebody tell me what the purpose of the Intellij Commander is?
http://jetbrains.net/devnet/docs/DOC-17 :
The two-panel Commander paradigm is a way of representing a hierarchy which provides the following benefits when working with the project elements:
In contrast to the tree-mode views, the Commander always shows only one hierarchy level which is rather convenient in many situations (e.g. when you are permanently working only with one package and don't want or just don't need to view the entire hierarchy-tree)
It provides a very convenient interface for copying and moving packages/classes (i.e., when using copy/move operations in one of the two panels, the destination is automatically suggested according to the location currently expanded in the opposite panel). For details on the operations available from the Commander, please look at the popup menus that appears when you right-click on different nodes in the commander tree. These menus are context-dependent and allow different operations on the elements of different types.
If you don't use it, you can always disable the Commander plug-in in Settings | Plugins.