What do java programmers version control?

Discussions

News: What do java programmers version control?

  1. Daniel Hinojosa addresses what gets put into a repository with "What do java programmers version control?," suggesting "all of the things that will allow you to jump from one machine onto to another, checkout your project, and start your work."
    I personally recommend that you put into your version control all of the things that will allow you to jump from one machine onto to another, checkout your project, and start your work. This recommendation comes in particularly handy when your primary machine is on the blink. In this vein, items that get placed into my version control include documentation from the customer, library documentation, library binaries, keystores, and even IDE project files. I do not include class files, or jars that get created by my "build" or "dist" target. You might also consider placing into your version control other types of files that should be safely stored in case you become unhinged and start eating your laptop while yelling "melted butter". Believe me, if you have ever programmed in EJB 2.x or even 1.x, you have, at one time or another, thought about eating a laptop. This particular scenario has forced me to put into my version control items like customer invoices, RFPs, copies of emails, agreements, electronic receipts, etc.
    Do you agree with this approach? What do you store in version control? (Maven, for example, discourages storage of dependencies in revision control, preferring to grab them from a third party repository.) Lastly, have you ever wanted to eat a laptop, perhaps while shouting "melted butter?"

    Threaded Messages (23)

  2. Since I use Maven 2 : pom.xml + src directory. That's all I need and I can work with Eclipse, Netbeans, IntelliJ or JDevelopper :)
  3. Since I use Maven 2 : pom.xml + src directory. That's all I need and I can work with Eclipse, Netbeans, IntelliJ or JDevelopper :)
    QFT :)
  4. Tools[ Go to top ]

    I would normally use maven so I would just store what is needed in the source project trees. However, I would have a separate project for tools where I would version control some of the tools we would use (license permitting) The advantage of it is when we tell the new developer what to do, he just needs to set up his version control client to download the tools (not necessarily the code base) run a batch file and let it download the source code and others. I would also create a separate project tree for Business Analyst and other types of documentation (it may be separate depending on the size).
  5. Since I use Maven 2 : pom.xml + src directory. That's all I need and I can work with Eclipse, Netbeans, IntelliJ or JDevelopper :)
    Slightly off topic, but since you mention JDeveloper, I was wondering if you had a simple solution for integrating Maven 2 with JDeveloper. If so, would you mind sharing? This was a distinct problem that we ran into when adopting Maven as well as trying to figure out what to version control - JDeveloper didn't seem to handle these situations very well. Versioning JDeveloper jpr files and the like seemed very problematic as they have multiple references to directories and local information stored within them, but it also seemed to require fairly intensive work to setup a JDeveloper project from a maven project. Any suggestions that you might be able to supply would be most appreciated. Thanks.
  6. There is a Maven 2 JDeveloper (10.1.3) plugin in the MyFaces project which is going to be repatriated to the Maven project. You can learn more on Maven mailing list.
  7. and even IDE project files
    well, I think storing IDE project files is crucial if You want reasonable collaboration within a team that uses standard tools. Purist praising platform/IDE/tool independence are just to far from reality. You want to check it out and execute, not spend hours to configure your IDE.
    customer invoices, RFPs, copies of emails, agreements, electronic receipts
    .. only if You miss any other documentation ;) What I'm interested in is how you handle generated files? The advantage of having it in repository may be as above, but does it really belong there?
  8. ... and even IDE project files.
    You can run into problems if you version control the IDE project files in the same location where they are used. Move them off to another directory so that you don't replace them underneath someone else's IDE while it is running. Here's an example of the kind of problem this causes. One of our developers switched back to a specific minor point version of JDK 1.4 due to an XML parsing problem that was introduced into the latest version. He changed the JDK in Eclipse and when he did a commit his .classpath and .project files, which pointed to a specific JDK location that only existed on his machine, were checked in. When I did an update CVS overwrote my .classpath and .project files. Since they pointed to a JDK location that didn't exist on my machine Eclipse stopped working. It took over an hour to figure out what was wrong since he didn't realize his JDK location changes had been committed to CVS and I didn't realize that mine had been overwritten. Don't make it impossible for an individual developer to customize his/her environment by version controlling IDE configuration files in the location where they are used.
  9. You guys should really check out Maven 2. There is a slight learning curve up front, but once you get used to using it, you won't want to ever go back to the old way. I've seen projects easily shared between OSX, Windows, and Linux; Eclipse and Netbeans, without the need to check in IDE project files or jars. And it doesn't take hours to configure the IDE, either. All you have to do is: 1. Check out the code 2. Run "mvn eclipse:eclipse" to generate Eclipse project files 3. Run "mvn package" to create Jar/War
  10. Obviously binaries here. I think an ideal system would include a vmware kind of installation, database utilities and version control with complete text source as well as images and binaries. Some have said that word documents with specs or even images would be wrong. I think it's nice to make possible, based on scenario to create a full installation. That is, sources in repository and everything required to make a full install available in source control. It's then a one stop shop. Building a patch should then be also possible without having to reinstall all platform pieces. I've used CVS as part of the build process...there is always the funny catch of checking out the most recent build script (since it's a circular dependency)...that is, how does one have the script call cvs/svn/etc. to "update itself"? Sometimes you can.
  11. Obviously binaries here.
    I think an ideal system would include a vmware kind of installation, database utilities and version control with complete text source as well as images and binaries.

    Some have said that word documents with specs or even images would be wrong. I think it's nice to make possible, based on scenario to create a full installation. That is, sources in repository and everything required to make a full install available in source control. It's then a one stop shop. Building a patch should then be also possible without having to reinstall all platform pieces.
    Sounds like Squeak!
  12. You can run into problems if you version control the IDE project files in the same location where they are used. Move them off to another directory so that you don't replace them underneath someone else's IDE while it is running.
    We rename the files, eg IntelliJ Idea's projectname.ipr file becomes projectname.ipr.template with the project's default settings in it. The template file is then put in CVS. After checking it out, a simple Ant script copies the files, inserts some file paths etc. and you are ready to go... Of course this provides a default setup and not your own personal settings.
  13. I personally recommend that you put into your version control all of the things that will allow you to jump from one machine onto to another, checkout your project, and start your work.
    Being able to switch from one machine to another quickly is important for developer productivity. For some projects however, it maybe be insufficient to version IDE project files only. For example I find it necessary to export Eclipse preferences to re-use settings under Java/Compiler, Team/CVS, and others. That may also fall short of a smooth transition where directory paths are concerned. Eclipse offers something called "Linked Resources" but in my experience that falls short of the goal because it isn't used consistently throughout Eclipse. I've had to develop some custom scripts to help me be able to switch from one machine to another quickly and without effort.
  14. Good idea but unless version control software allows user based file visibility I cant see how my preferences can exist in repository.
  15. Everything[ Go to top ]

    We version control everything - literally everyting - we need to reproduce a ship build. Including the SDK we used on the prodcution build machine and the test data we used. Once in a while - not often, true - we have to recreate a shipped product. Then, man, are we glad we do it this way ! Now of course the machine configuration has to be documented and recreated and that is far from perfect. But we've helped ourselves significantly this way. <<have you ever wanted to eat a laptop, perhaps while shouting "melted butter?">> I prefer jalapeno relish and more spicy condiments. I'd be interested in other developers' views on this issue.
  16. We are checking in to version control almost every file needed to recreate a build There's some discussion as to checking in eclipse project files and some developer's DB setting, otherwise the rest is under version control. I'll go futher and tell: how ofter do you commit to version control? I try to commit every time the code is 'usable/working', I don't like to have 'private' sources hanging around for days on my laptop!!!!
  17. Lastly, have you ever wanted to eat a laptop, perhaps while shouting "melted butter?"
    The thought has occured to me. I think it would taste better than a pickled herring and peanut butter sandiched between two halves of a banana. Floyd
  18. Everything[ Go to top ]

    All my projects have 3 modules at the minimum: - Core: common library set not related specifically to the business - App: the business app that uses core - Resources: custom apps like label makers, documentation, diagrams, etc. My rule of thumb is that anything which cannot or should not be lost goes into version control. So that means almost everything excluding larger commercial application such as IBM RAD, CrystalReports, Intellij, and so on. Technically you could loose those so long as you have your license keys and/or CDs.
  19. ...as many have stated - Maven is the answer. The real question is the development environment so that you can go from 1 machine to another and then check out your project and go. A ghosted "development image" has been my approach in the past, but now I'm considering a VMWare like approach. I'm concerned about the performance though.
  20. This has been hacking in my head for quite a while. I have little experience in versioning. I use CVS and Eclipse out of the box integration. But I do not know when to tag versions, how to identify them, when to branch, and why. Yes, I am wondering about whys and whens more than how-tos. If I want to get back to a version, will the version name tell in wich state the project was? Where is it supposed to be written? Any good book, blog, tutorial on this subject (project management?) would be welcome.
  21. This has been hacking in my head for quite a while.
    I have little experience in versioning. I use CVS and Eclipse out of the box integration. But I do not know when to tag versions, how to identify them, when to branch, and why. Yes, I am wondering about whys and whens more than how-tos. If I want to get back to a version, will the version name tell in wich state the project was? Where is it supposed to be written?

    Any good book, blog, tutorial on this subject (project management?) would be welcome.
    The best book I have found on the subject : http://www.scmpatterns.com/book/ You can see why tools like Maven and Ant are very important.
  22. This has been hacking in my head for quite a while.
    I have little experience in versioning. I use CVS and Eclipse out of the box integration. But I do not know when to tag versions, how to identify them, when to branch, and why. Yes, I am wondering about whys and whens more than how-tos. If I want to get back to a version, will the version name tell in wich state the project was? Where is it supposed to be written?

    Any good book, blog, tutorial on this subject (project management?) would be welcome.
    Please, consider switching to Subversion (subversion.tigris.org). Just to half stay in topic, I keep under version control anything that cannot be generated/acquired otherwise. Normally I use eclipse as IDE, but I don't put project file under Subversion, also because my official build system is based on ANT. Going OT, the whys and whens, well, the role of branches strongly depends on your development model. I have a trunk that is the main development line and create branches if I have to develop variants (for whatever reason) of what is (or was) in the trunk, or even other branches: subversion is great for this kind of stuff. Version tags reflects you naming conventions/release policies. How many levels have release numbers ? What are the conditions that cause the advance of a level ? Guido. P.S. Give a try to TortoiseSVN if you switch to Subversion :)
  23. VSS question[ Go to top ]

    I think revision controlling the binary, source and project files will keep one far from the "melted butter" syndrome. I have a question though, how would you suggest a webapp containing an applet is managed and setup in VSS as part of a continuous integration strategy without creating too many revision controlled files and bearing in mind that I favour controlling binaries?
  24. Checkout and build[ Go to top ]

    My philosophy is that if I can't check-out a project, build it, and package it for release, then my revision control system isn't working for me. Also, keeping vendor depencies out of your VC system can mean that they disappear when needed for older projects. If you use svn:externals (for example) then you've solved most of the problems. They can point to a repo anywhere (including your own), and will exist as one code base for n projects...