I am using curl command to manually add artifacts in the nexus repository. What will happen in the case if I reupload the artifact of the same version which is already present in the nexus repo. Does it replace the previous one or not push at all in the repo?
It depends on the settings of the repository.
If the "Deployment policy" is set to "Allow redeploy" then if the artifact reuploaded it will replace the original artifact
If the "Deployment policy" is set to "Disable redeploy" then if the artifact reuploaded it will result in an error.
Related
Some of the artifacts in my local Nexus repository don't have the correct checksum. For example (wrong checksum):
cat central/org/codehaus/plexus/plexus-compiler-api/1.8/plexus-compiler-api-1.8.pom.sha1
95f3332c2bbace129da501424f297e47dd0e976b
vs (correct checksum):
sha1sum central/org/codehaus/plexus/plexus-compiler-api/1.8/plexus-compiler-api-1.8.pom
4c2947f7e2d09b6e13da34292d897c564f1f9828
It looks like I have a few artifacts in my repository that were downloaded when this bug was active.
Maven Central has the correct checksum (4c29...) now, but the checksums in my local Nexus repository remain stale. I don't know how to get my local repository to verify and / or re-download the correct checksum from central.
What is the correct way of fixing my local repository. There aren't too many artifacts with this problem, so I think I could (by hand) verify they still exist in central and delete them from my local repository. They should get re-cached with the correct checksums. Is there a better way?
Update:
I've looked at this more and I'm almost positive I know what the source of my problem is. One of the artifacts I'm having trouble with is this one (plexus-compiler-api:1.8):
In my repository, both the .pom and .pom.sha1 are timestamped as 29-Mar-2010. At central, the .pom is timestamped as 29-Mar-2010 while the .pom.sha1 is timestamped as 21-Apr-2010. I was reading about Nexus maintenance. I assume that, on 21-Apr-2010, Maven Central rebuilt metadata and verified checksums which fixed the incorrect .sha1 for the plexus-compiler-api:1.8 artifact.
According to the Sonatype link above, I should be able to expire the caches for Maven Central and have my local installation pull new copies of anything with newer timestamps than the originally cached artifacts. However, based on the behavior I've observed, I think it's only checking timestamps for artifact files, not checksum files.
As far as my local Nexus repository is concerned, I have the most recent version of the artifact (29-Mar-2010), so there's no need to re-download anything.
I've noticed my version of Nexus is quite old (1.5 vs 1.9.1), so I'll try updating and see if the newer version does a better job of expiring caches. If not, I'll probably see what the Sonatype guys think (maybe it's a bug?).
Nope, what you face is the defined behaviour of Nexus and Maven.
First, expiring caches does not delete anything from local cache of Nexus, it just marks them "old". The effect of marking items as "old" is shown on next incoming request asking for those same artifacts (if never asked for, the "old" artifacts just sits there). Meaning, expire cache alone will not cause Nexus to download remotely changed (newer) files. Nexus never downloads on it's own (if we leave out the index from this discussion). You have to force a client (Maven) ask for them – and that will result following chain of action: "cache content old", remote change detection and finally re-download and caching of the new file.
Next, what happens here is that Maven, since artifact (the JAR file) is not changed, not even asks for checksum file either, hence nothing "triggers" the "old" marked checksum refetch on Nexus side. Other to note, if we talk about released artifact (and Maven Central does contains released artifacts only), Maven will never re-check them, unless they are not present in local repository (once brought into local repository, Maven will never try to refetch them). Meaning, you need to remove them from local repository to be sure that Maven will ask for them from Nexus, and finally, that Nexus will detect the checksum file changes on remote and do what you actually want.
Re-download should happen, for example if you nuke your Maven's local repository and rebuild with a clean/empty one. In this case, Maven should ask for both, JAR artifact and checksum file – but from your description it's not clear how did you (or did you?) invoke Maven after expiring caches on Nexus.
Try this:
a) run expire caches on Nexus "Maven Central" proxy repository
b) nuke local repository (or just redirect it to a new clean folder by tampering ~/.m2/settings.xml
c) make Maven build your project, and it should refetch both, the JAR and checksum files (by using empty/nuked local repository)
Hope this explains some of the stuff you wrote.
Reference to JIRA issue discussing same thing.
This was a bug.
As explained by Tamas, when a proxied repository cache is expired, Nexus will check the remote repository for newer timestamps. The locally cached artifacts are essentially flagged dirty and the check for updated artifacts happens on demand as artifacts are requested from the local Nexus server.
Nexus (1.9.1) is making the assumption that if an artifact timestamp is unchanged, the checksums should be unchanged as well. Most of the time this will be true, but, due to the old bug in Maven that was deploying artifacts with incorrect checksums, there are rare cases where an artifact can be unchanged yet have an updated checksum.
I think the best way to deal with this for now will be to move any bad checksums and let Nexus try to re-resolve them the next time they are requested:
mv plexus-compiler-api.pom.sha1 plexus-compiler-api-1.8.pom.sha1.bak
Thanks for the help Tamas.
I have an installed dependency in my local repository. The remote repository where the dependency came from is now down for some reason. When I try to compile the project Maven says that it can't resolve dependency. But why???
When you have these error, simply clean the _remote.repositories that indicate maven where the dependency comes from. You will find this file for each artifact inside your M2_REPO.
Maven will compare the local POM's timestamp (stored in a repository's maven-metadata file) to the remote. When maven does this depends on the updatePolicy that can be defined in your settings xml.
Either set this to never (discouraged) or skip this check (only when a remote repository appears to be down) by using the -o option (offline); then maven will not check remote repositories.
When using Alt-Insert to insert a dependency into the POM, the Artifact Search is always completely blank regardless of what I search for.
I tried to add repo1 to Settings->Maven->Repository Services, it says "no repository found." I find that hard to believe.
I've also tried to "update" my local repository but that results in an error.
FYI I'm using Community Edition Snapshot.
Thanks!
If you have a brand new IntelliJ install and have never updated your Maven Repository, notice that there is a little "Update" button to the right that becomes clickable when you click on each repository.
Preferences > Build, Execution, Deployment > Build Tools > Maven >
Repositories
The important one is the https://repo.maven.apache.org/maven2/ remote repository, make sure you update it.
I used Artifactory to generate a settings.xml for me, and by default it pointed me to the "libs-releases" repository.
Instead want my "releases" repository to point to the much larger virtual repository "remote-repos."
All it took was a simple change to the options of the "Generate Settings" function.
Weird. The Artifact Search is working fine for me with IntelliJ Community Edition, at least for artifacts from the central repo that has been indexed:
And as you can see above, all repositories declared in POMs known by IntelliJ are listed.
There might be something wrong with your Maven settings. This is a wild guess but is your Maven home directory properly defined? Same for the user settings file? Is Maven actually working fine under IntelliJ?
Solved - by reinstalling Intellij Idea
Search for class tab in Maven Artifact Search popup was always empty
Solution in linux:
remove idea folder (for me it was ~/idea-YOUR_VERSION_HERE)
remove ~/.IntelliJIdeaYOUR_VERSION_HERE folder (settings)
download new version form jetbrains.com, unzip, run installer from bin
It appears to be a blocked port, as I am using my own artifactory repository. Of course, the port it is using looks to be completely undocumented, but WireShark shows it to be 58754. Sounds random, I hope it isn't!
I have nexus 1.5.0 setup to proxy springsource repositories but it's not working. The repositories are on s3 that nexus doesn't seem to understand how to deal with that.
What's the right pattern?
Here are the repositories I'm told I need, but I cannot access the maven paths with in them
http://repository.springsource.com/maven/bundles/release
http://repository.springsource.com/maven/bundles/external
Do, I need to mirror these locally?
According to NEXUS-1121, your version of Nexus knows how to deal with S3 based repositories. Below, Eugene's comment:
Here is Nexus setup that works for me:
Configured "proxy" repository for http://repository.springsource.com/maven/bundles/release
Configured "proxy" repository for http://repository.springsource.com/maven/bundles/external
Added both of those repositories into default "Public Repositories" group
After that I am able to download
artifacts from those repositories as
if they are in Maven Central
repository.
The only issue is that you can only
search trough artifacts that been
proxied, because there is no Nexus
index published on those repositories.
It should be easy to publish index and
instructions for using standalone
indexer can be found at
http://docs.codehaus.org/display/M2ECLIPSE/Nexus+Indexer#NexusIndexer-indexer
It works for me with this configuration and with another repository.
I have a Sonatype Nexus repository version 1.9.1.1. I wanted to configure the repositories to download artifacts from http://maven.springframework.org/milestone/.
I have created a new proxy repository with this configuration:
id: repository.springframework.maven.milestone
Name: Spring Maven Milestone Repository
Rep. Type: proxy
Provider: Maven2
Format: Maven2
Rep Policy: Release
Remote storage: http://maven.springframework.org/milestone/
Down. Remote indexes: false
Auto blocking: true
File validation: False
Checksum: warm.
I saved the data and the repository was created.
The strange thing is that when i try to use the "browse Remote" tab I can't list anything.
Important: After that I clicked on Public Repositories / Configuration and added the Spring Maven Milestone Repository to the ordered group repositories.
And finally, I wrote the dependency in my POM archive:
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-jpa</artifactId>
<version>1.0.0.RC1</version>
</dependency>
And it was downloaded without problems.
I hope it will be useful.
I'd like to specify some artifacts that SHOULD NOT be downloaded from a remote repository, even if they are present there. Is there any way to achieve this in maven2?
Have you tried the offline mode?
mvn -o
Not sure if this is what you need, but you can declare a dependency with system scope, which tells Maven that a particular JAR is assumed to be in the classpath (e.g. one that is included in the java installation directory).
From the docs:
This scope is similar to provided except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository.
AFAIK, Maven treats the local repository basically as a cache of a remote repository, so there isn't any way to tell it not to get a particular dependency from a remote repo.
I'm not clear exactly what you're after, so here's answers to a few different interpretations:
If the artifacts are transitive dependencies, you can specify that the dependencies be excluded. See the Transitive Dependency Exclusion section of the Dependency Mechanism documentation.
If you want to make sure no artifacts are downloaded, you can set Maven to offline mode by passing -o as a command line switch, or adding <offline>true</offline> to your settings.xml
With the Nexus Maven repository manager, you can set up a proxy repository to the remote repository, and configure the proxy to block certain artifacts. You would do this by adding a "repository target" matching the artifact's groupId and artifactId, then create read permissions for the that target that the Nexus user doesn't have. Any user connecting to the proxy would then not be able to obtain that artifact. See the Nexus book for details, of configuring targets.
If none of these meet your needs can you elaborate on your question please.
One option would be to install a local copy of the file with the install-file mojo and give your copy a distinct name. Pre-pending "local." to the groupid name would make it easy to id in the pom files. If would also make it easy to switch out.
add it to your local repos like this:
mvn install:install-file -Durl=file://xmlthing.jar -Dinternal -Dfile=xmthing.jar -DgroupId=local.org.xmltool -DartifactId=xmlthing -Dversion=1.6.1 -Dpackaging=jar
You would then replace
<dependency>
<groupId>org.xmltool</groupId>
<artifactId>xmlthing</artifactId>
<version>1.6.1</version>
</dependency>
with
<dependency>
<groupId>local.org.xmltool</groupId>
<artifactId>xmlthing</artifactId>
<version>1.6.1</version>
</dependency>