Is it possible for maven to not search snapshots in release repositories? - maven

I've discovered today, while investigating a bug regarding my project being no more deployable, that maven tries to load dependencies from all available repositories.
I don't find it wise, specifically regarding our internal artifacts, that are searched on amven central, Sonatype FlexMojos, and other external release repositories (specificall when the last one provides a custom 404 page that maven wrongly interprets as valid content, replacing my valid artifact with an invalid one).
So, is is possible to tell maven which repositories to lookup for SNAPSHOTs artifacts, and which to lookup for RELEASE ones ?

Would it help if you made it explicit to not look for snapshots in your repo?
<repositories>
<repository>
<id>central</id>
<name>Maven Repository Switchboard</name>
<layout>default</layout>
<url>http://repo1.maven.org/maven2</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>

My solution is to set up a repository mirror in the intranet. That way, Maven needs to know a single URL to download everything.
I then use the internal mirror to bundle repositories (local and remote ones). If snapshot repos are first in the search path, the mirror server will almost never publish the names of my internal artifacts (only when I forgot to deploy them).
On top of that, it will reduce the download times for the rest of the team plus it will make sure that everyone can still work even when there are network problems outside of your control.

Related

Why maven is not able to download "SNAPSHOT" artifacts from azure artifacts repository? (Snapshot translation to timestamp is malfunctioning)

Maven is not able to download artifact when referred by version such as 'XXX-SNAPSHOT' but it is able to download every other dependency from it. It even download the SNAPSHOT if & only if I replace 'SNAPSHOT' by the real timestamp, for example, replace 155-SNAPSHOT by 155-20220224.175558-1.
We are hosting SNAPSHOTS and releases both under the same azur artifact feed. Any advice on how to approach/fix this missing snapshot translation to timestamp?
I wasn't able find the detailed documentation on how this snapshot translation mechanism works on client or server side, can anyone please point it to me?
<dependency>
<groupId>com.st.services.clients</groupId>
<artifactId>st-ccs-web-service</artifactId>
<!-- <version>155-SNAPSHOT</version> --><!-- not works -->
<version>155-20220224.175558-1</version>
</dependency>
<repositories>
<repository>
<name>My Hosted Maven Repo Group</name>
<id>maven-feed</id>
<url>https://pkgs.dev.azure.com/my-org/my-project/_packaging/maven-feed/maven/v1
</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</snapshots>
</repository>
</repositories>
Not the outcome you were after, but,
Having also tried this myself, I think Azure DevOps simply does not support this.
There are a few aspects of Azure DevOps's Artifacts feature that doesn't entirely align with Maven/how Maven does things. Unfortunately, this appears to be one of them.
(An example of another is the management of timestamped snapshots of the same version as individual versions, which Sonatype Nexus can do but DevOps Artifacts cannot).

How can I get jenkins/Jfrog to pull from my own artifactory AND another remote one?

I currently have artifactory set up on my jenkins pipeline correctly. I can see that it does indeed fetches artifacts but I noticed there is a few artifacts that arent being pulled. These artifacts dont seem to be in my jfrog server but i do specify in the POM file where they can be found and pulled. Here they are:
<repository>
<id>osgeo</id>
<name>OSGeo Release Repository</name>
<url>https://repo.osgeo.org/repository/release/</url>
<snapshots><enabled>false</enabled></snapshots>
<releases><enabled>true</enabled></releases>
</repository>
<repository>
<id>osgeo-snapshot</id>
<name>OSGeo Snapshot Repository</name>
<url>https://repo.osgeo.org/repository/snapshot/</url>
<snapshots><enabled>true</enabled></snapshots>
<releases><enabled>false</enabled></releases>
</repository>
I guess maven/jenkins only checks my artifactory server and doesnt reach out to these repos at all. Is there a way where I can tell maven to not just look in my artifactory repo and also look in these repos as well? I have this snippet of code in my main pom file so im clueless as to why it doesnt pull from them.
Artifactory does reach out these remote endpoints if they are configured. Check if these "https://repo.osgeo.org/repository/snapshot" and "https://repo.osgeo.org/repository/release" are configured in the remote repository and if not, create the maven remote repositories in Artifactory and point the URL textbox to these remote endpoints. Add these 2 remote repositories in the Maven virtual repository and try to pull from Artifactory.

Why is maven hitting repo.maven.apache.org for local jars?

I have a project built and installed in the local maven repository ~/.m2 named com.example.project. From time to time, not always, when I build another project that depends on com.example.project, maven says in debug messages:
Downloading: https://repo.maven.apache.org/maven2/com/example/project/maven-metadata.xml
Why is maven querying that URL and why does this happen occasionally? First, there is nothing on that URL, second, the jar already exists on local repository, third, I didn't change the version number of the local jar dependency. So let us say I have 1000 local projects, will it query URL1, URL2, ..., URL1000. What is the logic of this query to a non-existing URL?
Why is maven querying that URL and why does this happen occasionally?
occasionally: is specifically daily, because it is the default updatepolicy for the maven builtin Central Repository.
If you take a look at the maven super POM, which all pom files inherited from, you will find the repository is configured as follows
<repositories>
<repository>
<id>central</id>
<name>Central Repository</name>
<url>https://repo.maven.apache.org/maven2</url>
<layout>default</layout>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>
<release> element is not appearing here, so that means the repository will take the default values for it.
enabled (default is true)
updatePolicy (default is daily) --> possible values: "always", "daily" (default), "interval:XXX" (in minutes) or "never" (only if it doesn't exist locally).
hope this helps

Setup AEM Adobe CQ5 6.1 project to build/install offline

I'm new to CQ5 and looking for steps/settings I may need to do to setup an AEM adobe CQ5 6.1 project to build/install offline (not connected to internet).
I've to use our internal network Nexus (which has lot of general dependencies available except AEM related).
I've to use Maven & Java7.
Looking for possible issues/resolutions, steps & any helpful info.
Thanks all for your inputs.
After a detailed investigation, this is now resolved. Just want to share the findings so that it may help others.
The content-package-maven-plugin which was uploaded to our local nexus got corrupted.
Interestingly maven was not throwing any errors when i was trying mvn install command on my AEM project. Rather it was giving NoClassDefFound error for a further dependency of content-package-maven-plugin.
From the output of, mvn dependency:resolve-plugins, it was confirmed that the dependencies are not fully resolved for particular this plugin JAR, I tried to manually download the artifact from nexus & try to open/unjar it.
The artifact pom was corrupted and hence I uploaded the fresh artifact in nexus, and this time all went smooth.
My AEM project is now building fine with local nexus dependencies.
a typical AEM project does have lots of dependencies. There are some dependencies for the AEM platform(including granite, sling, osgi etc). These dependencies are downloaded from the adobe public repositories, unless you have a nexus repository in your company where all these dependencies are available.
If your Organization specific Nexus repository can connect to internet and download dependencies (AEM and non AEM related) atleast for the first time , then you do not need to connect to internet from your local sand box.
Theoretically, your organization specific nexus repo also might not be
connected to the internet and all the JARs can be uploaded to Nexus
manually. But, that would be the last thing I will do in my life !
Your project can download all the dependencies from the Nexus repo(only) in multiple ways.
Configure the repository configuration in your pom.xml file to point
to your internal Nexus repo.
<repositories>
<repository>
<id>internal</id>
<name>Internal Public Repository</name>
<url>URL to the public repository of your internal nexus</url>
<layout>default</layout>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>internal</id>
<name>Internal Public Repository</name>
<url>URL to the public repository of your internal nexus</url>
<layout>default</layout>
</pluginRepository>
</pluginRepositories>
Change your Maven settings (settings.xml) to use your internal Nexus
every time it downloads dependencies (Recommened).
settings.xml can be found in your <user>/.m2 directory or <maven-installation>/conf
<mirrors>
<mirror>
<id>public</id>
<mirrorOf>*</mirrorOf>
<url>URL to the public repository of your internal nexus</url>
</mirror>
</mirrors>

Where should I define maven repositories given that I use mirrorOf * in settings.xml?

I have a nexus repo on my network. In settings.xml on the build server we have
<mirror>
<id>company.com</id>
<name>nexus</name>
<url>http://build.company.com/nexus/content/groups/public/</url>
<mirrorOf>*</mirrorOf>
</mirror>
On this build server we have a number of proxy repositories defined for public repos, and I have some commercially licensed artifacts in a hosted repo.
And a profile - Maven cannot resolve my parent pom (artifact in nexus) without this:
<profiles>
<profile>
<id>repos</id>
<repositories>
<repository>
<id>my-local-repo</id>
<name>bootstrapthingy</name>
<url>http://build.company.com/nexus/content/groups/public/</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
<checksumPolicy>fail</checksumPolicy>
<updatePolicy>always</updatePolicy>
</snapshots>
</repository>
</repositories>
</profile>
</profiles>
<activeProfiles>
<activeProfile>repos</activeProfile>
</activeProfiles>
My question today:
I also have removed all my
<repositories>
tags from the parent pom that all projects (should eventually!) inherit, and everything seems to work.
Is this well and good? I seem to end up a lot thinking about best practice when I work with maven - lately, around where should information be kept?
As my repositories are now defined at Nexus level, there is an element of my build that is no longer source code controlled, and this bothers me.
Yes I would argue you're on the right track!
Maven recommends to think about your infrastructure and plan it! By that it splits project concerns from infrastructure aspects. Project specific configuration goes into the pom.xml while I would vote to put infrastructure configuration into settings.xml
So the company mirror / proxy goes into settings.xml (as infrastructure may change) along with its authentication and environment settings (that are project independant!)
Usually projects do not rely on a per-project repository. If they do they could in almost any case use the nexus server for that (lets say explicit SNAPSHOT dependencies). So the practice to not have repositories in a pom.xml is ok. URL's change and builds should not request artifacts at different locations. It endangers your build reproduce-ability (as does adding all kinds of unstable remote repos into nexus).
I think within a company you need to consider (or simply acknowledge) that builds in projects are not self-maintained. Most open-source projects are since they do not have a common shared infrastructure they may benefit from (or suffer under?). You need to do the best of it but having infrastructure issues solved in settings.xml also means that the project does not need to do that anymore. Has pro's and con's - no doubt about that :)

Resources