When I try to build neo4j from sources and deploy it, the deployment phase fails since there is already a repository defined in the grandparent's pom.xml.
Is it possible to redefine (or add) the DistributionManagement properties so that I'll be able to deploy custom neo4j build to an internal non-local repository?
It is possible since maven-deploy-plugin 2.8
Just be sure to use that version of the plugin (by defining it in neo4j's pom if neo4j doesn't already do that by itself)
Then define altReleaseDeploymentRepositoryand/or altSnapshotDeploymentRepository in your maven settings.xml. (Depending on your personal preference you can also define that inside a profile).
The syntax of the alternative repositories is id::layout::url where id must match the id of a server that is also defined in your settings (giving you the chance to give user/pass for that server). Layout is default
Example:
<altReleaseDeploymentRepository>my.nexus::default::https://my.domain.com/nexus/content/repositories/releases/</altReleaseDeploymentRepository>
Related
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?
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 :)
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/
i am new to maven though worked on ant a lot.After going thru http://maven.apache.org/guides/mini/guide-mirror-settings.html, i am bit confused.
i have two basic questions:-
1)whats the difference between mirror url and pluginRepository url. As my understanding both url defines the url from where repository
needs to be downloaded
2)whats the diefference b/w repository and pluginRepository?
3)what actually profile is? as per my understanding its a goal which we want to execute. For example:- when we do mvn install, install is already
defined profile by maven. Is n't it?
Let me start with a basic difference in Maven.
In general repositories are containers which can store two major types of artifacts.
The first are artifacts that are used as dependencies of other artifacts.
The other type of artifact is plugins. Maven plugins are themselves a special type of artifact. Because of this, plugin repositories may be separated from other repositories
Usually there will not made a difference between pluginRepositories and usual repositories, but technically it's possible.
Now to your first question:
It is possible to declare a repository inside the project which means to put the repository definition into the pom file which is bad practice.
The mirror setting is usually used to mirror all request from the defined repositories into a defined URL (see mirror settings). In practice delegate all request to a particular URL which is usually a URL of a repository manager.
Now we came to your third question.
A profile has nothing to do with a goal and nothing with mvn install. The call mvn install calls the maven build life cyclce which will run all life cycle phase after another. A profile can be best translated with a if-statement. You can activate a profile on command line like this:
mvn -Pdev install
mvn -Prun-its verify
which is a kind of condition in you pom.
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).