Configure JFrog artifact repository for Maven project - maven

I'm working on some generic template which I need to use Jfrog artifactory for the repository. I have gone through their documents they are specified to use setting.xml (need to add report info) for maven, but I don't want to force down the users to change there settings.xml who are going to use my template.
So i want it should be in my parent pom to access this and use further.

While you can define repositories in (parent) POMs, the settings.xml often overrides these settings.
If the settings.xml has a <mirror>*</mirror> entry, everything from the (parent) POM will be useless.
So the standard way to go is to change the settings.xml.

Related

Maven plugin that allows to add entries to settings.xml?

I have private Maven repository (Nexus2) that requires a fixed username and password even for reading it.
I am now trying to find an easy way to make this repository accessible by all developers. My first attempt was to define the repository in the parent project's pom.xml (which is only accessible for developers from the SCM) - which does not work as there is no way to specify username and password.
Therefore I have to edit the user specific settings.xml.
Is there a Maven plugin available that allows me to add specific entries to the settings.xml upon execution?

Common repository maven best practices

If my company has an artifactory repository set up, what is the best way to ensure all projects can access it?
Currently all repository information is in a master pom project (it also contains stuff other than repo info). Then any other projects have that master pom as the parent to inherit from. Because the projects are independent, we have to use the relativePath property and ensure the master pom is in the correct relative directory.
Is there a better way?
In the settings.xml you have to configure the access to the company repository manager and in your corporate pom you have to setup up the distributionManagement.

Gradle equivelant of maven repository management paramenter

When building with Gradle I would like to reuse the maven repository I created in the past for dependency management, it is basically working, but I cannot find out answers for below questions from Gralde official document:
Does Gradle reuse my settings.xml from default location (my home folder) during maven dependency resolution?
How could I specify a repository in Gradle instead of using the default one? I can do it in maven command with -Drepository parameter easily.
How to control the update policy? I mean always update snapshot dependency and update release dependency per week something like this, or is my setting in settings.xml takes effect to Gradle as well?
Thanks in advance.
B.R.
My answers below are based on the following chapters from gradle user guide:
8. DEPENDENCY MANAGEMENT BASICS
51. DEPENDENCY MANAGEMENT
Now, to the specific answers:
According to DEPENDENCY MANAGEMENT BASICS (section 51.6.4. Local Maven repository), I guess the answer to this question would be yes:
Gradle uses the same logic as Maven to identify the location of your
local Maven cache. If a local repository location is defined in a
settings.xml, this location will be used. The settings.xml in
USER_HOME/.m2 takes precedence over the settings.xml in M2_HOME/conf.
If no settings.xml is available, Gradle uses the default location
USER_HOME/.m2/repository.
This applies to local repository defined as:
repositories {
mavenLocal()
}
Sections 8.5. Repositories and 51.6. Repositories in gradle user guide describes a couple of ways to define the repositories you'd like to use. these includes using mavenCentral, specifying a remote custom Maven repository, e.g.: maven { url "http://repo.mycompany.com/maven2" }, etc. If you'd like to pass the repository via command line then you can use gradle system property for that.
I believe that section 51.9. THE DEPENDENCY CACHE contains the information you're looking for. In short, the default cache is for 24 hours. However, it can be overridden configuring the ResolutionStrategy, e.g.: resolutionStrategy.cacheDynamicVersionsFor 10, 'minutes'.
Regarding using the settings in settings.xml then I could not find a clear answer for that but you're welcome to give it a try :)

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/

Maven repository inheritance and override

I have a Maven project that was built a few years back, and now I need to make some updates. One of the dependencies to my project has a Maven repository listed in its POM that no longer exists. I get build failures now.
I would have thought the repository listings in my POM or Settings.xml would trump any repositories listed in a dependency's POM; or Maven would try my repositories after failing to connect to the extinct repository. Instead, it just bombs out with a build failure.
Additionally, I already have the required dependencies in my local repository. I would have additionally thought that Maven would just use that.
Is there a way to override the inherited repository listings, or tell Maven to carry-on in the case of a repo problem?
If the artifact that you depend on is a snapshot version then maven will check for a new snapshot every time you build, thats why it is a good practice to lock down your dependencies to a released version.
You can "override" the repository declarations by defining a <mirror> in the settings.xml.
See http://maven.apache.org/settings.html#Mirrors
I usually set up a locally hosted repository manager (preferably nexus) and then define mirrorOf(*) = local-repo-manager/url.
Nexus allows multiple repo's to be grouped with a predefined search order.
Nexus repo's can be locally hosted or caching/proxies to public repo's.
I usually have a locally hosted 3rd party repo at the front of the group, where I can store artifacts that are not published on public repo's.

Resources