Closed mhofstetter closed 8 years ago
@mhofstetter, I tried to replicate this issue with Artifactory Pro 4.7 and the latest release of bower-art-resolver. I tried:
bower install PolymerElements/paper-item
As you can see below, the demo and test directories were created. Did you try to right click and then Zap Cache on your remote repository in the Artifactory Tree Browser? Any other way I can reproduce this scenario?
eyalb-mac:p-art eyalb$ ll bower_components/paper-item/demo/
total 16
-rw-r--r-- 1 eyalb staff 6466 Apr 15 21:02 index.html
eyalb-mac:p-art eyalb$ ll bower_components/paper-item/test/
total 24
-rw-r--r-- 1 eyalb staff 1015 Apr 15 21:02 index.html
-rw-r--r-- 1 eyalb staff 7052 Apr 15 21:02 paper-item.html
@eyalbe4, "zap cache" my repositories doesn't help - the remote repo and the virtual one.
Do you also tested it with a virtual repository in front of the remote one?
As I said: the cached content in the remote-repo looks good, the one in the virtual-repo doesn't.
How does the content of your tar.gz looks like when you retrieve the file from the artifactory rest-api with the following URL: http://ARTIFACTORY-URL/artifactory/api/bower/VIRTUAL-REPO-NAME/binaries/polymerelements/paper-item.git/v1.2.1 ?
The content of my ~/.bowerrc file looks like this:
{
"shorthand-resolver": "art://{{owner}}/{{package}}",
"registry": "http://ARTIFACTORY-URL/artifactory/api/bower/bower-virtual",
"resolvers": [
"bower-art-resolver"
]
}
Correct Version number of artifactory pro: 4.7.0 rev 40155
@eyalbe4: I think it's somehow related to the following issue: https://www.jfrog.com/jira/browse/RTFACT-10025
@mhofstetter thank you for this. RTFACT-10025 indeed describes this issue. Please track RTFACT-10025 for updates.
@eyalbe4 I will do that. Thanks. I'll close this issue, cause it seems to be an artifactory server related issue.
@mhofstetter, version 4.13.1 of Artifactory includes this fix.
When I download bower-packages from a virtual bower-repository through the bower-art-resolver, I have the issue, that the output in bower_components differs from the one downloaded directly with the github-resolver. This results in following build-problems.
It looks like the content of the github-repository which is hosting the bower-package lays "flatten" in the bower_components directory. Means, that the content of all subfolders of the github-repository are merged into the root of the tar.gz. which is ok in an archive - but after unpacking only the last file of the same name exists. e.g resolving "paper-item" (https://github.com/PolymerElements/paper-item/tree/v1.1.0) results in 3_index.html (root + 2_subdir) in the tar.gz. (the same for all other "duplicates")
Content of bower_components/paper-item after resolving through bower-art-resolver:
Content of the tar from github-repository
The tar.gz file which is cached in the-cache repository looks exactly like the content from the github-repo with the same version. I checked this by downloading the tar.gz via the Artifact Repository Browser UI. But the tar.gz of the same bower-artifact which is stored in the repository differs and looks like the wrong content in the bower_components directory. And this is also the tar.gz which I get when downloading the file through the REST-api "http://HOST:PORT/artifactory/api/bower/bower-virtual/binaries/polymerelements/paper-item.git/v1.2.1" - and when I look at the source from bower-art-resolver it's probably the reason why the content of the bower_components directory is wrong.
Artifactory Pro 4.7