Популярная структура папок для сборки

Question

Мне интересно, какой популярный или лучший способ организовать ваши ресурсы сборки и исходный код в проекте?

Answer 1

у меня

/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

с

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

В конце концов, вы должны быть немного гибкими в зависимости от самого проекта и от того, используете ли вы ANT или Maven. Я использую ANT и либо помещаю сценарии ANT в / build, но они появились в других проектах (например, в / website / для некоторых).

Answer 2

В целом:

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

Поскольку я работаю только над проектами Java, и все они "Mavenized", я использую соглашения , определенные Maven для структуры проекта .

В основном:

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 4

например, я использую следующее для моих проектов в стиле .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 5

Эта организация папок представляет собой эволюцию концепций xLim .

Вы можете проверить это в этом проекте с открытым исходным кодом .

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 6

Лично я пользуюсь

/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

У нас это хорошо работает, но я не думаю, что это лучше. Если речь идет о .net , вы также можете взглянуть на TreeSurgeon Они сами описывают это как:

Вы когда-нибудь проводили несколько дней, настраивая новое дерево разработки? Вы когда-нибудь тратили несколько дней на создание нескольких деревьев разработки? Вы даже потратили недели, пытаясь усовершенствовать все свои деревья разработки, используя набор лучших практик?

Если ответ на любой из приведенных выше ответов «да», то вам понравится Tree Surgeon!

Tree Surgeon - это генератор деревьев разработки .NET. Просто дайте ему имя вашего проекта, и он за несколько секунд создаст для вас дерево разработки. Более того, в вашем новом дереве накоплен многолетний опыт проектирования сборки.

Answer 7

Для проектов .NET отметьте ProjectScaffold и обсудите это gist .

Answer 8

Для меня это зависит от размера проекта. Я считаю, что для небольших проектов хорошо работает каталог проекта с одним каталогом Makefile, / src и / include.

Answer 9

Мне нравится, как среда IDE Netbeans организует проекты. Просто запустите новый проект, и он настроит дерево разработки по умолчанию и скрипт ant.