-------------------------------------------------------------------------------- Implementation Purpose -------------------------------------------------------------------------------- This project is focused on supplying a reference implementation, both for supply-side and demand-side platforms, of the offline synchronization services specified in the OpenRTB Specification. The goal and design of this work is to minimize the effort required by any DSP or SSP wishing to leverage the capabilities described in the spec. To aid in this effort, the work has been licensed under the New BSD License. Please refer to the LICENSE file in the root of this project for more information, or to the following website for more information: http://www.opensource.org/licenses/bsd-license.php -------------------------------------------------------------------------------- Project Structure -------------------------------------------------------------------------------- You should be able to build the project by running 'mvn clean install' from the top-level directory. The project is structured in the following manner: + common This directory is a maven project that produces a single jar file. This jar file contains all code that is shared between the demand-side and supply-side implementations (i.e. authentication/validation work, object models, etc.) + demand-side This directory contains a series of maven projects responsible for the DSP behavior of this specification. The sub-project artifact responsibilities include: * dsp-web This project packages up a web archive (war) file, capable of being deployed in any standard JEE web container based upon the reference 'dsp-client' artifact provided with this implementation. The contents of this package are purposefully minimized to the deployment artifacts necessary to deploy the war file. * dsp-core This project produces a jar file containing the necessary logic for sending requests and receiving responses, including all message handling that is pertinent to the DSP. This jar file represents standard logic that would be implemented by any DSP wishing to leverage this implementation. All DSP specific logic (i.e. persisting the response data, retrieving advertiser information, etc.) is delegated to the 'dsp-client' via the 'dsp-intf'. * dsp-intf This package is the contract and set of interfaces between the message handling code located in the 'dsp-core' and a DSP's specific internal representation of that data. * dsp-client This package is an example implementation of the 'dsp-intf' to satisfy the following: 1) Integration testing between the 'dsp-web' and 'ssp-web' projects. 2) Provide a framework for other DSPs to leverage this specification more quickly by allowing the DSP to focus on the integration aspects of the specification with their own specific platform. As a result of requirement (1) above, this package must be capable of working in concert with the 'ssp-client' described below. + supply-side Similar to the 'demand-side' module, this directory contains a series of maven projects responsible for the SSP behavior described in the specification. The sub-module artifact responsibilities include: * ssp-web This project packages up a web archive (war) file capable of being deployed in any standard JEE web container. It is based upon the reference 'ssp-client' artifact provided with this implementation. The contents of this package are purposefully minimized to the deployment configurations necessary to deploy the war file. * ssp-core This project produces a jar file containing the necessary logic for sending and receiving both requests and responses, including all message handling that is pertinent to the SSP. This jar file represents standard logic that would be implemented by any SSP wishing to leverage this implementation.. All SSP specific logic (i.e. persisting the advertiser data, retrieving publisher information, etc.) is delegated to the 'ssp-client' via the 'ssp-intf'. * ssp-intf This package is the contract and set of interfaces between the message handling code located in the 'ssp-core' and an SSP's specific internal representation of that data. * ssp-client This package is an example implementation of the 'ssp-intf' to satisfy the following: 1) Integration testing between the 'ssp-web' and 'dsp-web' projects. 2) Provide a framework for other SSPs to leverage this specification more quickly by allowing the SSP to focus on the integration aspects of the specification with their own specific platform. As a result of requirement (1) above, this package must be capable of working in concert with the 'dsp-client' described above. https://www.cnblogs.com/yehaia1/archive/2019/04/16/10715741.html 在github上fork项目如何同步并解决冲突 在github上有些项目我们可能会进行一些自己功能的添加但是提交PR后作者基于设计或者其他原因考虑没有通过，但是这个功能又是我们必须的。这时我们就想自己维护一份自己的版本，所以主仓库更新版本时我们就需要同步。 1.首先，先克隆自己的fork后的远端仓库到本地 git clone https://github.com/your/projectname.git 2.用vscode打开，并在vscode的终端进行操作 # 查看原有远程分支信息 git remote -v # 添加源项目的远程分支并命名为upgrade，名称随意 git remote add upgrade https://github.com/origin/projectname.git # 再次查看本地的远程分支信息，这时已经可以看到远程分支已经添加进去了 git remote -v # 把upgrade的代码拉取到本地 git fetch upgrade # 查看并选中dev（默认是选中master），或者其他你想合并的分支，只有一个master分支可以忽略 git branch # *号就是选中的 > * master > dev git checkout -b dev # 合并upgrade到我们自己的master分支 git merge upgrade/master # 如果没有提示冲突，直接推送到github仓库，有冲突请继续往下看 git push origin master 3.处理冲突 这时我们可以点开vscode的Source Control（源代码管理）就可以很方便的查看到冲突的文件，处理完冲突然后再次合并。 # 提交并注释 git commit -m "upgrade" # 这时执行合并提示成功了 git merge upgrade/master # 推送到github git push origin master