>To me, this is a huge difference, and I cannot imagine working on a multi-user >project with the old .ipr format anymore.
Since the project-based configuration is committed to the repo why do you need to generate it? Well... that's the way I think about it and hence personally, I find generation of *.ipr more important from the gradle standpoint. We want to support directory format, though: >More than half a year ago, we had created a JIRA issue with a patch that >supports the new .idea format. So far, nothing has been >done in that regard >(at least nothing that I'm aware of). I wanted to merge this patch some time ago but the idea plugin was under active refactoring to accommodate Tooling API - it had higher priority than directory-format. Since most of the refactoring is done we could merge it now but the patch no longer up-to-date :/ If someone provides a fork with a good solution I'll find time to merge it. >The workspace file is supposed to be a user's private workspace settings (open >editors, etc), what's the point of ever generating this? Good question :) Here's the use case I found in more than one project: devs are using the xml hooks to configure some extra stuff when .iws is generated. For example, the default vm parameters that are used when jUnit run configurations are created. >This is the first time I hear that .ipr is the "old" format. Isn't it still >the default in IDEA? You're right, it is the default. Yet, I think that IDEA remembers the setting of your previously created project. So if you created an .idea-formatted project, the next project you create will have .idea format selected by default. Cheers! On Tue, Jul 19, 2011 at 9:26 AM, Etienne Studer (practicalgradle.org) <[email protected]> wrote: > The fact that the .idea format breaks apart the project-specific > configuration into multiple files makes it possible to share only those > aspects that actually make sense to be shared, e.g. inspection > configurations, shared run configurations, etc. and to not share those > settings that are very user-specific like window positions, etc. > > To me, this is a huge difference, and I cannot imagine working on a > multi-user project with the old .ipr format anymore. > > Regards, Etienne > > > > On 19.07.2011, at 04:20, Peter Niederwieser wrote: > >> >> Hani Suleiman wrote: >>> >>> Some questions about this as I'd dearly love to use it but have a few >>> concerns... >>> >>> - Why is it generated the old .ipr format, rather than files using the >>> .idea directory format?' >>> >> >> This is the first time I hear that .ipr is the "old" format. Isn't it still >> the default in IDEA? How is the "new" format better except that it allows to >> check in some parts but not others in to source control? >> >> >> Hani Suleiman wrote: >>> >>> - The workspace file is supposed to be a user's private workspace settings >>> (open editors, etc), what's the point of ever generating this? >>> >> >> I'm not sure if you can open a project without an .iws, but maybe we can do >> better here. Any suggestions? In the Gradle build itself we use this for >> sharing run configurations across the team (integration tests, run Gradle, >> etc.). >> >> -- >> Peter Niederwieser >> Principal Engineer, Gradleware >> http://gradleware.com >> Creator, Spock Framework >> http://spockframework.org >> Twitter: @pniederw >> >> -- >> View this message in context: >> http://gradle.1045684.n5.nabble.com/IDEA-plugin-tp4599556p4610682.html >> Sent from the gradle-user mailing list archive at Nabble.com. >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Szczepan Faber Principal engineer@gradleware Lead@mockito --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
