File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes IDEs, Version Control and other tools and the fly likes Keeping Project Metadata in Source Control Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Engineering » IDEs, Version Control and other tools
Bookmark "Keeping Project Metadata in Source Control" Watch "Keeping Project Metadata in Source Control" New topic
Author

Keeping Project Metadata in Source Control

Gregory Smith
Greenhorn

Joined: Jun 07, 2007
Posts: 3
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.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16303
    
  21

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.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16303
    
  21

Moved to "IDES, Version Controls and other tools" at Greg's request.
[ June 07, 2007: Message edited by: Tim Holloway ]
Gregory Smith
Greenhorn

Joined: Jun 07, 2007
Posts: 3
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.

Thanks.
Gregory Smith
Greenhorn

Joined: Jun 07, 2007
Posts: 3
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Keeping Project Metadata in Source Control