Poll: Split project (.ipr) file into multiple files
We have an idea to split single .ipr file into multiple configuration files like
code style scheme
inspection profiles
project libraries
shared run configurations
etc.
Basically, the problem is .ipr files is supposed to be versioned but it changes way too often and changes are hard to track. As the side effect we could support graceful reload of named settings on external change like VCS update.
What do you think?
Please sign in to leave a comment.
Good idea. Do you plan to have an option in the system to treat chosen configuration files as a remote resource that can be cached locally?
Hmm, my experience is that the average developer who doesn't hang out on these forums all
day already has problems to understand the differences between .ipr, .iws and .iml files ;)
While the concept and the possibilities sound great, I'm not sure if it won't cause too
much confusion. On the other hand, it could reduce the confusion when it's more obvious
what all of the files contain when they get more descriptive names.
One thing I maybe wouldn't like is an inflation of project-related files, but I guess the
system could be designed in a way that the user can choose which parts should go into
separate files and which should stay in the .ipr.
Sascha
Maxim Shafirov wrote:
Fully agree.
Me either. In most of the projects, the teams already use more than one IDE and
there are just too many IDE related files. The different plug-ins for those IDEs
also add specific files, so it's just a nightmare for the average developer.
>> What do you think?
IMHO it should not be done.
Ahmed.
Yes, please. We're hitting this problem more and more often. There's really no reason that somone else adding a shared run profile should cause me to reload my project on SVN update.
--Dave Griffith
I think it's a good idea, but:
1.) Those multiple files should be placed inside a dedicated directory. This way the root directory becomes less 'polluted' (and non-IDEA-developers will still accept them to be added into VCS...)
2.) It should finally become possible to add those files into VCS without having to create a dummy module.
This is a pet annoyance of mine. There's no excuse for plugin writers to be writing into the project directory. EIther write into the project or workspace files, or write into the config directory if you've got application global configuration.
--Dave
I like this dedicated directory idea. Maybe some form of "conversion" wizard that turns the myproject.ipr FILE into an myproject.ipr DIRECTORY which includes say project.xml, shemes.xml, runprofiles.xml etc. etc. etc.
The "Open Project" dialog could be file/directory aware and list both as projects.
Thoughts?
Why does support for a more graceful reload require splitting the file up? The two would seem to be orthogonal to me.
When .ipr file changes we're pretty unsure what changed there and will be required to build a diff of something to investigate. Having in mind we do not control all of the components writing to the project file as there are 3rd party plugins it becomes quite a tricky task.
Mark Derricutt wrote:
+1
The only issues the directory-only way would cause is the lack of the ability to load a
project file by double-clicking it. The solution might be to keep the .ipr file and create
a parallel folder named $PROJECT$-Files or $PROJECT$.ipr-Files that can contain all other
files:
MyProject.ipr
MyProject-Files/codestyle.xml
MyProject-Files/inspections.xml
...
Sascha
We are used to clicking the .ipr file to start the project. It doesn't
mean that there isn't a .ipr file. It can be in the new IntelliJ
specific directory, along with the other files.
Sascha Weinreuter wrote:
>> I like this dedicated directory idea.
>
>
>> The "Open Project" dialog could be file/directory aware and list both
>> as projects.
>
>
>
>
+1, Please yes! Exactly what I was hoping for...
http://www.jetbrains.net/jira/browse/IDEA-10066
That's only for project libs, but more is better. ;o) Just be sure to include documentation for all the new files, and keep the ability to define everything with relative paths.
--pete
ps. please include ant settings and build files (and maven2 if you ever integrate it) in the set of configurable settings. There's a Jira issue for this, but Jira seems to be down right now.
+1 to the project library sharing idea. In fact, +1 to the whole idea of splitting the project file!
I think what Mark was suggesting is:
If there is a (not yet converted) ipr file, then the open project dialog
shows this file and you can click on it to open the project.
But if there's a dedicated project directory containing all those new
project files, then the open project dialog doesn't show it as a regular
directory but as a dedicated project entry and clicking on it doesn't
open the directory but opens the project.
So you won't loose anything by putting all those files into the directory.
Sascha Weinreuter wrote:
>> I like this dedicated directory idea.
>> The "Open Project" dialog could be file/directory aware and list both
>> as projects.
--
Martin Fuhrer
Fuhrer Engineering AG
http://www.fuhrer.com
That would be great.
But please properly support a dedicated "idea-project-files folder".
I have always stored ipr, iml and iws in a separate folder named "idea", but that makes it a little hard to configure and work with my project:
For example the module creation wizard proposes "idea" as content root (but I'd like the content root to be the parent folder).
I have to remember to check "store path outside the project folder as relative", because virtually all files are outside that "idea" folder.
Martin Fuhrer wrote:
You cannot double-click directories to start an application from e.g. the
Windows Explorer.
Sascha
Please, not more files! :)
If this does happen, could they be kept under a subdirectory please? As the last thing we need is more files cluttering up the base directory, especially in an environment with multiple IDEs where everyone has there own project files in there.
I think that the new 6.0(.2?) feature of being able to share run/debug
settings goes a long way, at least for us.
That was our last need to share an .iws in the SCM system and now it's
resolved (it's not even in the on-line help...).
I would vote no for that.
We'll finally go from 3 to 2 IntelliJ file types (.ipr and all .iml
files) in SCM, I don't think it will do us any good to have multiple types.
Thanks,
Amnon
Maxim Shafirov wrote:
What about those of use that work on multiple machines?
I use my laptop at work, but when at home, I prefer to use my PC(bigger, better, and faster everything).
I keep my projects on a memory card and put them in the machine I am using. I want anything that is project related to come along.
I suggest to keep the existing project(.ipr) file around and just move the components that you want to treat separately in a subdirectory. This way you can preserve the existing behavior of opening a project upon double-click on the .ipr file. The stuff to keep in the .ipr file is:
- ProjectModuleManager
- ProjectRootManager
- information about the subdirectory where other stuff is kept
Maxim.
Maxim, it seems to me that constructing a diff would not be hard, and if all changes are to components which implement ReloadableComponent (or something) then no project reload required.
Yes great idea. Will solve many of our problems.
But i want to suggest a small step forward, something that will solve our problems completely:Each file will consist of two parts, one i taken from he default location were .jpr is and the other can be taken from other relative or absolute location.
This will allow us for example to share run configuration and on the other end, to add some personal configurations.(same goes for inspection[which is big problem today] and others)
Thank
Boaz
Boaz Nahum wrote:
You can already do that with configurations, as in the 6.0.2 EAP there's
a checkbox to share a configuration which moves it to the ipr.
Amnon
Yes, but i can take from other place other then .ipr - you see i wan to share configurations(and other settings) between PROJECTS and users.
Regards
Boaz
Boaz Nahum wrote:
Between users is basically covered. Between projects? Well, that is
something else that may make sense to some people, though I don't think
that splitting the IPR further would help here, but possibly allowing
other partial files to be used in conjunction, thus allowing projects
like ours to continue as they are now, but environments like yours to
use additional files as well.
Amnon
I agree, if the only reason is to enable reload then you're attacking the problem from the wrong direction.
You can detect the file has changed (as it is now), if one of the 'known' nodes has changed (eg, vcs, code style, whatever standard top level nodes idea writes out) then just that gets reloaded. Anything else means a project reload.
There are already too many config files (all the .imls). Adding even more just makes things even more confusing to developers.
+1
Thanks For Your Reply.
I guess I'm missing something-
You said:
Can you share settings (for example run configurations) without share .ipr or .iws ? and allowing individual to add it's private run configurations ? how you do it ? It is very useful for us.
A more urgent need for us - how can we share settings or JDK tables definition between users and again allowing individual add it's own JDKs ?
These question are critical to our project. Today distributing these settings between 60 developers is a nightmare, and in some cases we just give up.
Thanks
Boaz
Boaz, at my company we don't share ipr/iws/iml files, but we all use the same templates when checking out code. So when you check out, you copy ]]>/idea/project.i* into the checkout root, and open that in IDEA. You never check those files back in.
If you want to change a run configuration, which is rare, you simply open those template files, change what you want to change, and check them back in.
However, on a smaller project that I work on, I do share ipr and iml files (not iiws files). This seems to work okay although I wish I could check in parts of the file but not other parts. Why don't you want to share iml and ipr files?
Hi Keith.
We work with ClearCase and we don't have such a concept(or we are not used to think this way) of check in/out a whole project.
How ever what important is your question: share *iml and *.ipr files. I think i need to check this option again with IntelliJ 6. What prevent us doing it till now is we never want the user check out this files. My big question is: now with IntelliJ 6, is it possible for every modification i made (not including changing project structure) is to choose where is be should shared (placed in .ipr) or should it private (placed in .iws) ?
We here all appreciate your support.
Regards
Boaz