Basic Subversion Question

I created a Java Project in Eclipse using the Web services Top down approach (i.e. creating a WSDL file and using it to generate the Skeleton Java class and web services with axis2) (Hence, there are a lot of auto-generated files and axis2 jar libraries).

My Project has the following files/directory structure

- Deployment Descriptor         
- build              
- build.xml                 
- doc (i.e. generated javadoc)         
- src     
  - com.package1
  - com.package2
  - Libraries
    - Apache Tomcat 6.0 (apache jar files)
    - Web App libraries (axis2 jar files)
- lib (containing external jar files)          
- resources     
- WebContent           
  - axis2-web           
  - META-INF    
    - MANIFEST.MF    
  - WEB-INF 
    - classes
    - conf
    - lib
    - modules
    - services
    web.xml
`- wsdl (contains WSDL file`)

I want to import this project into a subversion repository on a remote host. Which files should be imported in order to ensure anybody checking out this project can have it up and runni开发者_开发百科ng quickly? As per my understanding, we DO NOT import jars, class files, into subversion repository. What should be the best approach here? I am especially unsure of all the web app axis2 and tomcat libraries, and directories like axis2-web, META-INF, WEB-INF (in WebContent)

The guidelines we use are:

• Commit all the project-specific files
• Don't commit file which can be created by the IDE or build scripts ( transient files )
• Dont commit workspace specific files, except in a "workspace template" area, because they usuaally contain machine-specific paths or data
• Shared files should be on a "shared" or "lib" project

The last point is similar to what maven does: store the libs not in each project, but in a common area.

So applying these guidelines to your project:

• Deployment Descriptor : commit
• build : don't commit ( generated )
• build.xml : commit
• doc (i.e. generated javadoc) : don't commit ( generated )
• src
  • com.package1 : commit
  • com.package2 : commit
  • Libraries: commit only the directory. See note below
  • Apache Tomcat 6.0 (apache jar files)
  • Web App libraries (axis2 jar files)
• lib (containing external jar files) : commit only the directory. See note below
• resources : commit
• WebContent
  • axis2-web : commit the dir, and contents if there is anything specific
  • META-INF
  • MANIFEST.MF : commit
  • WEB-INF
  • classes : don't commit ( generated )
  • conf
  • lib : commit only if not generated. It depends on how you set up your build scripts
  • modules : commit ( I guess it´s not generated )
  • services : commit ( I guess it´s not generated ) web.xml commit - wsdl (contains WSDL file) : commit

Regarding the lib directories, what we did in several of our projects before using maven, was that each developer downloaded the required jars/libs from a central "libs" project, which contained the jars in a directory structure similar to what maven does ( vendor/libs/versioned jars ). This helped to reduce the project checkout times, and avoided having libraries copied all over the different projects.

However, in other settings these where not issues, and we preferred to just commit the libs in the project "lib" directory. So each checkout took a little more, just some minutes; having copies of libraries wasn't a problem since there where few projects, and it made the checkout process simpler ( just one checkout and you had everything in place ).

I don't remember any other guideline at the moment :)

Since I don't see pom.xml in your project I assume that Maven is not used and your libraries cannot be brought automatically after checking out your project. That simply means you have to share all your libraries through SVN. The only folder I wouldn't share is 'doc'- those can be regenerated.

UPDATE: The ultimate way would be to setup your project to use dependency management system such as Maven or Ivy. Then you don't have to keep the libraries is your source management system and people checking out your project will have a quick way to have it up and running.