Eclipse: how to keep project source files and ant build.xml seperate from eclipse workspace?

Question

I'm trying to re-familiarize my self with the Eclipse environment and ant integration.

Question is: how to keep my sources dir + build.xml separate from the workspace?

What I have is a small java project and its build.xml file with all the sources placed under a separate project folder. I then started Eclipse and let it import my project via New Project -> "Java Project from existing Ant Build File"

All went fine, until when I wanted to build the project from inside Eclipse using build.xml. Ant starts complaining about not being able to find the source tree. After I examined the workspace I found that Eclipse had copied the build.xml into the workspace, so it's obvious that ant couldn't find any sources there. They are still under my project director and I do want to keep them there, if possible.

so whats the best way so make this setup work? workspace on one side, my project on the other?

Thank!

edit: Is what I want even possible ?

Fortaleza

Why do you want to separate them? Is there some specific reason? – Humpback

Perhaps, you can specify the directory at which the execute the build script, so you can run it although it is copied in new location. Look at the other suggestions as well. – Vinasse

Because Netbeans can do it ;) – Burkey

You can do exactly what you want (To keep project and work-space folders separate) using eclipse IDE. Follow these steps. 1. Create new java project. 2. Import >> File System >> Select project folder (buid.xml files) 3. Click Advance ( Select Create links in workspace ) ScreenShot This will create link to actual project in your work-space. – Coloring

Answer 1

Instead of using "Java Project from Existing Ant Buildfile", just create a simple "Java Project". In the wizard uncheck "use default location" and enter the path (or browse) to the top level directory of your existing project (i.e., where your build.xml is). True, eclipse will create .project and .classpath files in your project directory (if they do not already exist), but the project will remain outside the eclipse workspace.

Case in point, this setup has worked really well in a very particular situation on a standalone system where the source tree resides in a common location but each user has a workspace in a protected location. Using the method described above, each user of this system can create a project in their own eclipse workspace, execute ant targets and subsequently remove the project from their own workspace without affecting other users' workspaces.

Misfortune

When I point Eclipse to the location of my existing project it says that dir is already in use even though it's not an Eclipse project, it's just a plain ant project. Using Helios 3.6.2. – Burkey

I cannot reproduce this particular error with Helios 3.6.2 or Indigo 3.7 on OS X. The only time I have ever encountered a conflict error like this with eclipse was in trying to use a workspace that is already in use, or at least appears to be so (stale workspace metadata can do this). However, in trying to replicate this error, I found that I can actually repeat the suggested process above with two simultaneously running eclipse instances, using two different workspaces, and both pointing to a common project directory outside of either workspace without any problem. – Misfortune

Answer 2

What about using links?

• Windows Symbolic Links
• Linux man page for ln

Phantasy

That's a sound idea. Thx. I guess my concerns about keeping project and workspace as separate as possible aren't really an issue out there, b/c I couldn't find much on the subject. It seems that everybody is happily mixing them both under one single directory. But from a conceptional POV I'd think there should be distinction between IDE workspace and the project itself. Where the project shouldn't have any close ties to the IDE. Well maybe I'm just rambling... – Fortaleza

Answer 3

I do this all the time in C++ projects (no Java, sorry, but I think the concept is portable).

I have my workspaces in ~/workspaces/{workspace_name}. I have a single shared project file in ~/{my_projects, and then the source trees (multiple versions) are in ~/proj1, ~/proj2, etc.

Within each ~/proj* directory, I put a symlink to ~/my_projects/.project and .cproject (required for C++, not used in Java). So each source tree is sharing the single project file. Then in each workspace (one for each source tree), I configure the workspace by importing the project link. For example, ~/workspaces/proj1 imports ~/proj1/.project, but ~/proj1/.project is actually a symlink to ~/my_projects/.project.

So this keeps the source separate from the workspaces. When building, there's no real configuration to do -- I just have Eclipse run make in the appropriate node of the tree -- we already have our own command-oriented build system (we're not using ant, but the same principle should apply).

I source-control the ~/my_projects folder in a private area of the SCM, so other team members don't see it or fiddle with it -- many of them don't use Eclipse at all.

Cutinize

Answer 4

There isn't really any need to try and avoid Ant and Eclipse using the same set of source files. In fact, its probably better that they do use the same set.

Bear in mind, you're not actually mixing anything. There is just one set of source files and then there are two different ways of building it; Ant and Eclipse. These builders are independent of each other, so there is no problem with being coupled to Eclipse. You can even happily commit all the eclipse files (.classpath, .project, .settings) to source control without affecting any developers who use a different IDE.

Pyrogen

When I still used to develop with E I experienced quite often a corrupted workspace, and b/c of the source files were in different location other than the workspace I was able to easily remove the broken workspace and replace it with a fresh one without affecting the project itself. I may be wrong but the build.xml that I used then was always located with the project itself and never under the workspace. I think I used Eclipse for incremental builds, but for deployments, DB setups and unit testing I regularly used my build.xml targets from the ant view inside Eclipse.Sadly I forgot how 2 do it – Fortaleza

Commiting IDE project files is a bad idea. From my experience they include user specific home dir paths so they are not reusable between developers. – Burkey

@leif81 The bad idea is putting user-specific information in your project configuration and it is also unnecessary. I can't speak for other IDEs but Eclipse provides features that allow your config files to contain placeholders which can then be specified by each developer in their workspace. e.g. classpath variables, run/debug string substitution. – Pyrogen

@Kevin, I was speaking regarding experience with Netbeans, perhaps Eclipse handles it better. – Burkey

Answer 5

I do this all of the time (admittedly using maven, not ant), but the same principle applies.

If you have an existing project in Eclipse (with the .project in the source tree), then you can Import Project->Import Existing Project. When the dialog box comes up, you can choose to 'Copy projects into workspace'. Make sure this is unchecked, and them import.

You still store the .project in the original source tree, but thats all.

So now I have

1. code/xxx (which contains the .java files, which are in SVN)
2. code/xxx-workspace (which contains the eclipse workspace)

Nu