制备

Question

可能这是一个反复出现的问题，但我找不到在Bintray上发布Eclipse p2存储库的可靠方法。

手动创建repo / product / version并填充文件是可以的，但是，对于生产环境，需要一个可靠的脚本化解决方案。

目的

将Eclipse p2存储库部署到Bintray。

什么是Eclipse p2存储库？

（对不起Eclipse人员，但对于Bintry支持人员，我们更好地定义了我们所说的内容）。

Eclipse p2存储库是一个文件夹，必须在一个稳定且不会更改的URL上发布，即使多个版本及时发布也是如此。

使用最新版本的Tycho Maven插件生成的Eclipse p2存储库文件夹具有以下结构：

根目录中的5个文件（p2.index，artifacts.jar，artifacts.xml.xz，content.jar，content.xml.xz）
2个子文件夹，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）在每个版本中都具有相同的名称;无法访问特定于版本的子文件夹。

因此，部署多个版本不应创建特定于版本的子文件夹，因为它们的内容将被忽略。

使用特定于版本的URL

Eclipse插件在其中配置了一个可用于自动获取新更新的URL。这是p2存储库的URL，无法更改为指向特定于版本的URL，因此，要使更新生效，p2存储库应具有唯一的URL。

Eclipse p2存储库生命周期

Eclipse p2存储库的生命周期应该允许新版本完全替换以前的版本，即前5个文件和双子文件夹 all 应该是单个版本的一部分;如果由于任何原因，发布失败，以前的版本应该继续可见，不变

一旦发布版本，与之关联的文件将永远不会更改，因此不必将给定文件替换为具有相同名称但内容不同的文件
但是，顶级文件和文件夹对于所有版本都具有相同的名称，服务器应该允许上传它们而不会抱怨该名称已由先前版本上载
发布新版本的时刻尚未提前知道，可能每个月都会发布，但可能会发布超过180天的版本

发布到产品/版本URL

第一次尝试是使用以下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文件被忽略。

使用此过程创建的存储库是：

https://dl.bintray.com/ilg-ul/repo3/

使用不同的POST方法发布到产品/版本URL

如文档所述，有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

请注意，据我所知，这些文件没什么特别的。

使用此过程创建的存储库是

https://dl.bintray.com/ilg-ul/repo6/

虽然它看起来像一个有效的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来自第一个版本，所以存储库是不一致。

发布到repo URL

虽然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网址，但是对于所有其他文件它失败了。

使用此过程创建的存储库是：

https://dl.bintray.com/ilg-ul/repo1/

将两者发布到repo和产品/版本URL

我还尝试选择性地将一些文件上传到repo，并将一些文件上传到产品/版本（p2.index，artifacts.xml.xz和content.xml.xz / features文件夹）;这创建了一个正确的p2，但是当我尝试为另一个版本重复该过程时，我遇到了错误：

plugins

`Processing 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脚本（以及其他一些）：

https://gist.github.com/ilg-ul/568a6806d5e97fcc1384d7acda4ffe36

要下载此脚本，请使用以下

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

所有其他文件都已正确上传，但这三个文件是以特殊的（我会说错误的）方式处理的。

尝试发布到repo URL失败的大多数文件

如果这不是向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的建议

删除Generic存储库中某些文件的特殊处理

正如这些测试所证明的那样，Bintray通用存储库不是通用的，因为它们不会像预期的那样平等地处理所有文件;它看起来像是支持Eclipse p2存储库的尝试，并且服务器上载代码被修补以不同方式处理一些Eclipse文件，但结果不是完全正常，而且非常令人困惑。

添加对Eclipse p2存储库的显式支持

如果Bintray支持一个新的存储库类型＆＃34; Eclipse p2＆＃34; ，那么没有产品，那将是非常好的。版本，每个发布版本都可以删除所有现有文件并添加新文件。

这相当于允许在repo文件夹中发布，并允许以后随时删除和上传文件。

如果无法摆脱版本控制机制，则可以发布到版本文件夹，但自动将最新版本的文件也显示在产品文件夹中，如repo6所示，但要确保接受所有文件，包括artifacts.jar和content.jar。

2017-03-31更新

在与Bintray支持交换无数消息后，他们终于理解了问题并提供了修复。

现在运行脚本对于测试4,5和6是有用的，除了信息传递给Bintray的小变化之外，它们基本上是相同的。

测试结果如下：

上传到不功能
直接上传，指定包和版本作为不功能
使用HTTP标头指定包和版本时上传功能
使用HTTP矩阵参数指定包和版本时上传是有效的

总之，不要尝试上传到根URL并使用HTTP头或HTTP矩阵参数。

2017-07-31更新

我已经在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）。

Answer 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。

Answer 2

我正在bintray上托管我的eclipse项目，但也遇到了一些问题，但能够修复：

制备

创建了一个通用存储库 - 例如＆＃34; myproject的＆＃34;
在里面创建了一个包 - 例如＆＃34;更新现场＆＃34;
创建了一个版本 - 例如＆＃34;电流＆＃34;

所以在我的项目中，我想只使用一个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的已采用版本来上传我的文件。

180天覆盖问题以及如何修复

当你查看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近一年，没有更新等问题。

Bintray对Eclipse p2存储库的支持

目的

什么是Eclipse p2存储库？

使用特定于版本的子文件夹

使用特定于版本的URL

Eclipse p2存储库生命周期

发布到产品/版本URL

使用不同的POST方法发布到产品/版本URL

发布到repo URL

将两者发布到repo和产品/版本URL

`override`标志

完整的测试脚本

发现的问题

拒绝服务器上传`bash "${HOME}/Downloads/bintray-test.sh"`和`artifacts.xml.xz`

创建中间文件夹和存储内容

尝试发布到repo URL失败的大多数文件

结论

对Bintray的建议

删除Generic存储库中某些文件的特殊处理

添加对Eclipse p2存储库的显式支持

2017-03-31更新

2017-07-31更新

2 个答案:

制备

如何使用覆盖

180天覆盖问题以及如何修复

Bintray对Eclipse p2存储库的支持

目的

什么是Eclipse p2存储库？

使用特定于版本的子文件夹

使用特定于版本的URL

Eclipse p2存储库生命周期

发布到产品/版本URL

使用不同的POST方法发布到产品/版本URL

发布到repo URL

将两者发布到repo和产品/版本URL

override标志

完整的测试脚本

发现的问题

拒绝服务器上传bash "${HOME}/Downloads/bintray-test.sh" 和artifacts.xml.xz

创建中间文件夹和存储内容

尝试发布到repo URL失败的大多数文件

结论

对Bintray的建议

删除Generic存储库中某些文件的特殊处理

添加对Eclipse p2存储库的显式支持

2017-03-31更新

2017-07-31更新

2 个答案:

制备

如何使用覆盖

180天覆盖问题以及如何修复

`override`标志

拒绝服务器上传`bash "${HOME}/Downloads/bintray-test.sh"`和`artifacts.xml.xz`