I have created a repository in Nexus. As I am the owner of this repository, it is of type : Hosted.
I was going through the book of Mastering Apache Maven 3.0 and it says that, it is not possible to perform a health check on the repositories which are
1.The Repository Type is Proxy.
2.The Repository Policy is not Snapshot.
3.The Repository is In Service.
I have the last 2 conditions satisfied in my repository. But, the type of my repository is Hosted as I have the repository in my local machine.
Is there anything which I can do for a health check of custom repositories in Nexus?
I have one more question. If I want to mark an artifact in my hosted repository, how should I do that? Or should I just delete the vulnerable artifact from the repository?
Thanks in Advance!
How could nexus perform a health check on your custom libs?
From the nexus docs
HDS exposes data about the components in the Central Repository and
other public repositories, including license information, security
vulnerability data, and other statistics like relative usage
popularity and age
HDS is
Hosted Data Services (HDS) run by Sonatype
None of that is available for your hosted custom libraries. You can't really expect sonatype to maintain a database about them, because it doesn't know about them. If you want this, move your libs to an open-source model with an appropriate licence and upload them to maven central.
Related
We have Sonatype nexus repository where we publish artifacts. I want to mirror that repository in a different server located in a different office location. Is there a opensource tool to mirror an entire repository? Note: I am not talking about proxy repositories or caches. I want active mirroring with the two repositories more or less in sync.
You need to setup one as a main repository (basically the one you have) and then the second one in proxy configuration, see this detailed instruction:
https://help.sonatype.com/learning/repository-manager-3/first-time-installation-and-setup/lesson-2%3A-proxy-and-hosted-maven-repositories#app
I need to push our project API's (bundled jar) to Maven Central Repository. As Part of that,i have gone through this link . However, am quite confused whether our project is eligible to publish in maven central repo,
Our API is not open source. it need to distribute only to client who purchase from us. is Maven provides any restrictions to download jar only for specific user who has some key etc?
POM.xml is requesting for licensing information. ours is not open source, if we allowed to publish, what should be licensing content in pom.xml?
Why we have to give our repo information in pom.xml? we are using bitbucket and hence providing the repo url is not accessible for others. can we have dummy repo or it is mandatory?
Please help me out guys.
Everything you publish to maven central will be available to everyone in the world.
For your use case, you can consider hosting your own maven repository.
Check sonatype nexus, artifactory, archiva...
With your own repo, you can configure a password in your server. Then your clients will need to configure your server in their pom.xml or settings.xml to download your artifacts.
I have a central Maven repository which is shared by more than one Projects within the Company LAN. Now, I need to have an artifact which is licensed for a single Project, to be placed in the shared repository.
Is it possible set authorized access to that artifact, the credential can ideally be in the pom file of the desired project.
Any better solution is more than welcome.
Maven doesn't handle access rights in repositories, since it's just a client fetching data from a server. If you're using a repository manager, read its documentation. If you're just hosting files behind an Apache HTTPD server, then configure HTTPD.
Alternatively, you could move that file in a separate repository, and configure just one project's POM to use it. This doesn't fix the fact that the repository will continue to be public, so other projects/teams could get to it if they really want to.
We have recently decided to use Maven as build system. I'm responsible to migrate all the projects from Ant to Maven. We also decided to use Apache Archiva to configure an internal repository in the company.
I see that Archiva create two repositories by default (internal and snapshots). I also see that it configures the internal repository to proxy the central and java.net repositories.
Are there some best practices regarding Archiva configuration?
In the Archiva documentation, there is a possibility to configure Maven to use only the internal repository and then access the remote repository through the internal repository. What do you think about this option?
Thanks for your help
A Maven repository manager is essential to support Enterprise Maven development. The Maven installer is merely a bootstrap, running Maven for the first time downloads everything it needs from the Maven Central repository in order to compile your project.
The benefits of using a Maven repository aree documented elsewhere but I'll summarize:
Efficiency. Repository acts as a cache for Maven Central artifacts
Resilience. Repository protects against remote repository failures or lack of internet connection
Repeatability. Storing common artifacts centrally, avoids shared build failures caused by developers maintaining their own local repositories.
Audit. If all 3rd party libraries used by development come from a single entry point in the build process one can assess how often they're used (based on download log files) and what kinds of licensing conditions apply.
To that end I'd encourage you to use the following Archiva features:
Locking down to only use Archiva. Configure Maven clients download everything from Archiva.
Virtual repositories for each team. Configure all the remote repositories used by teams centrally in Archiva instead of leaving the details to the teams themselves.
PS
I use Nexus for my Maven repository management, but the same concepts apply.
According to the Maven documentation:
You can force Maven to use a single repository by having it mirror all repository requests. The repository must contain all of the desired artifacts, or be able to proxy the requests to other repositories. This setting is most useful when using an internal company repository with the Maven Repository Manager to proxy external requests.
To achieve this, set mirrorOf to *.
This StackOverflow question also suggests that setting mirrorOf is sufficient to block an external repository, so why does the Sonatype documentation suggest overloading central with an unreachable URL?
The bogus URL is really irrelevant - you can set it to the original one if you need to, or the URL of your repository manager - as long as the mirrorOf is applicable, it won't be used.
The reason these examples redefine central is to set policies on artifact requests to the default repositories. By default, Maven does not enable snapshot requests to central, and uses default update and checksum policies. Redeclaring central allows these to be overridden - in this case, to enable snapshot artifacts and plugins, and the mirror then redirects all of these to the repository manager. This avoids the need to declare the repositories in your POM (as long as all users have their settings correct).
I wrote that so I can tell you what I was thinking ;-)
The central repository definition needs to be updated to enable snapshot retrieval for at least one repo, otherwise Maven won't even ask the repository manager (pointed to by the mirrorOf) for any snapshots.
While not required, I like to change the definition of the url to be an invalid one also so if there is a misconfiguration somewhere else in the system, it becomes immediately obvious what is happening. Otherwise Maven may still reach out to Central and mask the problems. It's essentially a fail-fast setup.
There's more information on this topic in an old blog I wrote
maven needs project dependencies to be available locally for it to run. It does not care about how it is made available - whether manually installed (using mvn install:install-file), through a mirror or by from central repository. It will fail to run if it is unable to find dependencies.
The sonatype documentation that you are referring to is on using nexus to mirror/proxy repositories. The url specified should be a valid nexus url and cannot be unreachable.
The same is suggested in the SO question as well.