Tapestry Training -- From The Source

Let me help you get your team up to speed in Tapestry ... fast. Visit howardlewisship.com for details on training, mentoring and support!

Friday, July 22, 2005

Don't shit where you eat

I made a recent change to the set of build scripts used by Tapestry and by HiveMind; it no longer builds inside my workspace. Let me explain why this is a good thing.

Your workspace is supposed to be a local image of the files stored in your source code repository, so that you can make changes to those files, then follow a compile/test/fix cycle, and eventually check the source files back in.

A common problem in many projects is when derived files, .class files, or .jar files, get accidentally checked in to a project repository. This can cause a lot of confusion, and may be difficult to clean up.

But more importantly, I've noticed when using Eclipse is that the number of files (not source files, but file system files) in my workspace affects the performance of the IDE. Somewhere, in the background, it is constanty checking for changes and re-indexing files using Lucene. Builds of Tapestry and HiveMind create a huge amount of documentation ... Javadoc, HiveDoc, test reports, clover code coverage and so forth. Thousands upon thousands of files ... none of which are interesting to me as a developer.

In the old scheme, all the output classes and jars and instrumented Clover source files, and everything else, were in target directories inside the workspace.

That's whay I mean about shitting and eating; it's better to stay clean.

What I did was change my Ant build files to create the target directories under ${java.io.tmpdir}. That is, a shadow project structure is created there, directories like C:\WINDOWS\TEMP\jakarta-tapestry\workbench\target. Just about everything goes there, except for a handful of output jar files (as a convienience) and some Forrest files (out of necessity).

My builds and my IDE run better and faster now. I think this is a model that should be followed by other build tools, such as Maven.


Barry Kaplan said...

I generally turn off automatic workspace refresh because I use smartcvs along with eclipse. When doing an update with smartcvs eclipse would thrash big time. You can change this in Preferences->Workspace.

However, when you do decide manually update workspace, it may still take a long time.

Patrick Lightbody said...

In IDEA, you can exclude certain directories such that they won't be indexed. My common build system excludes the "build" and "dist" directories.


Brett Porter said...

Interesting topic... gross headline.

I was under the impression Eclipse had a similar setting to IDEA as patrick mentioned.

That's probably a better alternative as you don't have issues with clashing with other users on the same system. Also, on some systems /tmp is in swap space which would degrade performance far worse than Eclipse's syncing :)

Certainly worth a FAQ entry though.

Jared said...

Yep. Building in your workspace is generally a "bad thing". Sort of makes you wonder why that's the default way of doing things . . .

Naresh Sikha said...

I step around this problem by creating two Eclipse workspaces - one that contains the project under development, (e.g. "jakarta-foo") and another that contains the "work" project (e.g. "jakarta-foo-work") that's also in CVS.

The advantages to this approach are that the work project can be mounted in Eclipse or not and that the work project can assemble output from multiple projects (e.g "jakarta-foo-core" and "jakarta-foo-ext").

This just formalizes the "toilet" as being another project in source control.

Pazu said...

Howard, there's a reason you usually generate your project artifacts inside your project root: they are, undeniably, part of your project.

Now, I don't think it's fair to twist that and hack the build system to generate important artifacts outside your project root just because your IDE can't cope efficiently with that. Can't you tell eclipse to, let's say, ignore the "target" directory?

shin said...

Hello Hive.