当前位置：文江博客话题详情

流行的构建文件夹结构

发布于 2024-07-12 08:40:38 字数 37 浏览 5 评论 0原文

我想知道在项目中组织构建资产和源代码的流行或最佳方式是什么？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

樱＆纷飞 2024-07-19 08:40:38

，您必须

/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 中，但它们出现在某些项目的其他位置（例如在 /websites/ 中）。

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

回复收藏 0 原文

緦唸λ蓇 2024-07-19 08:40:38

一般来说：

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)

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)

回复收藏 0 原文

耳根太软 2024-07-19 08:40:38

由于我只处理 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.

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.

回复收藏 0 原文

凡间太子 2024-07-19 08:40:38

例如，我将以下内容用于我的 .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

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

回复收藏 0 原文

拥抱影子 2024-07-19 08:40:38

此文件夹组织代表 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

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

回复收藏 0 原文

为你拒绝所有暧昧 2024-07-19 08:40:38

我个人使用

/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 开发树生成器。只需给它您的项目名称，它就会在几秒钟内为您建立一个开发树。不仅如此，您的新树还内置了多年积累的构建工程经验。

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 原文