可能这是一个反复出现的问题，但我找不到在Bintray上发布Eclipse p2存储库的可靠方法。
手动创建repo / product / version并填充文件是可以的，但是，对于生产环境，需要一个可靠的脚本化解决方案。
将Eclipse p2存储库部署到Bintray。
（对不起Eclipse人员，但对于Bintry支持人员，我们更好地定义了我们所说的内容）。
Eclipse p2存储库是一个文件夹，必须在一个稳定且不会更改的URL上发布，即使多个版本及时发布也是如此。
使用最新版本的Tycho Maven插件生成的Eclipse p2存储库文件夹具有以下结构：
p2.index，artifacts.jar，artifacts.xml.xz，content.jar，content.xml.xz）plugins和features，每个文件夹包含多个.jar个文件，其中包含特定于版本的名称，例如ilg.gnuarmeclipse.core_3.3.1.201702251311.jar 例如：
artifacts.jar
artifacts.xml.xz
content.jar
content.xml.xz
features
ilg.gnuarmeclipse.codered_1.1.1.201702231729.jar
...
p2.index
plugins
ilg.gnuarmeclipse.codered_1.1.1.201702231729.jar
...
我要部署的确切p2存储库文件夹是：
（GNU ARM Eclipse项目的两个部分）。
必须在Eclipse中配置以访问这两个p2存储库的实际URL是：
访问这些p2存储库实际上是对这些URL正下方文件的一系列访问，例如：
$ curl -L http://gnuarmeclipse.sourceforge.net/updates/p2.index
#Sat Feb 25 15:11:37 EET 2017 version=1
metadata.repository.factory.order=content.xml.xz,content.xml,\!
artifact.repository.factory.order=artifacts.xml.xz,artifacts.xml,\!
$
Eclipse p2存储库没有特定于版本的子文件夹，所使用的子文件夹（plugins和features）在每个版本中都具有相同的名称;无法访问特定于版本的子文件夹。
因此，部署多个版本不应创建特定于版本的子文件夹，因为它们的内容将被忽略。
Eclipse插件在其中配置了一个可用于自动获取新更新的URL。这是p2存储库的URL，无法更改为指向特定于版本的URL，因此，要使更新生效，p2存储库应具有唯一的URL。
Eclipse p2存储库的生命周期应该允许新版本完全替换以前的版本，即前5个文件和双子文件夹 all 应该是单个版本的一部分;如果由于任何原因，发布失败，以前的版本应该继续可见，不变
第一次尝试是使用以下bash函数将所有文件上传到产品/版本URL：
curl \
--request PUT \
--upload-file "${file_absolute_path}" \
--user ${BINTRAY_USER}:${BINTRAY_API_KEY} \
"${API}/content/${BINTRAY_OWNER}/${repo}/${package}/${version}/${file_relative_path}?publish=1?override=1?explode=0"
上传成功：
Processing artifacts.jar file...
{"message":"success"}
Processing artifacts.xml.xz file...
{"message":"success"}
Processing content.jar file...
{"message":"success"}
Processing content.xml.xz file...
{"message":"success"}
Processing p2.index file...
{"message":"success"}
Processing feature: features/ilg.gnuarmeclipse.codered_1.1.1.201702231729.jar file...
{"message":"success"}
Processing plugin: plugins/ilg.gnuarmeclipse.codered_1.1.1.201702231729.jar file...
{"message":"success"}
但是，虽然所有文件都是以相同方式上传的，但是有些文件存储在repo文件夹中，而不是像预期的那样存储在product / version文件夹中：
artifacts.xml.xz
content.xml.xz
features
ilg.gnuarmeclipse.codered_1.1.1.201702231729.jar
pack3
3.2.1-201701141320
artifacts.jar
content.jar
p2.index
plugins
ilg.gnuarmeclipse.codered_1.1.1.201702231729.jar
请注意，虽然我没有明确地将list_in_downloads属性设置为任何文件，但上传到product / version的一些文件已移至父repo文件夹。
可以看出，*.xz文件以及features和plugins文件夹已提升到repo文件夹，而{{1} }文件和*.jar文件被忽略。
使用此过程创建的存储库是：
如文档所述，有3种方法将参数传递给curl。以前的测试使用了一个;在另外两个测试中，我尝试了接下来的两个，使用以下上传代码：
p2.index与
分开curl \
--request PUT \
--upload-file "${file_absolute_path}" \
--user ${BINTRAY_USER}:${BINTRAY_API_KEY} \
--header "X-Bintray-Package: ${package}" \
--header "X-Bintray-Version: ${version}" \
--header "X-Bintray-Publish: 1" \
--header "X-Bintray-Override: 1" \
--header "X-Bintray-Explode: 0" \
"${API}/content/${BINTRAY_OWNER}/${repo}/${file_relative_path}"
两者的表现都优于上一次测试，第一个版本的上传成功，文件夹结构得以保留：
curl \
--request PUT \
--upload-file "${file_absolute_path}" \
--user ${BINTRAY_USER}:${BINTRAY_API_KEY} \
"${API}/content/${BINTRAY_OWNER}/${repo}/${file_relative_path};bt_package=${package};bt_version=${version};publish=1;override=1;explode=0"
但上传第二个版本时，除了上传artifacts.jar
artifacts.xml.xz
content.jar
content.xml.xz
features
ilg.gnuarmeclipse.codered_1.1.1.201701141320.jar
p2.index
plugins
ilg.gnuarmeclipse.codered_1.1.1.201701141320.jar
和artifacts.xml.xz失败外，大部分文件都还可以。
content.xml.xz请注意，据我所知，这些文件没什么特别的。
使用此过程创建的存储库是
虽然它看起来像一个有效的p2存储库，但它不是，因为大多数文件来自第二个版本，但Upload 'artifacts.jar' to '/repo6/pack6/3.3.1-201702251311/'
{"message":"success"}
Upload 'artifacts.xml.xz' to '/repo6/pack6/3.3.1-201702251311/'
{"message":"Unable to upload files: An artifact with the path 'artifacts.xml.xz' already exists under another version"}
Upload 'content.jar' to '/repo6/pack6/3.3.1-201702251311/'
{"message":"success"}
Upload 'content.xml.xz' to '/repo6/pack6/3.3.1-201702251311/'
{"message":"Unable to upload files: An artifact with the path 'content.xml.xz' already exists under another version"}
Upload 'p2.index' to '/repo6/pack6/3.3.1-201702251311/'
{"message":"success"}
...
和artifacts.xml.xz来自第一个版本，所以存储库是不一致。
虽然Bintray文档中没有正式提及，但有些人建议尝试上传到更短的路径，对应于root或repo URL。
我做了，使用以下代码：
content.xml.xz但是在这种情况下我的大多数文件都出错：
curl \
--request PUT \
--upload-file "${file_absolute_path}" \
--user ${BINTRAY_USER}:${BINTRAY_API_KEY} \
"${API}/content/${BINTRAY_OWNER}/${repo}/${file_relative_path}?publish=1?override=1"
看起来上传机制很挑剔，并接受将一些文件（如Processing artifacts.jar file...
{"message":"success"}
Processing artifacts.xml.xz file...
{"message":"Invalid file path and name"}
Processing content.jar file...
{"message":"success"}
Processing content.xml.xz file...
{"message":"Invalid file path and name"}
Processing p2.index file...
{"message":"success"}
Processing feature: features/ilg.gnuarmeclipse.codered_1.1.1.201702231729.jar file...
{"message":"Invalid file path and name"}
Processing plugin: plugins/ilg.gnuarmeclipse.codered_1.1.1.201702231729.jar file...
{"message":"Invalid file path and name"}
，artifacts.jar和content.jar）上传到repo网址，但是对于所有其他文件它失败了。
使用此过程创建的存储库是：
我还尝试选择性地将一些文件上传到repo，并将一些文件上传到产品/版本（p2.index，artifacts.xml.xz和content.xml.xz / features文件夹）;这创建了一个正确的p2，但是当我尝试为另一个版本重复该过程时，我遇到了错误：
pluginsProcessing artifacts.jar file...
{"message":"success"}
Processing artifacts.xml.xz file...
{"message":"Unable to upload files: An artifact with the path 'artifacts.xml.xz' already exists under another version"}
Processing content.jar file...
{"message":"success"}
Processing content.xml.xz file...
{"message":"Unable to upload files: An artifact with the path 'content.xml.xz' already exists under another version"}
Processing p2.index file...
{"message":"success"}
标志请注意，所有测试都设置了override标志。
override标志请注意，所有测试都设置了publish标志，但这不是预期的行为。
为了保持存储库的一致性，预期的行为是尝试上传所有文件而不发布标志，并且只有在所有文件都正确上传的情况下才在最后进行发布;如果发生错误，未发出发布命令，则可以保留为先前版本发布的文件。
GitHub gists提供了用于这些测试的完整bash脚本（以及其他一些）：
要下载此脚本，请使用以下
publish此脚本需要在环境中设置以下变量：
mkdir -p "${HOME}/Downloads"
curl -L https://gist.github.com/ilg-ul/568a6806d5e97fcc1384d7acda4ffe36/raw/2df98f4899862f1d7e65f1601ccdbd320dce9021/bintray-test.sh -o "${HOME}/Downloads/bintray-test.sh"
要运行脚本，请输入：
export BINTRAY_USER=<user>
export BINTRAY_API_KEY=<auth>
export BINTRAY_OWNER=${BINTRAY_USER}
bash "${HOME}/Downloads/bintray-test.sh"
和artifacts.xml.xz 考虑到使用不同的POST方法（repo6）发布到产品/版本URL是最高级的测试，唯一确定的问题是拒绝服务器上传content.xml.xz和{{ 1}}。
将包和版本作为URL（repo3）的一部分传递，产生了最奇怪的结果，以及其他文件夹：
artifacts.xml.xz所有其他文件都已正确上传，但这三个文件是以特殊的（我会说错误的）方式处理的。
如果这不是向Bintray发布的合法方式，请忽略该部分，但尝试发布到repo网址仅对以下3个文件content.xml.xz，pack3
3.2.1-201701141320
artifacts.jar
content.jar
p2.index
和{{ 1}}）并且对其他所有人都失败了。
作为结论，基于现有文档，我找不到一种可靠的方法来将常用的Eclipse p2存储库发布到Bintray。
我看到了一些好奇的解决方案来发布复合p2存储库，但这是不是我的情况，我有两个常见的存储库，不需要任何版本控制（http://gnuarmeclipse.sourceforge.net/updates和http://gnuarmeclipse.sourceforge.net/updates-test），我想在Bintray上发布它们。
正如这些测试所证明的那样，Bintray通用存储库不是通用的，因为它们不会像预期的那样平等地处理所有文件;它看起来像是支持Eclipse p2存储库的尝试，并且服务器上载代码被修补以不同方式处理一些Eclipse文件，但结果不是完全正常，而且非常令人困惑。
如果Bintray支持一个新的存储库类型＆＃34; Eclipse p2＆＃34; ，那么没有产品，那将是非常好的。版本，每个发布版本都可以删除所有现有文件并添加新文件。
这相当于允许在repo文件夹中发布，并允许以后随时删除和上传文件。
如果无法摆脱版本控制机制，则可以发布到版本文件夹，但自动将最新版本的文件也显示在产品文件夹中，如repo6所示，但要确保接受所有文件，包括artifacts.jar和content.jar。
在与Bintray支持交换无数消息后，他们终于理解了问题并提供了修复。
现在运行脚本对于测试4,5和6是有用的，除了信息传递给Bintray的小变化之外，它们基本上是相同的。
测试结果如下：
总之，不要尝试上传到根URL并使用HTTP头或HTTP矩阵参数。
我已经在Bintray上托管了几个月的更新网站，似乎没事：https://bintray.com/gnu-mcu-eclipse。
用于发布的实际脚本是：https://github.com/gnu-mcu-eclipse/eclipse-plugins/blob/develop/scripts/publish-updates.sh
用于更新网站的公共网址如下所示：https://dl.bintray.com/gnu-mcu-eclipse/updates。
实际上有多个Bintray存储库，用于不同的阶段＆＃39;该项目（https://bintray.com/gnu-mcu-eclipse）;在他们下面有一个Bintray包（我称之为p2.index），下面是多个Bintray版本（https://bintray.com/gnu-mcu-eclipse/v4-neon-updates-experimental/p2）。
答案 0 :(得分：1)
去年我正在努力解决同样的问题 当试图通过curl上传一个简单的Eclipse p2存储库到Bintray。 受article of Lorenzo Bettini的启发 我找到了解决方案。 关键是在URL中使用路径和矩阵参数，例如：
curl -X PUT -T $F -u $BINTRAY_USER:$BINTRAY_API_KEY "https://api.bintray.com/content/$BT_OWNER/$BT_REPO/$BT_PACKAGE/$BT_VERSION/$F;bt_package=$BT_PACKAGE;bt_version=$BT_VERSION;publish=1"
随意查看我的shell脚本deployToBintray.sh。
答案 1 :(得分：0)
我正在bintray上托管我的eclipse项目，但也遇到了一些问题，但能够修复：
所以在我的项目中，我想只使用一个URL来更新站点，这个URL不会改变，只需将所有新内容放在同一个bintray-version（＆＃34; current＆＃34;）。将覆盖site.xml，content.jar等。
＆＃34; new＆＃34; REST API可以覆盖文件。
PUT /content/:subject/:repo/:file_path;bt_package=:package;bt_version=:version[;publish=0/1][;override=0/1][;explode=0/1]
我使用的是https://github.com/vogellacompany/bintray-publish-p2-updatesite/blob/master/pushToBintray.sh的已采用版本来上传我的文件。
当你查看https://bintray.com/docs/api/index.html#_content_uploading_publishing
时存在一个passus：
可选择发布上传的工件作为上传的一部分 （默认情况下关闭）。其他内容可以上传到已发布的内容 版本发布之日起180天内。
我确实在180天之后遇到了问题我无法上传......
但有一种简单的方法可以解决： 编辑您的版本
https://bintray.com/$userName/myProject/update-site/current/edit?tab=general
然后点击＆＃34;更新版本＆＃34;按钮。
执行此操作后，我可以再次上传，所以这似乎重置了180天。目前我现在主持我的upate-site近一年，没有更新等问题。