How register commands works with Artifactory and how to unregister a package

How register commands works with Artifactory and how to unregister a package

AuthorFullName__c
JFrog Support
articleNumber
000003513
ft:sourceType
Salesforce
FirstPublishedDate
2017-01-01T09:36:17Z
lastModifiedDate
2023-01-22T11:05:15Z
VersionNumber
2

 Once you register a package with Artifactory, on the remote repository there is a property that is being added: bower.pkg.{package_name}. The value of this property is actually the path to the package on your remote server (user/package_name). When you perform a search for the package (with the install, info, search commands for example) then Artifactory search for the property bower.pkg.{package_name} and creates the URL from the property value. On the Bower end, the package information are kept in the cache. This means that if the package requested is in the cache then Bower will use the cache to send to Artifactory the package coordinates. For example:

For the first request:

bower info mypackagetest

bower mypackagetest#*       not-cached art://sup/mypackagetest#*

You can see the coordinates are not in the cache and Bower is writing not-cached for those coordinates.

For the second request, since it’s already cached, the return will use the cache:

bower info mypackagetest

bower mypackagetest#*           cached art://sup/mypackagetest#1.3.1

Another point that since you performed a bower register command on an existing package, the property was added with additional value. This is not supported by Artifactory. Artifactory will always use the first property value to create the appropriate coordinates.

For example, create a package with multiple tags and deployed to our server under the user alexeiv. The property was created with the value ~alexeiv/mypackagetest and upon running the bower info it worked:

bower info mypackagetest

bower mypackagetest#*       not-cached art://~alexeiv/mypackagetest#*

bower mypackagetest#*          resolve art://~alexeiv/mypackagetest#*

bower mypackagetest#*         resolved art://~alexeiv/mypackagetest#1.3.1

…..

Available versions:

 - 1.3.1

 - 1.3.0

 - 1.2.4

 - 1.2.3

 - 1.2.2

 - 1.2.0

We changed the repository so now it’s under sup/mypackagetest. We run the bower register command again and the property was updated with additional value sup/mypackagetest. Now we run the bower info command. It failed since it went to the previous coordinates:

bower info mypackagetest

bower mypackagetest#*           cached art://~alexeiv/mypackagetest#1.3.1

bower mypackagetest#*         validate 1.3.1 against art://~alexeiv/mypackagetest#*

bower                         EREQUEST Request to http://localhost:9090/artifactory/api/bower/bower-stash/refs/~alexeiv/mypackagetest returned 404 status code.

As you can see Bower uses still the cache. We run the bower cache clean command and run the bower info again, however, still got the same result:

bower info mypackagetest

bower mypackagetest#*       not-cached art://~alexeiv/mypackagetest#*

bower mypackagetest#*          resolve art://~alexeiv/mypackagetest#*

bower mypackagetest#*         EREQUEST Request to http://localhost:9090/artifactory/api/bower/bower-stash/refs/~alexeiv/mypackagetest returned 404 status code.

This occurs since there are multiple values to the same package name. Once we removed the old value and cleaned bower cache again, it worked:

bower info mypackagetest

bower mypackagetest#*       not-cached art://sup/mypackagetest#*

bower mypackagetest#*          resolve art://sup/mypackagetest#*

bower mypackagetest#*         resolved art://sup/mypackagetest#1.3.1

….

Available versions:

 - 1.3.1

 - 1.3.0

 - 1.2.4

 - 1.2.3

 - 1.2.2

 - 1.2.0

 If bower install still goes to the old registry, you will need to remove the old value from the properties of the remote repository (Can be done in the Artifactory UI → Artifacts → Repository name → Properties tab). You also need to run the bower cache clean. After those operations you will be able to run the bower info command.