I am looking for information/documentation about reading project information from the .idea directory within projects created with various JetBrains programmes.
In NetBeans it's fairly straightforward: you open nbproject/project.xml and can get the name of the project, as well as the project type (e.g. org.netbeans.modules.php.project).
With .idea, I am having a harder time finding the definitive locations of the data.
Specifically, I am looking for:
Name of the project (if different from root directory name)
Exact software the project was created with (WebStorm vs. PhpStorm vs. PyCharm vs. RubyMine vs. [...])
Name of the project (if different from root directory name)
Look in .idea/.name file (if exists) -- it's a plain text file with single line of text.
Exact software the project was created with (WebStorm vs. PhpStorm vs. PyCharm vs. RubyMine vs. [...])
There is no such info inside AFAIK -- all products use the same folder/format (well, IntelliJ can also use .ipr files IIRC -- legacy format).
Different IDEs may use different types of modules: e.g. PhpStorm/WebStorm only uses WEB_MODULE -- look in .iml file.
Related
I am attempting to stand up a VxWorks Workbench version 4.5.2 project into a CM system but am running into issues. I have just started learning VxWorks Workbench. I have searched a bit on how others have done this and I came across two solutions:
Make the project path relative in a sub-directory in the WindRiver home directory.
Do not version Workbench project files and just version my source code. Every client must re-create the Workbench project on their local machine.
The first solution would be ok but I have not been able to make it work. There seems to be some registry (Windows 10) or some path stored elsewhere for Workbench related workspace locations but the end result is the project is not loaded.
The second solution would be a last resort that I would prefer not to do as there are many steps to re-creating a project on a local machine making it tedious and error prone. Does anyone have experience versioning Workbench 4 projects into CM and can share possible solutions?
This can be complicated, and it very much depends on what project type you are talking about.
For DKMs, RTPs, Static and Shared Library projects, you need to version these project files:
.wrproject
.wrmakefile
.cproject
.project
Other project types will have these, but also some additional files that are required to recreate the project, for instance VIP projects also have a <projectname>.wpj file. A conclusive list is too long for this answer however.
You do not need to version the automatically generated Makefile , nor do you need to version the automatically generated build subfolders.
My advice is to store the projects along side your code. I personally prefer to store my projects outside of my workspace, and they should certainly not be stored anywhere in your Windriver installation folder.
I tend to use a structure like this:
c:\gitrepositorys\CuriousCamel\Source\
dkmProject1
.wrproject
.project
.wrmakefile
.cproject
dkm.c
dkmProject2
dkmProject3
vipProject
etc.
The above are all versioned. In terms of the actual Workbench Workspace, I tend to create it in c:\gitrepositorys\CuriousCamel\Workspace and this is explicitly not versioned - I create it fresh for each clone, and often delete and recreate when I switch branch.
Existing projects can be imported into the workspace using the import wizard (using the General->Existing Projects from Filesystem option). When you create a new project, just make sure you choose the "Create Project in external location" option, and select wherever you have chosen to store projects.
A little intro:
I work on a project with legacy codebase witch uses internal xml based descriptors with specific file extensions (about may be 10 extensions).
Let it be *.desc, *.check etc.
To have code highlighting for such a files I can configure Idea to consider these types of files as XML.
It's available through:
Preferences / Editor / File types
And then add all custom extensions to 'Recognized file types': 'XML'
Our project uses gradle as build tool
and my question is:
Is it possible to make same configuration via dsl of gadle 'idea' plugin?
The short answer is: No.
One could create a custom Gradle task that will modify IDE file type preferences XML file in the config directory. While it's possible to run such task automatically on the project refresh in IntelliJ IDEA, it will most likely not work since you can't modify IDE configuration when IDE is running (the changes will be reverted). So, you will have to run it from the command line, outside of IntelliJ IDEA when IDE is not running.
It's probably not what you want, but if documented, can be used by the team as the manual step to make this configuration change easier.
Using gradle idea is not recommended anyway.
A better way might be to provide your own IDE plug-in that will associate these file extensions with XML file type and instruct the team to install this plug-in.
We started a directory-based project in IntelliJ IDEA (currently using version 2016.3 build 163.7743.44). Everything is fine, the .iml file is inside .idea/modules and we can easily share/update it.
The issue is that, sometimes, when someone clones the project and start using it the IDE doesn't care about that file (or project structure) and puts an .iml outside the project's root. It's an intermittent/random issue and I'm not able to reproduce it step by step.
We opted for deleting the .idea directory from Git and keep the configurations/settings in a JAR file.
Is there any way to tell the IDE to use one approach or the other? It's not a big deal, but I would like to know what's the reason behind that behavior.
The reason for that behavior may be that people don't use the "Open" action to open the project but use the "Import project from existing sources" action instead. The latter action does not use the existing .idea directory, but instead recreates the project structure from scratch. You should teach your colleagues not to use that action.
Note that storing the settings in a .jar file is not a replacement for sharing the project structure, because shared settings do not include project-specific items such as libraries and run configurations.
In the Community Edition when I import a module IntelliJ goes through and tries to figure out which directories are what types. The modules I deal with sometimes have a src and a test directory, which work fine, but more often than not the test directory is actually named tst. IntelliJ likes to mark is as a "Sources" directory rather than "Tests". With the tools I am working with, the dependency configuration and generation of the .iml file happens after this, as well as using a modified build system that is not IntelliJ supported. I have to build via commandline which generates a build folder which I would like to have automatically excluded.
So a couple questions.
Can I configure IntelliJ to automatically recognize different folder names "Tests" and mark them as such?
Can I configure IntelliJ to automatically mark a folder as excluded when it is present in a module?
You can't configure it, the list is hard-coded. However, I've added "tst" to the list of names that are recognized as test source roots; that fix will be included in IntelliJ IDEA 14.1.
You can add "build" to Settings | File Types | Files and folders to ignore. Then IntelliJ will ignore the directories and files named "build" anywhere in your project structure. Given that "build" is a fairly common name, this may or may not be what you want.
As the title suggests, is there any documentation that describes what the content of the configuration files should be? anything from an xsd to a reference manual regarding it's structure would be helpful.
I am researching how to automate the setup of my idea workspace using gradle's idea plugin.
After some correspondence with JetBrains Staff, I discovered that the XSD files are not available for public viewing.
an excerpt from the email:
"There is no complete references or XSD for these files. The format is internal and is not > designed for others to reuse."
If you want to generate projects, consider using Maven or Gradle, generate the files for these tools that IDEA will be able to import them.
Either that means JetBrains don't want you playing with their configuration files (I don't know how Gradle knows what to do) or the structure is subject to change and shouldn't be modified for backwards compatibility purposes (Say intellij updates their IDE and the config files are modified with a new structure, any programs designed to modify according to a previous structure may be invalid).