It seems that question can be related to How to automatically attach source code for dependency in Intellij? but it`s not in full manner.
In debug mode I'm getting into decompiled file and idea ask me to download or set the path to sources.
For resolving I'm using some nexus repository which aggregates different vendors public jars (proxy repositories,reuploaded jars and etc). Unfortunately it contains jars but very often it doesn't contain sources or javadocs.
But at the same time vendors' repositories contain sources. After clicking "download" button - I can see that idea try to find sources only in "oss.sonatype.org" repository.
So is any ability to set the list of repositories where Idea can search sources?
IntelliJ will respect your normal Maven configuration. You can define repositories in the actual pom.xml or in your maven user setting under ~/.m2/settings.xml. See https://maven.apache.org/guides/mini/guide-multiple-repositories.html
Check settings of IntelliJ IDEA "Settings-->Maven-->Repositories
There are two sections:
Index Maven Repositories
Artifactory or Nexus Service URLs
Related
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
My team is migrating our code to an Azure environment and Microsoft's own article on the subject describes how to use Maven in an Azure environment:
https://learn.microsoft.com/en-us/azure/devops/java/labs/mavenpmvsts/?view=vsts
One of Maven's best practices is to avoid defining repository elements within the pom file and use a repository manager configured within the settings.xml instead.
The Microsoft article instructs otherwise: they say to add the repository url right in the pom file.
I would have been okay with it if the repository element was defined only in the distributionManagement section, but that is not the case. The article defines the url in a repositories element outside of the distribution context.
My understanding of the repository element of the pom.xml file is that it overrides the source of artifacts used for fetching dependencies. The problem I see defining this in the pom file is that it could have adverse effects depending how the library is being reused.
Use case example:
1) Shared library is created with repository url defined in pom
2) Shared library is deployed. POM file containing url and JAR file are published.
3) Artifact repository is moved, renamed or copied, url is changed.
4) Later on, a new application using that shared library is created, but uses the new repository url. The URL in the application pom is now different from the one in the shared library's previously published pom.
Because Maven uses a dependency graph and inheritance, what I would expect to happen is that when we build the new application:
1) maven will read the application pom file and begin exploring the dependency graph by downloading pom files for each of the application's dependencies from the URL found in the application's pom. In this case, the only download is the shared library's pom.
2) maven will explore transitive dependencies and read the shared library's pom. Reading the shared library's pom, the repository section will take precedence over the application's pom in the context of the shared library's dependencies. The shared library's dependencies poms would be downloaded from the old URL.
3) maven will continue like that and download all the pom files until the dependency tree has been built.
4) depending on project configuration, maven will go through the graph it built to download the jars and etc using the same rules.
In this use case, maven would download artifacts from both the old source and the new source. If the old source no longer exists or isn't accessible in this build context, the project cannot be built. This is why it's best to avoid setting repository urls in a pom file.
Or so I thought.
I wrote a scripted demo with local repositories to show my team exactly what would happen and to my surprise, even though Maven does download the shared library's pom file containing a different repository url, the repository tag does not seem to be overriding the one from the application being built. Logs show all artifacts being downloaded from the source specified in the "top" application pom.
So my question to Stack Overflow is two fold:
1) Why am I wrong? Did I misunderstand Maven's inheritance, dependency graph building and behavior?
2) Shouldn't Maven download the shared library's dependencies from the url specified in the repository tag, if specified? I'm sure there are some cases where the artifacts must come from a private repo. (ex: org.geotools)
3) Does anyone have experience setting up Maven on Azure? Did you follow Microsoft's guide or found a way to move repository urls to your settings.xml in an Azure environment?
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/
How do i set Maven to retrieve external dependencies first from my own remote repository (using Archiva), and if its not found, Archiva will download from external sources, and at the same time saves the downloaded dependency?
You essentially have to set up your .m2/settings.xml file, nothing fancy.
Here is a pretty comprehensive guide. While based on Artifactory, the aspects of POM configuring are obviously general. That should give you all the information you need.