Versions Compared

Old Version 6

changes.mady.by.user Alex Huang

Saved on

compared with

New Version 7

changes.mady.by.user Alex Huang

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

CloudStack development environment has gone through quite a bit of changes lately.  For people who are developing on CloudStack, these changes have caused quite a bit of confusion.  I'm documenting these problems here and the solutions to each.

Dealing with

...

  • Setup a separate source repo and Eclipse workspace for each branch.  Don't mix the branches.  With CloudStack development changes in maven, packaging, and breaking into smaller modules, using one local repository for different branches really does not work.  Eclipse re-compiles each time you switch branches because directories are different.  Until these things have settled down, the best thing to do is to setup a separate source repo for each branch.
  • If you've been updating the source repo from an older version, you should clean out the bin directory and .project files.  The best may be to start with a clean repo and workspace and import the maven projects again.
  • Setup the eclipse profile in Eclipse.  Eclipse needs to manage the files that it generates or else it will keep re-compiling and re-indexing.  Unfortunately, by default, eclipse m2e uses the same target directory in the pom.xml as the place where eclipse holds the files.  That slows down Eclipse and your computer significantly.  CloudStack is setup to deal with that with a script file that adds the eclipse profile to every Eclipse project.  You can take advantage of that by running the script from the top of your source tree.
    • Code Block
      
bash -x tools/eclipse/set-eclipse-profile.sh
  • Setup working sets for Eclipse.  Open Resource Dialogue (Shift-Ctrl-R) in Eclipse is one of the fastest ways to get to a file you know about.  However, with the nested projects in CloudStack, this dialogue gets rather confusing because files of the same name appear from both the project itself and the parent project.  Working Sets are the best way to get around this problem. 
    • Hit Shift-Ctrl-R to open resource dialogue
    • Click on the down arrow in the upper right of the dialogue box
    • Click on the Edit Active Working Set from the drop down menu
    • Create a working set called cloudstack
    • Add all of the projects to it and then remove the parent projects.  The reason you want to remove them is because they’re parent projects and when you open resource, the open resource dialogue gets the .java file from both the actual project and the parent projects so the same .java file appears more than once.  Here's the list of projects: Cloudstack-framework, Cloud-engine, Cloudstack, Cloudstack-plugins, Cloud-services, Cloud-apidocs.
    • Click on finish.
    • Click on the top right drop down button again
    • Make sure “Show derived resources” is not checked
  • Consider creating multiple working sets.  Put your most commonly used files in one working set so you can actually access them.
  • Use Indigo release.  Juno release is infamous on poor performance.  You can google it yourself.  I've tried SR2 for Juno and it's still slower than Indigo.

Dealing with Windows and Cygwin

  • Don't use spaces in Windows.  Windows and cygwin just don't play well with paths with spaces in them.  I even create a top directory called bin and put all of my java, eclipse, cygwin, maven, mysql and other directories in it.  Just so I don't have to deal with the spaces issue.  You have to be diligent because JDK and other installations want to install in Program Files or Program Files (x86), just change the path to bin.
  • Make use of the mklink feature in Windows.  Windows comes with a little known utility to make symbolic links.  Here are the type of things I do with this utility.
    • Create a current link to all the software that have version updates and have environment variables.  For example, for JAVA_HOME, my environment variable is JAVA_HOME=c:\bin\Java\current and current is a symbolic link to the JDK version I installed.  This way, I don't have to change the environment variable each time I update JDK.  I just change the symbolic link.  You can also leave the old version there in case of problems and revert easily.
    • I create a link to genisoimage.exe called mkisofs in the cygwin bin directory.  Now you don't have to download the mkisofs file.
    • I create a link to python2.7 called python in the cygwin bin directory.  Now you don't have to download a separate version of python.
  • Add the following to your /etc/fstab: "/cyg cygdrive binary,noacl,posix=0,user 0 0".  This line does two things.  Instead of /cygdrive/c to change to a different drive, you type /cyg/c which is much shorter.  It also removes the posix acl semantics which causes problems with the build because the build tries to manipulate file permissions and causes big problems with the Windows file system.
  • Download systeminternals tools from Microsoft.  It comes with a little handy utility called handle which tells you which process owns a handle to your file.  With Java and Cygwin, it's sometimes difficult to know who still owns a handle to a file.  Unlike Unix, Windows doesn't let you delete a file when a handle is still open on it.  With this utility, you can figure out the process and kill the process.