Issue with imported scope poms (spring bom io dependency issue) - maven

My company policy restricts us from downloading thirdparty artifacts from public repositories (maven_central, spring-io etc)
We use Nexus as a repository manager which hosts all the artifacts that are approved by our company policy.
We are trying to use io-platform bom pom in our project to manage all spring dependencies.
We have uploaded all boms and its dependencies in our company repository. Verified also, everything is there in the company repos.
In my settings.xml all repositories (hosted by company) are properly mentioned.
But somehow for spring-framework-bom project maven searches only in central even if it is disabled in settings.xml.It should ideally search in our company repositories first.
We are getting the below exception.
Exception trace:
org.apache.maven.reactor.MavenExecutionException: POM 'org.springframework:spring-framework-bom' not found in repository: Unable to download the artifact from any repository org.springframework:spring-framework-bom:pom:4.0.6.RELEASE
from the specified remote repositories:
central (http://repo1.maven.org/maven2)

This problem comes when you have pom/artifact defined with import scope in your other pom.
Imported dependencies basically looses repository information and they try to search dependencies in maven central .
Trick is to mirror maven central repository with your companies repository. So in case of imported dependency it will search in companies repository rather than default maven central.
Hope this helps.

It's a bug. This is the proposed solution:
IMO, using the stated workaround (adding the custom repository to the POM that has the scope == import dependency) is probably the safest way to go
It works at least in Maven 3.3.9. Probably already earlier.

Related

Is it possible to make a maven-repository with a static-website?

Stupide idea but ... is it possible to create a maven repository from a static website?
if I mannualy put pom and jar file on a website with a path similar to the one on any maven repository, then I reference the website as a maven repository from which I try to import dependency, will it work ?
I need it in order to store my snapshot version without publishing them. I don't care of security but I have 0 budget

Publishing licensed artifact to Maven Central Repository

I need to push our project API's (bundled jar) to Maven Central Repository. As Part of that,i have gone through this link . However, am quite confused whether our project is eligible to publish in maven central repo,
Our API is not open source. it need to distribute only to client who purchase from us. is Maven provides any restrictions to download jar only for specific user who has some key etc?
POM.xml is requesting for licensing information. ours is not open source, if we allowed to publish, what should be licensing content in pom.xml?
Why we have to give our repo information in pom.xml? we are using bitbucket and hence providing the repo url is not accessible for others. can we have dummy repo or it is mandatory?
Please help me out guys.
Everything you publish to maven central will be available to everyone in the world.
For your use case, you can consider hosting your own maven repository.
Check sonatype nexus, artifactory, archiva...
With your own repo, you can configure a password in your server. Then your clients will need to configure your server in their pom.xml or settings.xml to download your artifacts.

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.

Migrating maven artifact repositories - pom <url> value points to old repo

Question:
When importing maven artifact repositories (either from other instances of Artifactory, or nexus, for example), many artifacts (and most parent) poms contain url tags which reference the old repository. These url tags are within the distributionManagement and repositories tags.
Do we need to go through a time consuming process of updating these URLs for every single artifact (and parent pom, where applicable)?
Further Information:
We are in the process of migrating some artifact repositories to a whole new environment. We have an old Artifactory instance and a Nexus instance from a separate project that we need to migrate into a single Artifactory instance in a new environment. We currently don't have access to run maven builds from the Nexus repo - we have only been given access to their filesystem to pull artifacts across.
The new Artifactory version is newer than the old one, so we used the following process:
1. system export excluding binaries
2. copy filestore directory across to new Artifactory server
3. imported the system export
For Nexus, we are rsyncing the filesystem for each repository across to the new Artifactory server, and using the 'Import Repository from Path' feature.
These imports have all finished successfully, and we can see all of the required artifacts in the new Artifactory instance.
We have successfully executed a maven build that pulled down dependencies imported from the old Artifactory instance, and this same build successfully published it's artifacts back to the new Artifactory instance as well.
Given our successful tests so far, we're not sure if we really need to update them, or if they will become a problem later for some reason (such as when we decommission the old Artifactory instance)
You're lucky to use Artifactory in your new environment :)
Artifactory will automatically remove any <repositories> references from your pom files, leaving the resolution rules to your settings.xml. All you need to do is generate a new settings.xml file from your new Artifactory and all the resolution will occur from it.
In order for it to work, please declare the old Artifactory and Nexus as remote repositories for the new Artifactory instance (don't use export/import). Once new Artifactory fetches artifact from old Artifactory or Nexus it removes the repositories declaration and stores the new, clean pom in the cache.
After awhile when you sure everything is cached, you can decommission the old servers and declare those repositories as offline (optionally moving the artifacts to local repository).
Neither the repositories nor the distribitionManagement have an impact on your usage of the components and as such nothing needs to be done on the import.
The distributionManagement details where components are released to. Since the component are already released and in your repo server the content does not matter.
Having repositories as an element in your pom files is a very bad practice and should be avoided. However if you are using a repo manager and the appropriate settings using the mirrorOf setup in settings.xml none of the repositories will be taken into account, but instead your repo manager will be contacted as defined in your settings.xml.
As you can see you can just migrate the components and leave them alone. Modifying the poms of already released components is probably a bad practice, since it means that some clients will have one pom, while others will have a different one for the SAME artifact. This violates the idea of a non-changing release artifact and can cause problems.
And in terms of migration you can easily just migrate the repositories in Nexus and turn off the old servers (at least you could migrating to Nexus). That way you don't have to run a number of them in parallel and can quickly decommission, while at the same time being sure you have all your components in your new repo manager.

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