How to make a project "repository/team" ready

Question

I have been working solo on a project for some time, and now, new developers are likely to join the project for various reasons.

I, of course, use a version control software but I am afraid importing my project into Eclipse and making it run might prove a little difficult for new comers, and I want to make it as clean as possible.

When I first took over the project, it took me almost two days to have the project built and run it, I documented every step and fixed the most obvious errors, but not all, and I want the project to run as it is when imported.

• The project is a mix of java projects for the backend, a j2ee project for the server and a flex project for the client.
• The IDE is going to be Eclipse
• The version control software is Perforce

Here are some of the specific problems I have right now, should I fix them, and how ?

1. Eclipse environment variables are used for libs, all the libs are in a folder in the j2ee project but are used by all the java projects (they have to be set in each IDE the project is imported into)
2. Runtime JRE is specified in .classpath for each project, so each projects property must be edited when trying to build the project in another environment
3. Apache server is specified in j2ee project property
4. To avoid exporting the jars of all the java projects into the j2ee project each time I modify the code, there are linked folders in the j2ee projects, linked to each java project bin folders

For (4) I will probably have to use maven, but is it possible to fix problem (1) (2) and (3) without using maven ?

The alternative is to have a one page set up instruction document

Also do you have any other general or specific advices as to how organize this whole mess.

Thank you

Answer 1

1. Dependency management is a must - use Maven. If you can't use maven, because you are already using ant, go with Ivy.

2. Make the project buildable with one click - be int ant build all or mvn package. Maven provides integration with the IDE (via the plugin).

3. Don't reply on IDE metadata. like .project and .classpath. You can still commit them to ease Eclipse users though, but don't restrict the IDE.

4. Provide build-on-save. Either using Eclipse WTP, or using the FilSync plugin (it sounds like a hack, but is pretty cool)

5. Use build profiles (maven provides them automatically) - to create different builds for different environments

6. It's not always possible to configure everything in your maven (or ant/ivy) scripts. For any additional actions, like installing app server - document then in a single file in the root of your project, describing step by step what should be installed, with what config options, etc. Thus the developers have only one place to look at and follow. The document can (and better) be plain .txt

7. A sidenote: use Continous Integration - download Hudson or TeamCity and configure it to build a project

From my very recent experience - we had a project we've been working on for 6 months. A colleague of mine had to re-import the project on a new machine. It took him 20 minutes. The project is configured with Maven.