Why have all your eggs in one basket?
I’m a great fan of Eclipse but sometimes I’m disappointed with how people use it. I’ll give you a simple example; when you create a Java project you get the option to “Create separate source and output folders“. In my opinion, it’s good practice to always do this - and hopefully there are few these days who would try to argue that having source and generated artefacts together is a good thing.
But why do so many developers stop there; why put your test cases in the same directories as your application classes, why put the configuration in there too? The simple answer is don’t - create additional source folders. Right click the project and select “New->Source Folder” - it’s as simple as that.
Take a simple example where I want to have a “src” folder for my application classes, a “test” folder for my test cases and a “config” folder for my non-Java configuration files.
(click images to see them in detail.)
You can see that although I’ve separated the source artefacts into their relevant folders the output is still as you would expect - or rather how a running JVM would expect.
So, can this be used in more complex scenarios? Absolutely - let’s take the example of a Web Project using the new web tools. For this I’m using Eclipse 3.2.1 with the standard Eclipse extensions for web development.
When you create a new web project the structure it gives you is very similar to the standard WAR file structure - which, if you’re a J2EE developer, is something you’ll be familiar with. It has a single java source folder (called src) which is where you’d put your servlets and other related web application code. Now, it’s simple to apply the same technique as above and create additional source folders for Test classes (e.g test), general configuration (config), and hibernate configuration (config-hib). When you build the output from these all appear in the build/classes directory.
So how does Eclipse know where to put the output? In the previous example it was going to bin. The simple answer is to look at the Java build path; this can be found by right-clicking the project and selecting properties, then “Java Build Path” - make sure that the Source tab is showing.
You’ll notice that for the web project, the default output folder is different. This output folder is where the java builder outputs resources when the project is built. You can use it for non-Java resources because the java builder will just copy them rather than compile them.
So, can we take this further still and populate the WEB-INF directory? Yes you can, but a word of warning; remember that the point here is that we want our directories to contain either source or generated artefacts. Therefore, we’d also need to remember to copy out any resources before we set it as an output folder - in this case that’s only web.xml.
If you look more closely at the Java Build Path dialog, you’ll see there’s a check box to “Allow output folders for source folders”. Click that and you can specify a non-default output for any of the source folders. So for our example, I’ll create two new source folders webfiles-main (to hold my web.xml) and webfiles-foo to hold resources relating to the Foo part of my application.
Now we have specified the WEB-INF as output to these two new source folders - all the other folders have retained the default output location.
This isn’t the only way to achieve this sort of behaviour - you do not have to have all your resources within the Eclipse workspace. Resources can be linked into the workspace from any location on disk. There are a few ways to do this, most commonly when creating a new file or folder you can click the “Advanced >>” button to declare the resource as linked and provide the actual location. Also, you can do this on the Java build path page by clicking the “Link source” button.
I’ve left this linked method until last because it’s not going to work as often as the earlier techniques if you work in a team. Unless you have draconian standards to mandate development processes, it’s unlikely that every member of you team will have their workspace in the same location and it’s quite possible that they may even use a different operating system! In these scenarios you should be very wary of using linked resources.
One final point - some Eclipse based products may have linked resources turned off by default. If you do feel the need to use them you can re-enable them by going into the workspace properties. Have a look in either “General->Workspace->Linked Resources” or “Workbench->Linked Resources“.