I had jcenter repository in my artifactory under remote repositories. Since some of the artifacts were missing such as qpid, I decided to delete jcenter and add it back. When I deleted the jcenter repository and added it back it didn't download any artifacts.
The repository tree structure looks like this
Before removing the jcenter repository it was like this.
Why it is not able to import any artifact? I can see the URL which is associated with it(http://jcenter.bintray.com/) has so many artifacts.
A remote repository in Artifactory serves as a caching proxy. This means that it downloads artifacts from the remote URL and cache them in Artifactory,
When you deleted the JCenter repository from Artifactory you deleted all cached artifacts.
After recreating the repository, your cache is empty. This is why, when browsing jcenter-cache, you see no artifacts. You can use the remote browsing capability in order to see which artifacts are available in the remote URL, but not currently caches
To re-populate the cache, you will need to download artifacts from the remote repository. Usually the best way to do it, is running your builds which are using this repository.
If the problem is that artifacts are not resolved at all from the remote repository, try the following:
Make sure the repository is configured correctly in Artifactory. Use the "Test" button to make sure that the URL is correct and you can reach the remote URL.
Check that your build tool is properly configured to use the repository you configured. One way of checking this, is by monitoring the Artifactory request log looking for requests from your build tool.
Deleting a repository is not a good practice when you are missing some dependencies. A better approach would be checking if they are available in the remote URL and downloading them into the cache. Artifactory has the option to perform a remote search in Bintray which can help you when looking for artifacts in JCenter.
Related
I'm trying to understand how to work with a remote repository in Artifactory for a Go project. My initial expectation was that it'll work transparently, all I would need to do is to point GORPOXY variable to a virtual repository (with local and remote behind it), do go build and dependencies will either be downloaded from the Artifactory cache or Artifactory would download them transparently. Similar to the way it works for maven dependencies.
When I tried that, it complained that the dependencies weren't found in artifactory. Ok.
Reading the documentation two things stand out. First, there's nothing there about GOPROXY and everything is about using artifactory cli. That's a big downside for several reasons.
Second, is that you need to publish dependencies manually with jfrog rt go-publish go --self=false --deps=ALL and then dependencies appear under a local repository.
So I'm trying to figure out if 1) I can avoid using JFrog CLI and 2) what's the point of remote repositories if they don't proxy? Or maybe I'm missing something?
Artifactory 6.3.0
I understand your confusion on the blog post you mentioned, though I have a feeling the intent of the writer was to more show how the JFrog CLI can be used.
To answer your questions:
1) Yes, you don't have to use the JFrog CLI to build. Please check out the documentation on how to set up a remote repository for Go. This will guide you through setting up GitHub or GoCenter as a remote repository for your Go builds. This will allow you to set the GOPROXY environment variable following this structure <protocol>://<username>:<password>#<artifactory domain>/api/go/<go repository>.
2) Remote repositories will absolutely act as a proxy, caching the contents you download from the remote repository (copying a part from the user guide: A remote Go repository in Artifactory serves as a caching proxy for a public Go registry such as GoCenter or GitHub.)
Using Springframework Repo central in China is a pain. I am thinking about to build a mirror for springfw repo.
Like there are plenty of mirrors around the around for maven center repo.
And I know the structure for maven center and springfw repo are both artifactory from Jfog.
So I think it is possible to set up a mirror for springfw, right?
I've used Sonatype Nexus to do this before, it's available in an open source version that you can run yourself.
I'd recommend setting it up in proxy mode which means that you will fetch all your artifacts from it and it will in turn fetch artifacts from the upstream mirror the first time and then serve them from a local cache in the future.
I'm new to Artifactory. I'm trying to understand better how the remote repository cache mechanism works.
Right know I have 3 imported remote repositories at the system:
google-code-cache.
java.net-cache.
jcenter-cache.
At the first two (google and java), After I'm entering to the remote url and downloading an artifact it seems to be saved at the repository-cache.
At jcenter that doesn't work. even if I'm downloading a file the file doesn't goes to the cache.
Can anyone help me understand better the logic behind the cache mechanism - when does it save the artifacts at the cache and when it's don't?
Thanks,
Nadav
First of all, with JCenter you don't need the other repositories. You'll be able to retrieve all the artifacts from java.net and google-code directly from jcenter.
Second, the easiest way to configure remote repositories is using the configuration import functionality. Just click on the Import button. The default server to import from will be repo.jfrog.org, which is a good choice, since it has a lot of remote repos to choose. Select 'jcenter' from the list of the proposed repositories and it will be added to your Artifactory and configured correctly.
I have small open-source projects hosted on Github which I want to make available for others via Maven. I have a small webspace where I can host static files. How can I create a repo? Also, I would want to remove old snapshots from there if possible.
Standard maven repository implementations are almost all Tomcat web apps. Each one of them should have a static repository, just as your local repository. The webapp serves to the purpose of searching and management of the artifacts stored in that static repository.
If you want to host the repository with static web access only, you'll have to perform the management manually and provide a static manually generated html page that contains GAV coordinates of all artifacts in the repo. No other user but you could ever upload to the repository unless you give your password or enable anonymous FTP acces.
If maven doesn't try to upload anything to the repo until the deploy phase then this approach is still partly usable, since running a mvn clean deploy should fail.
You can check if is it doable like this (I suppose that you have that projects in your local repo):
upload your local repoistory folder to a URL
for the purpose of testing mirror your central repo to that URL
try to build your project with dependencies from your repo
Open your settings.xml file and under <mirrors> node add:
<mirror>
<url>http://your/url/repo</url>
<mirrorOf>*</mirrorOf>
</mirror>
and see if mvn clean install suceeds. Please feedback.
In this SO answer I have outlined the way I set up my OSS projects which are all hosted in Github. There are actually a number of free services out there you could you when you would like to run an OSS project.
I would recommend publishing to Maven Central, if your plugin is well-tested and expected to bring other people benefits as well. You can use CloudBee's BuildHive as a free Jenkins CI.
A static repo works great, per my experience.
I scp'd up my local repository into a static apache server. Legit repo. Not as easy to maintain as a real repo of course, but quite a bit cheaper if you've already got a plain vanilla web host.
Other than setting the permissions properly (same as required for you to browse the folders), it was a pretty painless procedure.
The only two things I did to make it more reasonable were
1 - Wrote a script to "rm -rf ...." on most of the contents of my local repo so that the only thing I am deploying is those few artifacts that are not available in the general repos.
2 - Tarred it up first before scping to my web host.
Hope this helps.
The guy below did something similar, only using FTP which saves him a lot of hand work if he updates his binaries very often.
http://stuartsierra.com/2009/09/08/run-your-own-maven-repository
I think I know how to do it now. I'm using mvn deploy now to create a local repository on the file system and then I upload it to the webserver. If I'm not wrong, there doesn't even need to be a file listing.
The command I'm using is:
mvn deploy -DaltDeploymentRepository=local::default::file:./repo
This creates/updates the local repository automatically, so the repo can be synced with a server.
I'm trying to add a proxy to a public repository (specifically camel-extra). However, I get the following error in my Nexus logs:
Cannot fetch remote index for repository camel-extra
and then further down:
The remoteURL we requested does not exists on remote server (remoteUrl="http://camel-extra.googlecode.com/svn/maven2/releases/.index/nexus-maven-repository-index.properties")
I've ensured that 'Download Remote Indexes' is 'True', repaired the index, updated the index, all to no avail. Browsing to the provided URL shows that the artifacts are there.
So if a repository doesn't have this file, is it not proxy-able through Nexus?
TIA,
Roy
UPDATE
Thanks for the answers everyone - was able to pull the artifacts without the index. Thanks again!
Repositories without indexes published will be still proxy-able thru Nexus (or any other MRM). Index is only a "topping" providing useful extras like searching the whole remote content, etc.
The index does not participate in proxy-ing at all, hence the lack of it on remote does not affect main functionality of Nexus at all: to proxy artifacts from remote repository.
From the nexus documentation, it appears that downloading an index is configurable.
The default for new proxy repositories
is enabled, but all of the default
repositories included in Nexus have
this option disabled.
You should disable the Downloading of Remote Index.
Yes, it is proxyable. Just try to download an artifact which is hosted in that repository. The indexes only affect searching and the index published in turn by Nexus.