When i create a maven prject which depend smtp 1.5.0, during updating denpendencies,
but the version exsit in center repo,
below is center repository config in my nexus(v2.2-01),
after do the operate (expire cache, repair index,update index)below,
Updating the project dependency again, but no use.
i check the storage browser,index browser, remote browser,
it seems my nexus has not get the index from center, and also has not get the smtp jar.
so what happened to my nexus?
Related
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 successfully installed Nexus OSS 3.2, but I get no search results, for example for "junit". Also under Browse / Components / Maven Central are no components listed.
I found NEXUS-9563 with following answer:
This means that the search indexes from Central haven't been downloaded. Have you set "Download Remote Indexes" to "true" in the central proxy repository's configuration?
But I can't find an option "Download Remote Indexes" in Nexus OSS 3.2. See proxy settings for Maven Central:
I tried:
Button Rebuild index:
The Rebuild Index button allows you to drop and recreate the search index for the proxy repository, synchronizing the contents with search index. This button is only available for proxy repositories.
Task of type Publish Maven indexes:
Maven indexes can be used to download an index of available components to a client including a developer’s IDE, for example. The task publishes the index for all or a specific Maven repository.
but nothing downloaded the remote index.
How can I download the remote index of a proxy?
Nexus Repository Manager 3.2 does NOT support usage of remote index for searches (and other purposes) at all. If you want this feature I suggest to stick with Nexus Repository Manager 2 for now.
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.
We're deploying our open source libraries to the OSS instance of Sonatype Nexus (https://oss.sonatype.org/) using the nexus-staging-plugin. This works all fine and well. However, since we're using a build server I want to block an accidential re-deployment of an existing artifact id - as this is normally not suppoted by maven. However, the OSSRH happily accepts and updates an existing release. Is there any way to block this and make the build fail?
I know that Nexus can be configured to do that - it is just, that I don't have any permissions to reconfigure the OSSRH instance..
Is there any maven plugin which could check the repo first and fail in first place in case nexus/sonatype does not support this? I looked into the enforcer plugin but there isn't a rule available.
It is true that there is a staging rule in Nexus which prevents duplicate GAV's being staged, but it is not enabled on https://oss.sonatype.org. The reason for this is that some users stage artifacts repeatedly (creating multiple staging repositories) and then choose one of them for release based on testing results.
But the server at https://oss.sonatype.org is configured so that you cannot release the same artifacts twice. So if you have two staging repositories that contain the same artifacts you will only be able to release one of them.
I work for a large company where we use an internally installed maven proxy for downloading dependencies. We have to use a proxy as our Network(Websense) does not allow downloading of files with the .jar extension. So whenever a pom declares an external dependency, maven tries to the get the jar files from the proxy. If it is not there in the proxy, the proxy will itself download it from the internet as the proxy is outside the purview of this Websense Nonsense. This method while not perfect works by and large.
The things that don't work are
Whenever we need to include a dependency for which there is no repository declared in the proxy server, that repository url has to be included manually.
The internal maven proxy does not have enough bandwidth to scale up. Some days it takes 10 minutes to download 7 MB jar file.
As a workaround we were thinking that if it were possible to install a P2P plugin in maven, then whenever a jar file is required maven could first check peers (for example local maven repo of the developer sitting next to me) before hitting the internal maven proxy. This will dramatically reduce the time it takes to download dependencies and also potentially avoid the bureaucracy of having someone to put an email to manually add maven repository urls.
You should install a repository manager (Artifactory, Archiva, Nexus in alphabetical order). The intention is to a have a single point which access the internet via the proxy and that should solve the problem. All developers only access the repository manager.