views:

1387

answers:

7

I am wondering what the popular or best way to organise your build assets and source code within a project is?

+3  A: 

for example, I use the following for my .Net style projects;

/build/reports  - reports and logs from the build process
/build/artifacts  - all output of the build process is copied here
/src/  - all solution source code
/lib/  - 3rd party or other build dependencies
/tools/...  - all other helper tools used in the build process
/tools/nant  - example tool
/tools/nunit  - example tool
/myProject.sln  - visual studio solution file (or other IDE)
/default.build  - nant build file
Xian
what about "source" libs (3rd party libraries you build yourself or inhouse libraries?)
Johannes Rudolph
Do exactly the same as above. Re 3rd party source, they're often not needed in the project directory. I typically keep the source of any open source stuff in a separate repository just in case I need it one day, but otherwise use a versioned lib in the "lib" folder
Bealer
+3  A: 

As I am working only on Java projects, and all of them are "Mavenized", I use the conventions defined by Maven for the project structure.

Basically:

project
  src/main/java        --> source files
  src/main/resources   --> resources files (*.xml, *.properties, etc.)
  src/test/java        --> source files for tests.
  src/test/resources   --> resources files for tests.
romaintaz
+2  A: 

In general:

src/      - source files
src/tests - unit tests
doc/      - documentation
res/      - static resources (textures, locale database, level definitions etc)
build/    - tools needed to build the system
            project specific libraries and compilers
Makefile  - the makefile (make, test, clean etc)
Martin Wickman
+1  A: 

Personaly I use

/client/projectname/trunk/source/Solution Name.sln
/client/projectname/trunk/source/Project.One
/client/projectname/trunk/source/Project.Two
/client/projectname/trunk/source/Project.Three
/client/projectname/trunk/source/SQL/
/client/projectname/trunk/source/SQL/SomeScript.sql
/client/projectname/trunk/libraries
/client/projectname/trunk/resources/Nunit
/client/projectname/trunk/resources/LLBLGEN
/client/projectname/trunk/documentation
/client/projectname/trunk/builds

It works fine for us but I don't think it's the best. If it's about .net you can also take a look at treesurgeon They describe it themselves as:

Have you ever spent a few days setting up a new development tree? Have you ever spent several days setting up several development trees? Have you even spent weeks trying to perfect all your development trees using a set of best practices?

If the answer to any of the above answers is 'yes', then you'll like Tree Surgeon!

Tree Surgeon is a .NET development tree generator. Just give it the name of your project, and it will set up a development tree for you in seconds. More than that, your new tree has years worth of accumulated build engineering experience built right in.

olle
A: 

I like the way the Netbeans IDE organizes projects. Just start a new project, and it will set-up a default development tree and an ant script.

+3  A: 

I have

/src    - source files (test files are within a package 'test' here, or 'test' subpackage of what is being tested)
/lib    - required libraries
/doc    - text documentation and development notes
/build  - where we build (each separate build item within a subfolder here)
/conf   - configurations (each config, production, test, developer, etc gets a folder in here, and when building Jars and Wars the correct set is copied across)
/extras - other stuff
/extras/resources - resources that should be included within generated Jars, e.g., icons

with

/websites - Web related content and configurations (each website in its own folder here)
/websites/$site/webcontent - All the web content here
/websites/$site/conf - website related configuration files here (instead of /conf)
/websites/$site/build.xml - ANT build script for website that creates a war, etc

(remember you might have an admin site and a public site for a single project, hence the multi-site configuration within a single project, or even site v1 and site v2, etc)

In the end you have to be a bit flexible depending on the project itself, and whether you use ANT or Maven. I use ANT, and either put the ANT scripts in /build, but they have appeared elsewhere in some projects (like in /websites/ for some).

JeeBee
+1  A: 

This folder organization represents evolution of xLim concepts.

You can check it out in this open source project.

Build           - ignored from version control
  Artifact      - build artifacts (grabbed by CC.NET from here)
  Package       - generated zip or install packages
  Test          - all assemblies for unit tests
  Help          - autogenerated documentation
Resource
  Build         - plugins and extensions for NAnt/MSBuild
  Library       - 3rd party dependencies
  Tool
    FxCop
    ILMerge          
    NCover
    NCoverExplorer
    NUnit
    SHFB
    Wix
Samples
  SampleProject1
  SampleProject2  
Source
  Project1
  Project2

  GlobalAssemblyInfo.cs
  VersionAssemblyInfo.cs   - integration server updates this one

Test
  Project1.Tests
  Project2.Tests        

Solution.build        - primary build file
Solution.ccnet        - CruiseControl adapter for the build file
Solution.sln          - Visual Studio

go.cmd                - shortcut for launching the build file locally
readme.txt            - licenses and overview
SharedKey.snk         - for strong naming
Rinat Abdullin