richardlog

On Java, Agile, Open Source, Architecture and anything in between

Putting Talend Open Studio projects under version control

When you are working on OS X - I’m not sure if other OS’es have the same issue - your Talend Open Studio workspace is located under

/Applications/TOS-<version>/TalendOpenStudio-macosx-carbon.app/Contents/MacOS/workspace

That’s right the workspace is placed inside TalendOpenStudio.app, which isn’t a very convenient place. Although Talend Open Studio is based on Eclipse it isn’t keen on moving your workspace to a different location. The easiest way around this issue is to replace the above workspace directory with a symlink: 

ln -s ~/workspace

From now on all your Talend jobs are created in a workspace under your home directory. To put the contents of this workspace under version control I recommend the following principles (source: bowerstudios.com):

First, avoid Subversion/CVS as they will likely get you into trouble since they add info to each directory that is in version control. Talend Open Studio (TOS) tends to wipe out directories and recreate them, so you will have problems with those two tools complaining that they have lost information. Try to use a tool that does not add per directory entries (like git). I chose git.

You will need to enter the entire workspace into version control, including the hidden metadata and compilation directories (.metadata, .JETEmitters and .Java). With each commit, make sure you grab all of those files that have changed.

For each commit, do not commit until after you have exited TOS.

If sharing across platforms, or with other developers, you may need to keep track of the different paths on your machines:
For example, when you export a job, it will successfully export, but with previously compiled classes if the .classpath file in the .Java directory contains paths not on your local machine. Another way to put it, If someone else commits the project, you check it out, you make changes, you export it, the running code will not reflect the changes you made, even though the source does reflect those changes.

While versioning an entire workspace isn’t ideal it’s the one solution that’s guaranteed to work. If you can suggest better alternatives please let me know.

Finally to verify whether your workspace is still valid after performing the above, just open a job and click on the ‘code’ tab. If you see generated Java code you know your workspace isn’t corrupted.

Good luck!