How to use the ivy local repository as a maven respository - maven

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.

Related

Is there a way in Gradle to define what patterns of artifacts should, (or should not), be resolved via a repository?

Is there a way in Gradle to explicitly define where certain artifacts should be coming from?
We have a legacy project which is being on-boarded to use a proper artifact repository manager, instead of a network share. However, we have multiple repositories from which artifacts are being downloaded. We'd like to be able to fine-grain where certain artifacts should be coming from, until we can fully on-board to the artifact repository manager in question.
Is something like this possible?
Yes that is possible as of Gradle 5.1
https://docs.gradle.org/5.1/release-notes.html#repository-to-dependency-matching
Repository to dependency matching
It is now possible to match repositories to dependencies, so that Gradle doesn't search for a dependency in a repository if it's never going to be found there.
See the docs for more details: https://docs.gradle.org/5.6.2/userguide/declaring_repositories.html#sec::matching_repositories_to_dependencies

Jars in Maven Central needs to go into Nexus OSS?

I need to set up my own maven repository, since some open sourced libraries are not in Maven Central. I want to use Nexus OSS, and then I can upload the libraries I need to Nexus OSS.
My question is, do I also need to upload those libraries that are originally in Maven Central and I can directly use in POM to Nexus OSS?
Nexus is a proxy for global repositories. You can define in Nexus configuration what repositories are you going to use. You do not need to upload libraries that are accessible from configured global repositories.
You can also host your own repository for your local libraries. Everything is configurable.
When you configure your Nexus you need to just connect to it trough maven config and all actions are done behind the scene. Don't worry about it.
All libraries that are needed to compile your project, firstly are downloaded to your Nexus and then from Nexus to your local repo.
For example this is the easiest way to configure Nexus with your maven:
Nexus - maven - Configuration
Not at all: In your local $userprofile/.m2/settings.xml file (as well as in every pom.xml, altough is not a good practice) you can define as many repositories as you want. And so, you will be able to reference artifacts published to different repositories.

Where to actually put internal repository URL?

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/

Are there any artifactory repository naming/configuration conventions?

I am recently working on setting up Artifactory on my virtual server. Basically everything works fine but I did not find any conventions how to setup the repositories used by my projects.
Is there any recommendation/guide to either create an own repository for each (multi module) project (e.g. myProject-release-local) or alternatively to put them all to the same repository (e.g. libs-release-local)?
Thanks in advance
It depends on how much isolation you need/want. If you want to tightly control the dependencies of each build, separate repositories might work better. In any case, each build should only have to list a single repository in its build script. This can be achieved by aggregating physical repositories into virtual repositories.

Reusing Artifactory's maven repo

I'm trying to figure out if its possible to reuse Artifactory's maven repo on the local machine where the Artifactory server is running. The following details what I am trying to do.
I have a server where Artifactory runs and I'm planning on setting up Jenkins on the same server. If possible, I would like to have only one maven repository on the server. Since Artifactory already runs there, I would expect it is maintaining some kind of a maven repository (I looked around for it but couldn't find it).
Currently, when Jenkins uses Maven to build a maven project, it downloads the dependent jars into a local maven repo (a .m2 folder) on the server. Instead of this, would it be possible to point the settings.xml that maven is using to some local folder under Artifactory where artifactory stores all the jars? Basically, I would like maven to think that all the jars are already available in a local repo (which artifactory is maintaining) and so it wouldnt have to download all the jars from artifactory.
If maven and artifactory can share the same repo folder, this would be possible. But if Artifactory uses its own strucuture to maintain the maven repository (something other than the structure maven follows with its .m2 folder) this would not be possible.
I should state that I have very minimal knowledge of Artifactory, other than the fact that it is a maven repository manager.
Answering my own question here, as more research suggests that this is not possible. I found another question here on SO that states:
Artifactory uses Java Content Repository (JCR) standard to store artifacts. It is an abstraction above various storage implementations, which include filesystem, relational databases, etc. In any case, JCR manages the store by checksums (to reduce size and bandwith), so the repository is not directly browesable in the filesystem. The default implementation is storing the binaries on the filesystem (inside $ARTIFACTORY_HOME/data/filestore and the metadata in Derby DB.
How Artifactory manages repos
A blog post by the Nexus guys also suggests that this is not possible.
Contrasting Nexus and Artifactory -> Contrast #2

Resources