we have a settings.xml on a build server that restricts access to outside repositories and forces access to a local repository.
with the cooperation of the policy makers behind this, we are investigating the possibility to selectively (from a project's pom.xml) enable outside repository access.
is this possible? if so, would it be as simple as configuring the repository in the pom.xml?
I'm afraid it isn't possible. You need to specify an alternative settings.xml on the command line.
Related
I see several options:
directly in pom.xml
in company super-pom
in settings.xml (global or user)
in a profile or directly (in settings.xml or pom.xml)
We want our Jenkins to push artifacts to internal repository, and developers to pull missing artifacts from there.
If I put the repository URL in pom.xml, and later the internal repository is moved to a different address, the released versions will all have a broken link.
Super-pom saves some repetition, but in a clean setup you need to somehow know where the repository is to find the parent POM — to tell you where the repository is.
Having the URL in settings allows one to change it without modifying the artifacts, but there are two problems:
build will fail due to unresolved dependencies, if maven settings have no reference to the internal repo
developers have to update their settings.xml files manually
I'm also unsure about the merits of putting repository configuration in profiles. I know it let's you easily switch the repositories on and off, but shouldn't the -o option and snapshot resolution settings be enough for most uses?
What about using a different repository (e.g. with instrumented classes) for integration tests?
Configure a single repository in the users ${HOME}/.m2/settings.xml and configure other needed repositories in your appropriate repository manager either Nexus, Artifactory or Archiva. In Jenkins there is the Config File Provider plugin which exactly handles such situations in a very convinient way.
If you want to have repeatable builds and good control over your organization internally, use a repository manager and use a mirrorOf entry in everyone’s settings.xml to point at that url.
If you are exposing your source and want to make it easy for others to
build, then consider adding a repository entry to your POM, but don’t
pick a URL lightly, think long-term, and use a URL that will always be
under your control.
http://blog.sonatype.com/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
The ivy local repository is in ~/.ivy2, and I'd like to use it as my local maven respoitory. Is there any easy way like setting to do it ?
I suspect what you're trying to do is share ivy's cache, not it's local repository. Files are placed in ivy's repository by calling the publish task. Ivy has a clear storage distinction between these file types:
~/.ivy2/cache
~/.ivy2/local
Maven on the other hand mixes up both file types under the following directory:
~/.m2/repository
It would be a lot simpler to optimize your caching by installing a Maven repository manager like Nexus and configuring Maven and Ivy to use it. Nexus is a very efficient java process and simple to setup on your development machine.
Finally if you are determined to share caches, you could attempt to use the caches directive in the ivy settings file. It has "ivyPattern" and "artifactPattern" directives which suggest one can customize how the cached files are stored. To make this work you'll have to customize ivy. Maven has no flexibility in this area.
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're trying to setup Gradle to publish artifacts to Artifactory. There are two sets of credentials that can be configured, a "deployer" and "resolver". The deployer seems fairly obvious, as the target repository is read-only, a set of credentials are necessary to authenticate for deployment.
However, what is this "resolver" in the context of maven repositories. We are already using Gradle's dependency management, so project dependencies are already getting resolved via the repositories we have configured using Gradle.
So what's the point of this second "resolver" configuration, and why would it need credentials?
Thanks.
If you're using the Gradle Artifactory Plugin, then it allows you to set optional user/pass for a repository that requires authenticated read access (can be set in Artifactory using permission targets).
A maven (or ivy, if configured) repository with these credentials will be added to your project by the plugin behind the scenes.
I think this is needed e.g. if you use your own enterprise repository (like Nexus or Artifactory) and you even need credentials to read that repositories (which may be the case in companies).
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.