jfrog / bower-art-resolver

Apache License 2.0
15 stars 17 forks source link

Wrong bower-package-content when resolving through bower-art-resolver #21

Closed mhofstetter closed 8 years ago

mhofstetter commented 8 years ago

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:

.
├── all-imports.html
├── bower.json
├── CONTRIBUTING.md
├── index.html
├── ISSUE_TEMPLATE.md
├── paper-icon-item.html
├── paper-item-behavior.html
├── paper-item-body.html
├── paper-item.html
├── paper-item-shared-styles.html
├── pax_global_header
└── README.md

0 directories, 12 files

Content of the tar from github-repository

.
├── all-imports.html
├── bower.json
├── CONTRIBUTING.md
├── demo 
         └── index.html
├── index.html
├── paper-icon-item.html
├── paper-item-behavior.html
├── paper-item-body.html
├── paper-item.html
├── paper-item-shared-styles.html
├── README.md
└── test
         ├── index.html
         └── paper-item.html

2 directories, 13 files

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

eyalbe4 commented 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
mhofstetter commented 8 years ago

@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

mhofstetter commented 8 years ago

@eyalbe4: I think it's somehow related to the following issue: https://www.jfrog.com/jira/browse/RTFACT-10025

eyalbe4 commented 8 years ago

@mhofstetter thank you for this. RTFACT-10025 indeed describes this issue. Please track RTFACT-10025 for updates.

mhofstetter commented 8 years ago

@eyalbe4 I will do that. Thanks. I'll close this issue, cause it seems to be an artifactory server related issue.

eyalbe4 commented 7 years ago

@mhofstetter, version 4.13.1 of Artifactory includes this fix.