Open chrisvdp opened 8 years ago
same issue here. For every occurrence of this that I've come across, I think the git repo is either missing the bower.json altogether, or the version attribute isn't being provided in the published bower.json. We've been struggling with a lot of Artifactory resolution issues when version isn't provided in bower.json. That reliance should probably be reviewed since the version property is now deprecated.
Artifactory Professional 4.5.0 rev 40115
@mattlewi and @chrisvdp, The issue you're experiencing could be caused by the fact that you have external dependencies declared in bower.json (dependencies that include a direct git URL). If you use a Virtual Repository in Artifactory to resolve your bower dependencies, you can configure it to re-write the URL for those dependencies and by that enforcing their resolution from Artifactory. You can read about it in the Bower Repositories Documentation page. @mattlewi - as for the point you raised about the version property deprecation: When resolving from Remote or Virtual Repositories, Artifactory lists the packages version by querying the existing tags in the Git repository, so the fact that that the version property became deprecated by Bower should not effect that. You will however still need to declare the version property when deploying your packages to Artifactory.
hi @eyalbe4
I'm facing the same issue behind artifactory pro 4.7.0. I'm using a Virtual Repository with url re-write enabled.
The problem occurs if a third-party dependency uses the bower GitHub shorthand variant in the dependency-section as version. e.g. "Polymer/polymer#^1.2.0" ==> github name/repo. See https://bower.io/#install-packages
"dependencies": {
"polymer": "Polymer/polymer#^0.5",
"core-icon": "Polymer/core-icon#^0.5",
"core-icons": "Polymer/core-icons#^0.5",
"core-input": "Polymer/core-input#^0.5",
"core-style": "Polymer/core-style#^0.5"
}
In this cases the bower-client doesn't make a lookup, justs "appends" this string to the github.com url.
bower polymer#^1.2.0 resolve git://github.com/Polymer/polymer.git#^1.2.0
I think this case isn't included in the re-write functionality of the artifactory server, nor in the bower-art-resolver.
Thanks @mhofstetter. We're looking into this and will update soon.
@mhofstetter, thanks for reporting this issue. We made sure version 4.11.0 of Artifactory supports Bower's shorthand-resolver. 4.11.0 is planned to be released soon. You'll also need to add the following line to your .bowerrc file: "shorthand-resolver": "art://{{owner}}/{{package}}" We will also try to improve the bower-art-resolver code, so that it adds the above configuration to the bower configuration automatically. We'll update here when this is done.
Thank you very much @eyalbe4. I will try this as soon as we can update our artifactory server to the latest version.
@mattlewi and @chrisvdp, Did you get a chance to try this out with version 4.11.0 or above of Artifactory?
We upgraded to 4.14.0 last week (from 4.5). We'll keep an eye out for a reccurrence of this issue.
Thanks for following up!
Matt
On Oct 30, 2016 9:56 AM, "Eyal Ben Moshe" notifications@github.com wrote:
@mattlewi https://github.com/mattlewi and @chrisvdp https://github.com/chrisvdp, Did you get a chance to try this out with version 4.11.0 or above of Artifactory?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JFrogDev/bower-art-resolver/issues/16#issuecomment-257152417, or mute the thread https://github.com/notifications/unsubscribe-auth/AGkTOxzwPLea7tMgmY9jVr_Yyr8E1Wxhks5q5KImgaJpZM4HnoL4 .
@eyalbe4 We are still running 4.4.3 rev 40110. I'll try and get it upgraded to see if it fixes the issue, in the meantime feel free to close the bug, I can reopen if it is still an issue.
A very specific set of our bower packages are resolving to github instead of artifactory.
running
bower i
showsAll packages that use semver symantics resolve correctly. We are using Artifactory v4.4.3
Full output