I had a maven project which I successfully deployed to Sonatype.
All the checks were successful.So,I released it from Sonatype.
But even though Maven Central Sync has been activated,the project I released is not yet been released to Maven Central Repository.
Can anyone please suggest solution for this?
The artifacts should be published to central in 10-15 minutes, but it can take up to several hours before you'll see them in the search results at https://search.maven.org.
If it's been longer than that file an issue at https://issues.sonatype.org in the "Community Support - Maven Central" and we'll look into this for you.
Related
I get what internal libraries are. But what is the purpose of a snapshot repository in archiva?
Libraries - private releases
Snapshots - private builds?
I have archiva set up and working with LDAP, but I am wondering why I need a snapshot repository. What purpose does this solve? Why is this used in development?
Also, lets say I update a library in the internal repo. Does this automatically update in the project POM files which use Maven, or I must update those poms to use the new JAR version?
Usually before releasing a maven project, the version is -SNAPSHOT.
So with such repositories you can share fresh SNAPHOT of your project for other people in your team to test or with a ci server.
Snapshots is maven idea to give version number as -SNAPSHOT , its under development it can be change any time.
Internal repository is the release repository with fixed version number. You can modify the SNAPSHOT, but That artifact never changes after it is released.
When we use internal, if dependency does not found inside it, then it will download it from central repository of maven. where as in snapshot it does not.
I have 2 builds of the same project on the same Hudson/Jenkins server (they are running different build profiles). The both build when polling SCM, but I sometimes get the following error:
The plugin 'org.apache.maven.plugins:maven-checkstyle-plugin' does not exist or no valid version could be found
This only started once I added the second build, so I'm assuming there is some sort of conflict. Does anyone know what's going on here?
thanks,
Jeff
Are your builds running at the same time, with the same Maven instance and the same local Maven repository? If so, then maybe you run into a filelock on that plugin jar. I have the same problem here, if two jobs are accessing the same Maven artifact at the same time, they fail, because Maven can't handle that.
I solved that with two Maven instances, with a separate local repository.
It could also help, if you set the VCS polling of the second job a minute after the first job.
I'm in the process of deploying Nexus OSS as internal company repository.
One of the main requirements is that once a jar has been downloaded by Nexus (for example, when using is as a proxy of Maven Central) it will never change.
I know that Maven Central has that policy, but I'm using other repositories which are not under my control, and I have to validate that requirement on my side.
Does a Release repository policy ensures that once a jar is downloaded into that respository, it will never change?
The requirement exists to ensure we can go back to a version of our product created 1.5 years ago, and make sure the repository artifacts used by the product are the same when building it now.
Indeed, a release repository should strictly forbid content modification after a release, which is what Maven Central is doing:
2.2.4. The Central Maven Repository
(...) Here are some
of the properties of release
repositories such as the Central Maven
repository:
...
Release Stability
Once published to the Central Maven
repository, an artifact and the
metadata describing that artifact
never change. This property of release
repositories guarantees that projects
which depend on releases will be
repeatable and stable over time. While
new software artifacts are being
published to central every day, once
an artifact is assigned a release
number on Central, there is a strict
policy against modifying the contents
of a software artifact after a
release.
That being said, whether a Maven client will (re)download an artifact or not does not really depend on the repository and its policy, this is part of Maven DNA and it just won't happen (unless you delete the given artifact from your local repository of course). Quoting Brett Porter in [MNG-2528] - updatePolicy "always" does not work for repositories with "releases", at least not for transitive dependencies:
Releases in Maven are, by definition, unchanging. The always flag is to check for new releases (like it looks for new snapshots), not modifications to the existing one.
In other words, if you don't delete the content of your Nexus repository, Nexus will never re-download a released artifact again and you will thus be able to rebuild the version of your product created two years ago, using the exact same libraries.
I have open-sourced some of my projects. I'd like to publish the artifacts in a common place. If I don't have to host my own repository, that would be ideal, otherwise I will have to setup my own instance of Nexus (or other repository that you recommend).
Can I publish artifacts to Maven Central? What process do I need to follow to get them there?
Yes you can, especially if it is an open source project. Here is some info:
http://central.sonatype.org/pages/ossrh-guide.html
I have a stable opensource library and was wondering how (and if) I can publish my lib to maven official repositories so people can include it in their pom.xml files and get the dependency downloaded automatically.
The process to get your library in the central repostiory is documented in the Guide to uploading artifacts to the Central Repository. In short, the new process is to get your project hosted by one of the approved Forges that will be synced with central, the Maven folks don't rsync personal repository anymore. In your case, your best bet would be to use the Sonatype Forge (open to any OSS Project). Check the given link (and also this document).
If you want reliable access for everyone out there, you need to stick with central. Due to the tendency of people at dev.java.net to break rules about the immutability of released artifacts, some people don't trust it. Further, it can be Very Slow.
To get your project into central, you need have your code in some public repo that they can sync from.
Central repository
A bit less bureaucratic dev.java.net Maven2 repository - allows completely automatic deployment.