We use Subversion (SVN) to keep our projects in Source Control. We create a new branch in subversion each time we begin developing a new release. We have been using JBuilder for many years. Jbuilder is very friendly to this process in that nearly all of the metadata for a project can be stored with the project and when any developer retrieves the new branch for the project from SVN, JBuilder is able to open, build and run the project without problems.
JBuilder stores the project metadata in a .jpx file as well as .library files specific to the project. It can use either relative or absolute paths for this data, so you can move your project around in the directory structure and JBuilder can still handle building and running it. The web server configurations still have to be setup for each user, but they can remain the same as we change to new branches.
I have been tasked with migrating our projects to Eclipse, but as far as I have been able to determine, Eclipse just can't handle this sort of usage. Eclipse is based on workspaces (where it stores its .metadata directory) and then on .project and .classpath files for each project under the workspace. To simplify moving to Eclipse, we created Ant build.xml files for each project. But there is still a fair amount of configuration that each developer will have to do for each project every time we start a new development cycle.
Does NetBeans handle this kind of problem more gracefully than Eclipse?
Also, one of the reasons for using Ant (in addition to its portability) was that Eclipse did not handle building multiple targets (jar, war, & ear files) in the same project. JBuilder handles this beautifully.
Does NetBeans allow you to have multiple targets in the same project?
I would be interested in what anyone has to say regarding these topics.
All the files in an eclipse project directory can be safely archived -- and shared -- between multiple users. The per-user data is all kept elsewhere.
In fact, I highly recommend that the .project file be archived in source control - it tells the IDE where the jarfiles and build paths are.
The only restriction is that the same paths be in use for all users, since these are filesystem paths. However Eclipse will use relative paths and symbolic names, so that's not as onerous a restriction as it might seem.
FWIW, IntelliJ projects come with 3 XML project files. Two of them (the project and module files) are safe to place under source management as well. The third (I think it's the IWS file) is per-user and should be on the svnignore list.
Another nice thing is that if you have an especially free-wheeling shop, the same source archive can house a project with both Eclipse and IntelliJ project control files - they have to be kept up to date independently, but they won't conflict in any way.
Customer surveys are for companies who didn't pay proper attention to begin with.
Moved to "IDES, Version Controls and other tools" at Greg's request. [ June 07, 2007: Message edited by: Tim Holloway ]
Joined: Jun 07, 2007
We use the branch-merge Subversion development policy. All new development is always done on a newly created branch copied from either the trunk or another branch. The Eclipse workspace's .metadata directory does not lend itself to being stored in SVN because Eclipse is continually creating and deleting files in the .metadata and without any interaction with SVN.
So without the .metadata directory in SVN, the other project files such as .project and .classpath and the .externalToolBuilders directory (since we are building with Ant) don't do any good. They are essentially orphaned. Eclipse does not have an option that I know of of opening a project that wasn't created in the current workspace. You have to create a new project. You can create it from existing source, or from an ant file, but not from an existing .project file. If I am wrong about this, please let me know how this is done.
Joined: Jun 07, 2007
Well I kept looking for information on this and I finally found out how it is done. It is well-documented in Eclipse's voluminous Help system. Just search on "subclipse".
In the search results it is under Tips and Tricks. It is an article entitled, "Using a Working Copy outside the Workspace". The key here is using File > Import.
The image in the article for the import dialog was a little outdated. In Eclipse 3.2.1 (the version I am using) the "Existing Projects Into Workspace" option is under "General" in the Import dialog.
I have tested this and it works perfectly. I assume the same would hold true for a CVS project.
Note: You still would not be storing your workspace's .metadata directory in SVN (or CVS). Each developer would need to set up his workspace individually. But this is still much better than the prospect that I had been facing.
subject: Keeping Project Metadata in Source Control