[Proposal]Standardize project output documents and simplify the way of making install

[gxthrj]

1. Distinguish development documents & deployment documents;
2. Independently compiled directory structure;
3. Unified management dashboard and manager-api packaging method (independent & combined);

[gxthrj]

I recommend turning the project into a directory structure like this

apisix-dashboard
├── .actions
├── .github
├── README.md
├── api
│   └── makefile
├── dashboard
│   └── makefile
├── docs
└── makefile

1. The root directory only contains:

file	type	desc
README.md	file	Project Introduction
makefile	file	The makefile in the root directory standardizes the overall packaging process, and the makefile in the subproject is called
api	dir	the logic of manager-api
dashboard	dir	the logic of dashboard UI
build	dir	Compilation results, such as a tar package that can be decompressed and run

2. There are respective makefiles in the api and dashboard, which are responsible for their respective construction work.

what do you think ? @juzhiyuan @justinmclean @membphis @moonming

[moonming]

We don’t need the build dir, this repo only has source codes kv <notifications@github.com>于2020年11月7日 周六下午9:29写道：

I recommend turning the project into a directory structure like this apisix-dashboard ├── .action ├── .github ├── README.md ├── api │ └── makefile ├── build │ ├── rpms │ └── tars ├── dashboard │ └── makefile ├── docs └── makefile 1. The root directory only contains: 2. The root directory only contains: file type desc README.md file Project Introduction makefile file The makefile in the root directory standardizes the overall packaging process, and the makefile in the subproject is called api dir the logic of manager-api dashboard dir the logic of dashboard UI build dir Compilation results, such as a tar package that can be decompressed and run 1. There are respective makefiles in the api and dashboard, which are responsible for their respective construction work. what do you think ? @juzhiyuan <https://github.com/juzhiyuan> @justinmclean <https://github.com/justinmclean> @membphis <https://github.com/membphis> @moonming <https://github.com/moonming> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#715 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGJZBK4FL5BGRYW4PQOO4GDSOVDTVANCNFSM4TNMVSAQ> .

-- Thanks, Ming Wen Twitter: _WenMing

[gxthrj]

ok, we can create dir build when make install

[moonming]

Do not. Why are installation and build mixed together?

[gxthrj]

Do not. Why are installation and build mixed together?

my mistake , there is no installation, just build.
we use makefile to build a package , the dir build is where the tar package is located.

[gxthrj]

Build tar package with Makefile, and the running mode will be described in readme

[nic-chen]

Why are there three Makefile? I think one in root dir is enough.

[gxthrj]

Why are there three Makefile? I think one in root dir is enough.

There are two considerations

1. I hope that the sub projects can be packaged and released independently;
2. The makefile of the root directory is the orchestration with different commands, regardless of the packaging logic of subprojects;

[gxthrj]

I just remove the dir build in the comment before

[juzhiyuan]

1. We don't have .action, we have .actions.
2. .actions is not clear for users, it should be renamed in this reconstruction work.
3. In this proposal, you only create 3 makefile files and rename the final product directory from output to build, I don't think it's better than before.
4. We don't have a plan to release the frontend & the backend separately, so 1 root makefile is fine.

[gxthrj]

1. We don't have .action, we have .actions.
2. .actions is not clear for users, it should be renamed in this reconstruction work.
3. In this proposal, you only create 3 makefile files and rename the final product directory from output to build, I don't think it's better than before.
4. We don't have a plan to release the frontend & the backend separately, so 1 root makefile is fine.

1. I just update the comment before: .action -> .actions, but I think the .actions is ok.
2. There are indeed many root directories in our dashboard, which is really confusing for novices, it will be more clearer to separate the project files.
3. one makefile is ok，but separate makefile for easy maintenance of front-end and back-end.
4. We have a scenario where only the admin-api installation package is needed, and dashboard is just one of the projects that rely on manager-api.
5. This is just a proposal that hopes to make the project directory clear，If reasonable, we can make a plan and do it step by step in the future.

[juzhiyuan]

1. Why .actions is ok? Is it clear for you when you see it in the first time?

2. If only the manager api is needed, why not update the repo's name to manager-api?

3. From your long long description, you mean it's ok to use 1 makefile or 3 makefile, then just kept the 1 makefile.

[membphis]

Why are there three Makefile? I think one in root dir is enough.

There are two considerations

1. I hope that the sub projects can be packaged and released independently;
2. The makefile of the root directory is the orchestration with different commands, regardless of the packaging logic of subprojects;

one makefile can do this too. just use different commands. you can take a look at the makefile of APISIX.

$ make help
Makefile rules:

    help:             Show Makefile rules
    deps:             Installation dependencies
    utils:            Installation tools
    lint:             Lint Lua source code
    init:             Initialize the runtime environment
    run:              Start the apisix server
    stop:             Stop the apisix server
    verify:           Verify the configuration of apisix server
    clean:            Remove generated files
    reload:           Reload the apisix server
    install:          Install the apisix (only for luarocks)
    test:             Run the test case
    license-check:    Check Lua source code for Apache License

[membphis]

my opinion of root folder:

1. one makefile
2. no build dir: when build, will create this folder automatically.
3. web vs dashboard: I can not sure which one is better.
4. .actions is not a good name, we need a better one

apisix-dashboard
├── .actions # need a better name
├── .github
├── README.md
├── api
│   └── ...
├── web
│   └── ...
├── docs
└── makefile

@gxthrj please pay more attention to the folder of api. The problem with this directory is more serious.

[gxthrj]

there is a questions, We have designed two dockerfile for both api and dashboard. I think the reason for this is because we need to build the image independently.

[gxthrj]

@juzhiyuan please give a suggest for renaming .actions

[moonming]

there is a questions, We have designed two dockerfile for both api and dashboard. I think the reason for this is because we need to build the image independently.

We have reached a consensus before that there is only one dockerfile

[membphis]

I don't want the dashboard and API to be built independently.

For users, they can choose only API, or dashboard + API, nothing else.

Within a single Dockfile, use parameters as conditions.

[juzhiyuan]

there is a questions, We have designed two dockerfile for both api and dashboard. I think the reason for this is because we need to build the image independently.

Nop, the Dockerfile under the api directory is used to run the test according to @nic-chen, just moved it under the test directory or somewhere else.

[juzhiyuan]

@juzhiyuan please give a suggest for renaming .actions

Just like workflows, actions are under the .github directory, just renamed it to .apache or .asf.

tools or utils are not good for me IMO.

[juzhiyuan]

web vs dashboard: I can not sure which one is better.

@membphis web is fine because this repo's name is apisix-dashboard, so we don't need to wrap a dashboard subdirectory just for the frontend.

[gxthrj]

there is a questions, We have designed two dockerfile for both api and dashboard. I think the reason for this is because we need to build the image independently.

Nop, the Dockerfile under the api directory is used to run the test according to @nic-chen, just moved it under the test directory or somewhere else.

for now , the content of /api/Dockerfile is building api image,but the docker-compose.yaml is for test

[juzhiyuan]

So why there will have multiple Dockerfile files? This doesn't make sense and it's unacceptable for me!

If you want to only build the manager api, just passed some arguments when building the image by using the root dockerfile.

Right? @membphis

[juzhiyuan]

Also, as far as know, the dockerfile under the api folder is used to do test, it seems that you don't have enough commuting with chen.

[membphis]

If you want to only build the manager api, just passed some arguments when building the image by using the root dockerfile.

Right? @membphis

yes, that is the right way I prefer.

[gxthrj]

Also, as far as know, the dockerfile under the api folder is used to do test, it seems that you don't have enough commuting with chen.

just see the code of dockerfile, it is for building image
and Keep unity ，there will be only one dockerfile and one makefile，the dockfile need to be modify too

[membphis]

the dockfile need to be modify too

let us update it. the current way is not good.

[juzhiyuan]

done?

[membphis]

ping @gxthrj

[gxthrj]

I think we can close this issue now, feel free to reopen if have any problems.