我有以下文件,希望将其作为9.8.0版本的 Artifactory 上传到Artifactory。
注意:前两个文件没有扩展名(它们是可执行文件,即,如果您在其上打开/打开目录,则会看到垃圾字符)。
在CVS中,给定版本9.8.0的文件夹/文件类似于:
com.company.project/gigaproject/v9.8.0/linux/gigainstall
com.company.project/gigaproject/v9.8.0/solaris/gigainstall
com.company.project/gigaproject/v9.8.0/win32/gigainstall.exe
com.company.project/gigaproject/v9.8.0/gigafile.dtd
com.company.project/gigaproject/v9.8.0/gigaanotherfile.dtd
com.company.project/gigaproject/v9.8.0/giga.jar
com.company.project/gigaproject/v9.8.0/giga.war
上载具有扩展名的上述文件非常容易...您以有权访问部署 Artifactory 的管理员/用户身份登录Artifactory,单击“部署”选项卡,浏览Artifactory文件,然后选择该文件,点击“上传”按钮。
接下来,您将看到一个屏幕(如上图所示)。您将在此页面上的字段中调整所需的内容,然后单击“Deploy Artifact”,即完成操作。您所要做的就是在上传时选择正确的file.extension
文件,并确保文件扩展名正确显示在“目标路径”框中(带有-x.x.x等版本)。
我的问题:
问题1 :如何上传没有扩展名的 Artifactory ?默认情况下,Artifactory似乎将 Artifactory 作为.jar扩展名。如何为Linux和Solaris上载“gigainstall” Artifactory ,如上面的文件夹/文件结构所示?我看到可以将 Artifactory 名称用作gigainstall-linux和gigainstall-solaris并对其进行区分,但是我不确定如何告诉Artifactory该 Artifactory 没有任何扩展名。
我认为开发团队不会以适当的扩展名开始生成此 Artifactory (因为该 Artifactory 可能在其他项目中的任何地方都进行了硬编码,而这些项目目前正在从某个地方从CVS/SVN源代码控制中获取它-这本身是一种不好的做法)将 Artifactory 存储在源代码控制版本工具中)。
问题2 :我如何告诉构建系统(例如Gradle)在“编译”任务期间消耗未扩展的 Artifactory 。在build.gradle部分{..}下,我将添加如下所示的内容,但是我不确定未扩展的文件(上面提到的文件夹/文件结构中的前两个)。
依赖项{
//编译'com.company.project:gigainstall-linux:9.8.0 @'
//编译'com.company.project:gigainstall-linux:9.8.0 @ ??????'
//编译'com.company.project:gigainstall-linux:9.8.0 @“”'
//编译'com.company.project:gigainstall-linux:9.8.0 @“none”'
//编译'com.company.project:gigainstall-linux:9.8.0 @“NULL_or_something”'
//以下内容将从Artifactory存储库中轻松获取giga.jar版本giga-9.8.0.jar
编译'com.company.project:giga:9.8.0'
//以下将很容易获得giga.war
编译'com.company.project:giga:9.8.0@war'
//同样,可以从Artifactory提取其他基于扩展的 Artifactory
编译'com.company.project:gigafile:9.8.0@dtd'
编译'com.company.project:gigaanotherfile:9.8.0@dtd'
}
最佳答案
答案1 (从不同的角度讲,还将涵盖2个):使用Artifactory的“Deploy”选项卡下的“Artifact Bundle”功能部分,可以通过创建一个zip文件以所需的方式上传艺术品,首先(包含其中的结构和 Artifactory )-或,您可以使用/调用Artifactory REST API的方式上传 Artifactory 。
高层次的想法:
创建一个名为gigaproject.zip的压缩文件或Artifactory可以读取的anyname.zip/.tar/压缩文件。在zip内,创建结构-这些 Artifactory 将如何加载到Artifactory
,即
gigaproject.zip将包含以下文件夹/结构/文件。
情况1:
com/company/project/gigaproject/9.8.0/linux/gigainstall com/company/project/gigaproject/9.8.0/solaris/gigainstall com/company/project/gigaproject/9.8.0/win32/gigainstall.exe com/company/project/gigaproject/9.8.0/gigafile.dtd com/company/project/gigaproject/9.8.0/gigaanotherfile.dtd com/company/project/gigaproject/9.8.0/giga.jar com/company/project/gigaproject/9.8.0/giga.war
NOTE: In case 1 example, I didn't use any -x.x.x in the filename (i.e. I'm using plain and simple giga.jar instead of giga-9.8.0.jar).
The above Upload/Deploy will result the files (as shown in the following snapshot):
So, we have achieved what we wanted. Actually (visibly speaking yes), but not in a way Artifactory usually stores these artifacts (as they should -x.x.x version embedded in the file name and where artifact id should match the artifact filename). Now, if you want to consume the following in a Gradle build file, you CANNOT as first, you haven't uploaded the filename with -x.x.x version name in it, secondly, the artifact id in our case 1 tree was "gigaproject" (after com/company/project folder), so Gradle way of defining what artifact id and what artifact file name you want won't work.
compile 'com.company.project:gigaproject:CANNOTSAY_HOW_TO_GET_GIGA_JARorGIGAINSTALL_with_without_extension'
结论:可以以任何结构上传任何文件(在Artifactory中带有/不带扩展名的文件),但这取决于您的构建系统使用或不使用它的方式。
-我从Artifactory储存库中删除了刚刚使用case 1 .zip文件创建的结构,以尝试下一个case#2,并删除了我创建的.zip文件。
情况2:
让我们为每个 Artifactory 创建一个单独的版本化文件名,并以以下格式创建结构-Artifactory实际存储它们的方式(在树状 View 的存储库中看到的 Artifactory )并创建一个包含该结构的.zip文件。让我们使用相同的“Artifactory 捆绑包”功能上载此.zip文件,以上载Artifactory中所需的单个 Artifactory -其中artifact-id(我们尝试使用它时提到的第二个值)将与Artifactory中的 Artifactory 文件名称匹配。
.zip文件的文件夹/文件结构:
com/company/project/gigainstall/9.8.0/gigainstall-9.8.0.linux com/company/project/gigainstall/9.8.0/gigainstall-9.8.0.solaris com/company/project/gigainstall/9.8.0/gigainstall-9.8.0.exe com/company/project/gigafile/9.8.0/gigafile-9.8.0.dtd com/company/project/gigaanotherfile/9.8.0/gigaanotherfile-9.8.0.dtd com/company/project/giga/9.8.0/giga-9.8.0.jar com/company/project/giga/9.8.0/giga-9.8.0.war
NOTE: This time, we'll be using the same "Artifact Bundle" feature and for similar files (gigainstall under both Linux/Solaris folders), I took the approach of creating gigainstall folder (containing gigainstall-9.8.0.linux and gigainstall-9.8.0.solaris file names) i.e. when we'll consume these artifacts in Gradle under dependencies { ... } section for compile, we'll use x.x.x@ way to fetch these artifacts from Artifactory.
OK, once "Artifact Bundle" Deploy/Upload was successfully complete, I got the following message.
Successfully deployed 7 artifacts from archive: gigaproject.zip (1 seconds).
Now, let's see how it looks like in Artifactory while searching for one of the artifact/in Tree view. You can see we have the files now in place, with filename-x.x.x.extension way so that I can consume them easily in Gradle.
In Gradle build file (build.gradle), I'll mention:
dependencies { compile "com.company.project:gigainstall:9.8.0@linux" compile "com.company.project:gigainstall:9.8.0@solaris" compile "com.company.project:gigainstall:9.8.0@linux" compile "com.company.project:giga:9.8.0 compile "com.company.project:giga:9.8.0@war compile "com.company.project:gigafile:9.8.0@dtd compile "com.company.project:gigaanotherfile:9.8.0@dtd }
OH OH!! - That didn't work, see below for Gradle error. Why? - Artifactory Bundle upload/deploy feature uploads a zip file content what you have in the .zip but it DOES NOT create a .pom file per artifact it deploys. Thus, making the Gradle build to fail. May be in Ant this might succeed. This occurred for each individual .jar/.war/.dtd/etc file. I'm just showing one error example.
While doing gradle clean build
Could not resolve all dependencies for configuration ':compile'.
> Could not resolve com.company.project:gigafile:0.0.0.
Required by:
com.company.project:ABCProjectWhichConsumesGIGAProjectArtifacts:1.64.0
> Could not GET 'http://artifactoryserver:8081/artifactory/ext-snapshot-local/com/company/project/gigafile/0.0.0/gigafile-0.0.0.pom'. Received status code 409 from server: Conflict
情况3 :让我们采用一种简单的方法(解决方法,但可以省去很多麻烦)。
使用以下结构创建gigaproject.zip文件,此方法需要-在文件夹/文件结构的单个 Artifactory/文件名中没有嵌入x.x.x版本值。我们将使用“单一 Artifactory ”方法(它将在Artifactory提供的上载/部署过程中自动为gigaproject.zip文件创建.pom)。使用这种方法,您仍然可以获取gigainstall文件,而无需对其名称进行任何扩展。正如您已经看到的,在上载/部署步骤中,您上载了gigaproject.zip,并且 Artifactory 会将其作为“gigaproject-x.x.x.zip”上传到给定的目标存储库中,在本例中,x.x.x为9.8.0。请参阅下面的图像快照。
gigaproject/linux/gigainstall gigaproject/solaris/gigainstall gigaproject/win32/gigainstall.exe gigaproject/gigafile.dtd gigaproject/gigaanotherfile.dtd gigaproject/gigaproject.zip gigaproject/giga.jar gigaproject/giga.war
Now, upload it in Artifactory using "Single Artifact" feature. Click "Deploy Artifact" once you tweak the values for GroupId, ArtifactId, Version, etc.
Once this is uploaded. You'll see in the zip artifact in the target repository (I took a bad example, usually this would be libs-snapshot-local or libs-release-local instead of ext-...), you'll be able to consume the ZIP artifact directly in Graddle:
dependencies {
// This is the only line we need now.
compile "com.company.project:gigaproject:9.8.0@zip"
}
一旦.zip可用于Gradle构建系统,现在您可以告诉Gradle在您的构建/工作区区域中的某个位置解压缩该.zip文件,您可以在其中馈送实际的(解压缩的)文件(gigainstall,.dtd,.jar,.war ,等等)到构建过程/步骤。
PS :我猜案例1和案例2适用于Ant。
答案2:
如果您以任何一种方式上载了未扩展的文件。确保您也手动创建/上载了其POM文件(即,如果我将gigainstall-9.8.0作为 Artifactory 上传到com/company/project/gigainstall/9.8.0/gigainstall-9.8.0下,则处于同一级别) ,我必须/应该创建它的POM文件(请参阅简单的模板.pom文件以获取自定义jar Artifactory ,或者通过“单一 Artifactory ”部署上传扩展文件时,您将看到POM编辑器窗口显示的内容)并同时上传这样Gradle就不会说没有POM冲突/错误,而Ant可能不需要pom(我没有检查)。
将其放在Artifactory中后,以下行应可以工作-如果您发现其他方法,请发表评论。
dependencies {
// See nothing mentioned after - x.x.x@
compile "com.company.package:gigainstall:9.8.0@"
}
关于file - 如何将 Artifactory 上传到Artifactory/在没有 Artifactory 扩展名的构建系统(Gradle Maven Ant)中使用它,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/24536706/