build process - tortoise - Estructura de carpetas populares para compilación

tortoise svn server

Question

Me pregunto cuál es la mejor forma popular de organizar tus recursos de compilación y tu código fuente dentro de un proyecto.

Answer 1

Como estoy trabajando solo en proyectos de Java, y todos ellos están "mavenizados", utilizo las convenciones definidas por Maven para la estructura del proyecto .

Básicamente:

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.

Answer 2

En 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)

Answer 3

Esta organización de carpetas representa la evolución de los conceptos de xLim .

Puedes verlo en este proyecto de código abierto .

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

Answer 4

Me gusta la forma en que Netbeans IDE organiza proyectos. Simplemente inicie un nuevo proyecto y configurará un árbol de desarrollo predeterminado y un script ant.

Answer 5

Personaly uso

/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

Funciona bien para nosotros, pero no creo que sea el mejor. Si se trata de .net , también puedes echarle un vistazo a treesurgeon. Ellos mismos lo describen como:

¿Alguna vez ha dedicado unos días a configurar un nuevo árbol de desarrollo? ¿Alguna vez has pasado varios días armando varios árboles de desarrollo? ¿Has pasado semanas intentando perfeccionar todos tus árboles de desarrollo usando un conjunto de mejores prácticas?

Si la respuesta a cualquiera de las respuestas anteriores es ''sí'', ¡entonces te gustará Tree Surgeon!

Tree Surgeon es un generador de árbol de desarrollo .NET. Simplemente déle el nombre de su proyecto, y configurará un árbol de desarrollo para usted en segundos. Más que eso, su nuevo árbol tiene años de experiencia en ingeniería de construcción acumulada.

Answer 6

por ejemplo, uso lo siguiente para mis proyectos de estilo .Net;

/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

Answer 7

yo tengo

/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

con

/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)

Al final, tienes que ser un poco flexible dependiendo del proyecto en sí, y si usas ANT o Maven. Yo uso ANT, y pongo los scripts ANT en / build, pero han aparecido en otros proyectos (como en / websites / para algunos).

Answer 8

Para mí, depende del tamaño del proyecto. Para proyectos pequeños, encuentro que un directorio de proyecto con un único directorio Makefile, / src y / include funciona bien.

Answer 9

Para proyectos de .NET, compruebe ProjectScaffold y analice este tema.