I will say just about the same thing as John. Do not check in project definitions!
At work we recognize that the development environment is a personal choice, we spend most of our life inside them, so it's very important that we enjoy our surroundings. To make this work the build system is the central point. This is quite natural since the build file is the authority to the state of the code. It is used for everything from continuous integration to releases. When set up as this, project definitions is only local artifacts, valid only for one particular checkout. Netbean, eclipse and idea definitions never enter the repository, it is the build file that is the important stuff. Whenever I need the code I check it out, build, see that the tests are green and (if necessary) generate the project for my ide. Whenever this doesn't work, there is a flaw that has to be adressed immediately. Anyone on the team should be able to fix any of our projects, and new members can be introduced and up and running with an url to the source. I have never seen an Ant based real life project attain this level of automation (and have seen a loot of really messy ones). At work we use Maven, and feeling the pain I've just started checking out Gradle for my play projects - just started with Scala and didn't think one more DSL would mess things up :) Hopefully this will eventually lead to a more easily maintained environment, but there is politics involved so we'll have to see about that... 2010/7/16 John Murph <[email protected]> > For us, each developer generates their IDEA projects (whenever things > change in a way that causes a problem for them). Therefore, having the > username in the path is not an issue. Many years ago (long before Gradle, > back in IDEA 4 or so days) we tried to share the project files from source > control. Due to a combination of limitations (for one, our source control > software at the time sucked!) this did not work well. In those days we used > Ant for our build, so we wrote Ant tasks that would generate IDEA projects. > This solved duplication of information (dependencies declared in Ant and > IDEA) and the issues we had with sharing the IDEA projects. We just never > looked back as this has worked for us. So, when we switched to Gradle, we > wrote code in Gradle to generate our IDEA tasks. Truth be told, I have not > yet switched to use Gradle's idea-plugin because of a few more missing > features that I'm waiting on Hans to incorporate into the plugin. However, > I don't think we'll care about paths in IDEA since we don't share the > projects. > > Anyway, that's why we do it the way we do. All our developers are happier > being able when to decide to have the project regenerated (this ancient > history matters for us since most of our developers have been with the > company for 8 or more years, so they lived this history). > > > > On Fri, Jul 16, 2010 at 10:42 AM, Dan Tanner <[email protected]> wrote: > >> Hmmm...I wonder why it's not a problem for you guys. My build.gradle >> looks just like the example... >> ideaProject { >> javaVersion = '1.6' >> withXml { root -> >> root.component.find { i...@name == 'VcsDirectoryMappings' >> }.mappi...@vcs = 'hg4idea' >> } >> } >> >> An example dependency path in my generated iml file looks like this: >> <root >> url="jar://$MODULE_DIR$/../../Users/dtanner/.gradle/cache/javax.activation/activation/sources/activation-1.1-sources.jar!/"/> >> >> Having the username in the path is a problem in a team environment if >> we store the .ipr and .iml files in source control. Looking at the >> code, it's creating a relative path to the .gradle cache directory, >> which is set to project.gradle.gradleUserHomeDir + '/cache', and it >> doesn't appear to be configurable. >> >> I tried a couple things with post-processing the xml, but I hit some >> snags. e.g. Here were some ideas I kicked around. >> whenConfigured { module -> >> module.dependencies.classes.each { path -> >> // replace the path with a value that uses a >> team-shared >> IDEA-defined variable >> } >> } >> >> OR... >> >> withXml { root -> >> def urlAttributes = root.depthFirst().'@url' >> urlAttributes.each { a -> >> if (a?.contains('$MODULE_DIR$/../../${user.home}')) >> { >> // replace a with a value that uses a >> team-shared IDEA-defined variable >> } >> } >> } >> >> >> So before I go further down this path...am I making this harder than >> it needs to be? i.e. What's different about your situations that's >> it's not a problem for others? Thanks again for your help guys. >> >> > > -- > John Murph > Automated Logic Research Team >
