如何将工件上传到Artifactory/在没有工件扩展名的构建系统(Gradle Maven Ant)中使用它 [英] How to upload an artifact to Artifactory / consume it in a build system (Gradle Maven Ant) where the artifact does not have an extension
问题描述
我想将以下文件作为9.8.0版本的工件上传到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文件，然后选择该文件，然后点击上传"按钮.
接下来，您将看到一个屏幕(如上图所示).您将在此页面上的字段中调整所需的内容，然后单击"Deploy Artifact"，即完成操作.您所要做的就是在上传时选择正确的file.extension文件，并确保文件扩展名正确显示在目标路径"框中(带有-x.x.x等版本).
我的问题:
问题1 :如何上传没有扩展名的工件?似乎Artifactory默认情况下将工件作为.jar扩展名.如何为Linux和Solaris上载"gigainstall"工件，如上面的文件夹/文件结构所示?我看到我可以将工件名称用作gigainstall-linux和gigainstall-solaris并加以区分，但是我不确定如何告诉Artifactory该工件没有任何扩展名.
我认为开发团队不会以适当的扩展名开始生成此工件(因为该工件可能在其他项目中的任何地方都进行了硬编码，而这些项目目前正在从某处从CVS/SVN源代码控制中获取它-这本身就是一个将工件存储在源代码控制版本工具中的错误做法.
问题2 :我如何告诉构建系统(例如Gradle)在编译"任务期间使用未扩展的工件.在build.gradle部分{{..}下的内容中，我将添加如下所示的内容，但是我不确定未扩展的文件(上面提到的文件夹/文件结构中的前两个).
dependencies {
//compile 'com.company.project:gigainstall-linux:9.8.0@'
//compile 'com.company.project:gigainstall-linux:9.8.0@??????'
//compile 'com.company.project:gigainstall-linux:9.8.0@""'
//compile 'com.company.project:gigainstall-linux:9.8.0@"none"'
//compile 'com.company.project:gigainstall-linux:9.8.0@"NULL_or_something"'
// The following will easily get giga.jar version giga-9.8.0.jar from Artifactory repository
compile 'com.company.project:giga:9.8.0'
// The following will easily get giga.war
compile 'com.company.project:giga:9.8.0@war'
// Similarly, other extension based artifacts can be fetched from Artifactory
compile 'com.company.project:gigafile:9.8.0@dtd'
compile 'com.company.project:gigaanotherfile:9.8.0@dtd'
}
答案1 (在不同的意义上还将涵盖2 ):使用Artifactory"Artifact Bundle通过首先创建一个zip文件(包含其中的结构和工件)，部署"选项卡下的功能"部分可以按照我们想要的方式，通过技巧至少上传工件，-或可以使用/调用 Artifactory REST API 方式上传工件.
高级构想:
创建一个名为gigaproject.zip的zip文件或Artifactory可以读取的anyname.zip/.tar/压缩文件.在zip内，创建结构-这些工件将如何加载到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
注意:在第1个示例中，我没有在文件名中使用任何-xxx(即，我使用的是普通的简单giga.jar而不是giga-9.8.0.jar)
上面的Upload/Deploy将生成文件(如以下快照所示):
因此，我们已经实现了想要的目标.实际上(显然是)，但是Artifactory通常不会以某种方式存储这些工件(因为它们应该嵌入文件名中的-x.x.x版本，并且工件ID应该与工件文件名匹配).现在，如果您想在Gradle构建文件中使用以下内容，则不能先使用-xxx版本名称上传文件名，其次，在我们的案例1中，工件ID是"gigaproject"( com/company/project文件夹后)，因此无法使用Gradle方式定义所需的工件ID和工件文件名.
compile 'com.company.project:gigaproject:CANNOTSAY_HOW_TO_GET_GIGA_JARorGIGAINSTALL_with_without_extension'
结论:可以以任何结构上传任何文件(Artifactory中带有/不带扩展名的文件)，但这取决于您的构建系统使用或不使用它的方式. -我从Artifactory储存库中删除了用case 1 .zip文件刚刚创建的结构，以尝试下一个case#2，并删除了我创建的.zip文件.
案例2:
让我们为每个工件创建一个单独的版本化文件名，并以以下格式创建结构-Artifactory实际存储它们的方式(在树状视图的存储库中看到的工件)并创建一个包含该结构的.zip文件.让我们使用相同的工件捆绑包"功能上传此.zip文件，以上传Artifactory中需要的单个工件-其中artifact-id(我们尝试使用它时提到的第二个值)将与Artifactory中的工件文件名称匹配./p>
.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
注意:这次，我们将使用相同的工件捆绑包"功能，并且对于相似的文件(两个Linux/Solaris文件夹下的gigainstall)，我采用了创建gigainstall文件夹的方法(包含gigainstall-9.8.0.linux和gigainstall-9.8.0.solaris文件名)，即当我们在依赖项{...}下的Gradle中使用这些工件进行编译时，我们将使用xxx @方式来获取这些工件Artifactory中的人工制品.
好的，一旦工件捆绑包"的部署/上传成功完成，我得到以下消息.
Successfully deployed 7 artifacts from archive: gigaproject.zip (1 seconds).
现在，让我们看一下在Artifactory中搜索其中一个工件/在Tree视图中时的外观.您可以看到我们现在已经使用文件名-x.x.x.extension的方式放置了这些文件，以便我可以在Gradle中轻松使用它们.
在Gradle构建文件(build.gradle)中，我会提到:
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 !! -没用，请参阅下面的Gradle错误.为什么? -Artifactory Bundle上载/部署功能可将zip文件中的内容上传到zip文件中，但不会根据其部署的工件创建.pom文件.因此，使Gradle构建失败.可能在Ant中可能会成功.对于每个单独的.jar/.war/.dtd/etc文件，都会发生这种情况.我只是显示一个错误示例.
在进行渐进式构建
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文件，此方法需要-在文件夹/文件结构的单个工件/文件名中没有嵌入x.x.x版本值.我们将使用单一工件"方法(它将在Artifactory提供的上载/部署过程中自动为gigaproject.zip文件创建.pom).使用这种方法，您仍然可以获取gigainstall文件，而无需对其名称进行任何扩展.如您所见，在上载/部署步骤中，您上载了gigaproject.zip，工件将其作为"gigaproject- xxx .zip"上传到给定的目标存储库，其中 xxx 是 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
现在，使用单一工件"功能将其上传到Artifactory.调整GroupId，ArtifactId，Version等的值后，单击部署工件".
上传后.您将在目标存储库的zip工件中看到(我举了一个错误的例子，通常是libs-snapshot-local或libs-release-local而不是ext -...)，您将可以使用ZIP工件直接在Graddle中:
dependencies {
// This is the only line we need now.
compile "com.company.project:gigaproject:9.8.0@zip"
}
一旦.zip可用于Gradle构建系统，现在您可以告诉Gradle在您的build/workspace区域中的某个位置解压缩此.zip文件，您可以在其中馈送实际的(未解压缩的)文件(gigainstall，.dtd，.jar) ，.war等).
PS :我猜想案例1和案例2适用于Ant.
答案2:
如果您以任何一种方式上载了未扩展的文件.确保您也手动创建/上传了其POM文件(即，如果我在 com/company/project/gigainstall/9.8.0/gigainstall-9.8.0 ，然后在同一级别上，我必须/应该创建它的POM文件(请参阅简单的模板.pom文件以获取自定义jar工件，或者通过单一工件"部署上传扩展文件时，您会看到 POM编辑器窗口向您显示)并同时上传两者，这样Gradle不会出错，说明没有POM冲突/错误.Ant可能不需要pom(我没有检查).
一旦出现在Artifactory中，下面的行就应该起作用-如果您发现其他方法，请发表评论.
dependencies {
// See nothing mentioned after - x.x.x@
compile "com.company.package:gigainstall:9.8.0@"
}
I have the following files which I would like to upload to Artifactory as a 9.8.0 versioned artifact.
NOTE: The first two files DO NOT have an extension (they are executable files i.e. if you open them/cat on it, you'll see junk characters).
Folder/files of a given version 9.8.0 in CVS is like:
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
Uploading the above files which have an extension is very easy... You log in to Artifactory as an administrator/user which has access to deploy artifacts, click on "Deploy" tab, browse for the Artifactory file and once you select the file, click on "Upload" button.
Next you'll see a screen (like shown above). You'll tweak what you want in the fields on this page and once you click on "Deploy Artifact", you are done. All you have to make sure is you select the correct file.extension file while uploading and make sure the file extension is shown in the "Target Path" box correctly (with the version -x.x.x, etc.).
My questions:
Question 1: How do I upload an artifact which doesn't have an extension? It seems like Artifactory by default takes an artifact as a .jar extension. How can I upload the "gigainstall" artifact as shown in the folder/file structure above for both Linux and Solaris? I see I can use the artifact name as gigainstall-linux and gigainstall-solaris and differentiate it, but I am not sure how to tell Artifactory that this artifact doesn't have any extension.
I don't think the development team will start generating this artifact with a proper extension (as this artifact may be hard coded everywhere in other projects where they are currently getting it from CVS/SVN source control somewhere - which is itself a bad practice to store an artifact in a source control version tool).
Question 2: How would I tell a build system (for example, Gradle) to consume a non-extensioned artifact during, let's say, 'compile' task. In build.gradle under section dependencies { .. }, I will add something like as shown below, but I am not sure for non-extensioned files (the first two in the folder/file structure I mentioned above).
dependencies {
//compile 'com.company.project:gigainstall-linux:9.8.0@'
//compile 'com.company.project:gigainstall-linux:9.8.0@??????'
//compile 'com.company.project:gigainstall-linux:9.8.0@""'
//compile 'com.company.project:gigainstall-linux:9.8.0@"none"'
//compile 'com.company.project:gigainstall-linux:9.8.0@"NULL_or_something"'
// The following will easily get giga.jar version giga-9.8.0.jar from Artifactory repository
compile 'com.company.project:giga:9.8.0'
// The following will easily get giga.war
compile 'com.company.project:giga:9.8.0@war'
// Similarly, other extension based artifacts can be fetched from Artifactory
compile 'com.company.project:gigafile:9.8.0@dtd'
compile 'com.company.project:gigaanotherfile:9.8.0@dtd'
}
Answer 1 (will cover 2 as well in a different sense): Using Artifactory "Artifact Bundle" feature section under "Deploy" tab can do the TRICK for AT LEAST uploading the artifacts in a way we want, by creating a zip file first (containing the structure and artifacts in it) --OR you can upload the artifacts using/calling Artifactory REST API way.
High level idea:
Create a zip file called gigaproject.zip OR anyname.zip/.tar/compressed file which Artifactory can read. Inside the zip, create the structure - how these artifacts will be loaded to Artifactory
i.e. gigaproject.zip will contain the following folders/structure/files.
Case 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'
Conclusion: It's possible to upload any files (with/without extension in Artifactory) in any structure but it depends how your build system will consume it or will be able to consume it or not. - I deleted the structure I just created with case 1 .zip file from Artifactory repository to try next case#2 and deleted the .zip file I created.
Case 2:
Let's create an individual versioned file name for each artifact and also create structure in the format - how Artifactory actually stores them (an artifact as seen in a repository in a tree view) and create a .zip file containing that structure. Let's use the same "Artifact Bundle" feature to upload this .zip file to upload individual artifacts that we need in Artifactory - where artifact-id (second value which we mention while trying to consume it) would match the artifactfile name in Artifactory.
Folder/file structure for the .zip file:
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
Case 3: Let's take a simple approach (workaround but will save a lot of pain). Create gigaproject.zip file with the following structure, this approach takes - No x.x.x version value embedded in the individual artifact/filename in the folder/file structure. We will use "Single Artifact" approach (which will create the .pom for gigaproject.zip file automatically during the upload/deploy process provided by Artifactory). You'll still be able to get gigainstall file without needing any extension to its name using this approach. During the upload/deploy step, as you already have seen, you upload gigaproject.zip and artifactory will upload it to a given Target Repository as "gigaproject-x.x.x.zip" where x.x.x is 9.8.0 in our case. See the image snapshot below.
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"
}
Once the .zip is available to Gradle build system, now you can tell Gradle to unpack this .zip file somewhere in your build/workspace area where you can feed the actual(unpacked) files (gigainstall, .dtd, .jar, .war, etc.) to the build process/steps.
PS: Case# 1 and 2 would have worked for Ant I guess.
Answer 2:
If you have uploaded a non-extensioned file in either way. Make sure you have manually created/uploaded its POM file as well (i.e. if I uploaded gigainstall-9.8.0 as an artifact under com/company/project/gigainstall/9.8.0/gigainstall-9.8.0, then at the same level, I have to/should create it's POM file (see a simple template .pom file for a custom jar artifact or while uploading an extensioned file via "Single Artifact" deploy, you'll see what POM Editor window shows you) and upload both so that Gradle won't error out saying no POM conflict/error. Ant might not need pom (I didn't check that).
Once it's there in Artifactory, the following line should work -- OR comment please if you find another way.
dependencies {
// See nothing mentioned after - x.x.x@
compile "com.company.package:gigainstall:9.8.0@"
}
这篇关于如何将工件上传到Artifactory/在没有工件扩展名的构建系统(Gradle Maven Ant)中使用它的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
