I am wondering what the popular or best way to organise your build assets and source code within a project is?
Asked
Active
Viewed 3.4k times
9 Answers
19
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
- 17,476
- 5
- 50
- 60
13
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
- 19,662
- 12
- 82
- 106
5
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
- 76,121
- 12
- 43
- 49
-
what about "source" libs (3rd party libraries you build yourself or inhouse libraries?) – Johannes Rudolph Oct 11 '09 at 13:27
-
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 Apr 26 '10 at 12:15
5
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.
Romain Linsolas
- 79,475
- 49
- 202
- 273
-
-
@YoushaAleayoub anything you may need to run your tests that is not directly code (such as an XML or JSON file, used in the test itself for example). – Romain Linsolas Mar 05 '17 at 22:29
3
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
- 23,036
- 8
- 57
- 80
2
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.
0
For me it depends on the project size. For small projects, I find that a project directory with a single Makefile, /src and /include directory works well.
jdmartin86
- 299
- 2
- 16
