I took a new laptop and setting my environment.
the code that builds fine on a different machine is failing with the following error:
Failed to collect dependencies at javax.enterprise:cdi-api:jar:2.0:
Failed to read artifact descriptor for
javax.enterprise:cdi-api:jar:2.0: Could not transfer artifact
javax.enterprise:cdi-api:pom:2.0 from/to
maven2-repository.dev.java.net (http://download.java.net/maven/2/):
download.java.net: Unknown host download.java.net -> [Help 1]
this is happening intermittently. What is wrong ? any solution please ?
Maven repository is resolving to 404 (for me too currently). It is oracle's problem. I suggest you can use multiple repositories including central nexus to avoid having single point of failure.
Ideally your organization should have one proxy repository which acts as your org level cache for public artifacts and could also act as internal repository for private artifacts.
Add these to your pom.xml and retry
<repositories>
<repository>
<id>central</id>
<url>https://repo.maven.apache.org/maven2/</url>
</repository>
</repositories>
This error happened to me when I was behind a corporate firewall.
You could try setting up a proxy server in maven settings in .m2 folder.
Also see If you can download the file directly from the maven repository website at that moment. Mostly you cannot download due to some network issue you are facing.
Maven settings will not change intermittently.
Related
We are using Artifactory 6.17.0 on a Linux Server.
We migrated it to a new server by simply tar'ing the installation directory & un-tar'ing it at exactly the same path in the new machine. This directory contains the entire installation.
Retrieval of local & bincentre objects via Artifactory is working ok using maven & pom.xml in a Java project under eclipse.
Deployments are being rejected as follows:
2022-02-06 14:48:49,779 [http-nio-8081-exec-1] [WARN ] (o.a.r.ArtifactoryResponseBase:125) -
Sending HTTP error code 409:
The repository 'libs-release-local' rejected the resolution of an artifact
'libs-release-local:my/server/0.0.1-SNAPSHOT/securpharm.server-0.0.1-20220206.134849-1.jar'
due to conflict in the snapshot release handling policy.
I have updated the <distributionManagement> in my pom.xml to the suggested values fromt the Artifactory Web Admin:
<distributionManagement>
<repository>
<id>central</id>
<name>servername-releases</name>
<url>http://servername.domain.name.com:8081/artifactory/libs-release</url>
</repository>
</distributionManagement>
Anyone have an idea what the problem might be?
In addtion to the above comment, If you would like to publish both snapshot and release version under the repository "libs-release-local" repository you can select the option "Handle Releases" in the libs-release-local repository configuration page and publish the version. As shown in the screenshot here.
Please note, it is always recommended to have separate repositories for handling release and snapshot version.
Note: Before you mark this as duplicate please check all information as after 4 hours of search I couldn't find any close cases. All results were about Android Library or Gradle which is not correct on this case.
Links:
Build Log: https://jitpack.io/xyz/agmdev/AGMCore/3.3.1/build.log
Github Source: https://github.com/Ashenguard/AGMCore
Error:
Exit code: 0
Timed out after 20 min
ERROR: No build artifacts found
Project: Maven - Spigot
Version: 3.3.1
Today after finishing the coding, compiling, testing (All of them were successful on my PC) I decided it's time to upload it on Github and create the 3.3.1 release on jitpack.io so I or any other developer can use it in further projects as dependency.
Everything was ok until I started the new project depending on the new code I just uploaded.
But I faced the dependency not found on my IDE (Intelij) and I thought it is a connection issue or something similar, But after troubleshooting, I got to the Build being failure on jitpack.io.
Before you ask, I did test mvn install and it worked fine without any issue on my PC, but for some reason that I'm not aware of, jitpack fails...
What confused me more only thing that has been changed on pom.xml since the last successful build, is the version number
Possible issues that were not the issue in this case. (I'll update the list)
Packaging not being jar which was, Same as previous versions.
useIncrementalCompilation was not the issue as well.
This error can happen in multiple scenarios.
Scenario 1:
If the build fails
If there are no pom.xml or .pom files in build directory
If artifacts are not copied to $HOME/.m2/...
Scenario 2:
You can fix it by looking at https://github.com/jitpack/maven-modular
Scenario 3:
Try this jitpack example
Note: You can only solve it by yourself making sure you have double check your poms.
--- Updated --
Workaround:
Try to add JitPack repository and dependency in your pom.xml file:
JitPack repository:
<repositories>
<repository>
<id>jitpack.io</id>
<url>https://jitpack.io</url>
</repository>
</repositories>
JitPack dependency:
<dependency>
<groupId>com.github.YourProjectName</groupId>
<artifactId>ID</artifactId>
<version>Tag</version>
</dependency>
Maybe it can fix the issue as you said it only occurs on JitPack.
After months of head-scratching, I found out the issue.
The issue was that Jitpack was not able to find one of the plugins I have used in the project, After adding the maven as a plugin repository the issue is gone and Jitpack is doing its job.
<pluginRepositories>
<pluginRepository>
<id>maven-snapshots</id>
<url>https://repository.apache.org/content/repositories/snapshots/</url>
</pluginRepository>
<pluginRepository>
<id>maven-shade-plugin</id>
<url>https://mvnrepository.com/artifact/org.apache.maven.plugins/maven-shade-plugin</url>
</pluginRepository>
</pluginRepositories>
Im' getting an error when deploying an artifact in my own repository in a Nexus server: "Failed to deploy artifacts: Could not transfer artifact" "Failed to transfer file http:///my_artifact. Return code is: 400"
I have Nexus running with one custom repository my_repo with the next maven local configuration:
settings.xml
<server>
<id>my_repo</id>
<username>user</username>
<password>pass</password>
</server>
...
<mirror>
<id>my_repo</id>
<name>Repo Mirror</name>
<url><my_url_to_my_repo></url>
<mirrorOf>*</mirrorOf>
</mirror>
user has permissions to create/read/write into my_repo -
pom.xml
<distributionManagement>
<repository>
<id>my_repo</id>
<name>my_repo</name>
<url><my_url_to_my_repo></url>
<layout>default</layout>
</repository>
<snapshotRepository>
<id>snapshots</id>
<name>Snapshots</name>
<url><my_url_to_my_snapshot_repo></url>
</snapshotRepository>
</distributionManagement>
and then I execute
mvn deploy
and get the error. Any idea?
A couple things I can think of:
user credentials are wrong
url to server is wrong
user does not have access to the deployment repository
user does not have access to the specific repository target
artifact is already deployed with that version if it is a release (not -SNAPSHOT version)
the repository is not suitable for deployment of the respective artifact (e.g. release repo for snapshot version, proxy repo or group instead of a hosted repository)
Check those and if you still run into trouble provide more details here.
Just to create a separate answer. The answer is actually found in a comment for the accepted answer.
Try changing the version of your artefact to end with -SNAPSHOT.
400 Bad Request will be returned if you attempt to:
Deploy a snapshot artifact (or version) ending in -SNAPSHOT to a release repository
Deploy a release artifact (version not ending in -SNAPSHOT) to a snapshot repository
Deploy the same version of a release artifact more than once to a release repository
Cause of problem for me was -source.jars was getting uploaded twice (with maven-source-plugin) as mentioned as one of the cause in accepted answer. Redirecting to answer that I referred:
Maven release plugin fails : source artifacts getting deployed twice
In the rare event that you need to redeploy the SAME STABLE artifact to Nexus, it will fail by default. If you then delete the artifact from Nexus (via the web interface) for the purpose of deploying it again, the deploy will still fail, since just removing the e.g. jar or pom does not clear other files still laying around in the directory. You need to log onto the box and delete the directory in its entirety.
I had this exact problem today and the problem was that the version I was trying to release:perform was already in the Nexus repo.
In my case this was likely due to a network disconnect during an earlier invocation of release:perform. Even though I lost my connection, it appears the release succeeded.
I had the same problem today with the addition "Return code is: 400, ReasonPhrase: Bad Request." which turned out to be the "artifact is already deployed with that version if it is a release" problem from answer above enter link description here
One solution not mentioned yet is to configure Nexus to allow redeployment into a Release repository. Maybe not a best practice, because this is set for a reason, you nevertheless could go to "Access Settings" in your Nexus repositories´ "Configuration"-Tab and set the "Deployment Policy" to "Allow Redeploy".
in the parent pom application==> Version put the tag as follows: x.x.x-SNAPSHOT
example :0.0.1-SNAPSHOT
"-SNAPSHOT" : is very important
Ensure that not exists already (artifact and version) in nexus (as release). In that case return Bad Request.
For 400 error, check the repository "Deployment policy" usually its "Disable redeploy". Most of the time your library version is already there that is why you received a message "Could not PUT put 'https://yoururl/some.jar'. Received status code 400 from server: Repository does not allow updating assets: "your repository name"
So, you have a few options to resolve this.
1- allow redeploy
2- delete the version from your repository which you are trying to upload
3- change the version number
If any of the above answers worked out, You can create new artifact directly from the admin side of (NEXUS Screen shot attached below).
Login to nexus UI http://YOUR_URL:8081/nexus( username: admin
default password: admin123 )
Click repositories on the left side then click the repo, For eg: click release.
Choose artifact Upload (last tab).
Choose GAV definition as GAV Param- Then enter your groupid , artifact id and version .
Choose Jar file.
Click upload artifact.
Thats it !
Now you will be able to add the corrsponding in your project.(screenshot below)
This can also happen if you have a naming policy around version, prohibiting the version# you are trying to deploy. In my case I was trying to upload a version (to release repo) 2.0.1 but later found out that our nexus configuration doesn't allow anything other than whole number for releases.
I tried later with version 2 and deployed it successfully.
The error message definitely dosen't help:
Return code is: 400, ReasonPhrase: Repository does not allow updating assets: maven-releases-xxx. -> [Help 1]
A better message could have been version 2.0.1 violates naming policy
I was getting the same 400 response status, and the issue was resolved by adding -Dresume=false.
mvn -B release:prepare release:perform -Dresume=false
In my case, the release:prepare target was being skipped and the following message was logged in the output.
[INFO] Release preparation already completed. You can now continue with release:perform, or start again using the -Dresume=false flag
I suspect that I may have made changes in the pom.xml that required forcing the release:prepare to run again before running release:perform.
Server id should match with the repository id of maven settings.xml
What worked for me was disabling the ReleaseProfile that comes with the release plugin and skipping the deployment in the deploy plugin
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<configuration>
<tagNameFormat>v#{project.version}</tagNameFormat
<autoVersionSubmodules>true</autoVersionSubmodules>
<releaseProfiles>releases</releaseProfiles>
<useReleaseProfile>false</useReleaseProfile>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
Use mvn help:effective-pom
Watch our for your CI doing a deploy after your release:prepare step. For us it was recent introduction of the official Bitbucket Server Integration plugin in Jenkins that was instantly firing on the push from release:prepare.
The fix was to add a step in the plugin for "Polling ignores commits with certain messages" with: ^(?s)\[maven-release-plugin\].* (from https://stackoverflow.com/a/32371336/1399659)
I'm trying to use jackson at a json project. And Maven is ignoring my local repository (where I have the library already set, from a previous project) and downloading from codehaus repo.
The catch is that my workplace has blocked access to external repos, so I must use local repository for this. How do I force Maven to look first at local and use the library there?
Thanks in advance
Please set the Local Repository Path in eclipse that maps to your local repo path..
Go to Windows->Preferences->Maven->User Settings and change the settings.xml and your local repository path..
If these both are correctly located then it should check to the local repo first
Having to move my development environment offsite in response to COVID-19, my environment had not been established to directly connect to various public repositories since we were mirroring those repos in our server at the office. However, my Maven was still contacting public repositories for our in-house releases. This was odd, because I already had our in-house releases in my local repo.
The solution was to update the Maven configuration, in my settings.xml. Define profiles, a profile for the office and a profile for offsite. In the offsite profile, in addition to the public repos we were already mirroring at the office, I also defined a repository that matched the name, id, and URL of our server at the office where we stored our in-house releases - identically. This allowed Maven to see that the library it was looking for did in-fact come from that repository and didn't need to go looking for it because it was already in the local repo. It also didn't matter that Maven wasn't going to be able to connect to the office server, it just needed to be defined.
Before:
Downloading from central: https://repo.maven.apache.org/maven2/com/mycompany/test-core/1.1.0/test-core-1.1.0.pom
Downloading from jboss-releases: https://repository.jboss.org/nexus/content/repositories/releases/com/mycompany/test-core/1.1.0/test-core-1.1.0.jar
Downloading from repository-apache-org: https://repository.apache.org/content/groups/public/com/mycompany/test-core/1.1.0/test-core-1.1.0.pom
[WARNING] The POM for com.mycompany:test-core:jar:1.1.0 is missing, no dependency information available
This was a library we had produced and released ourselves, definitely not at Maven Central. Maven was just hunting around for it - lost with no direction.
I defined a new repo in the offsite profile, a repo that my environment definitely would not be able to connect to due to existing company firewall rules:
<repository>
<id>leroy-releases</id>
<name>Development Release Repository</name>
<url>http://leroyhost:8080/repository/maven-releases/</url>
<layout>default</layout>
<releases>
<enabled>true</enabled>
<updatePolicy>interval:15</updatePolicy>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
Please note, the profile section includes its own repositories section in which the repository section above must be defined in. You also need to activate the offsite profile:
<activeProfiles>
<!--activeProfile>main-developer-profile</activeProfile-->
<activeProfile>offsite-snapshots</activeProfile>
</activeProfiles>
I named the profile snapshots because without access to our office repository, no one is doing any releases out "in the field".
After:
Maven no longer searched the public repos for our in-house release artifacts. It consulted my local repo and found all of our releases there.
This question is really, really stupid as I have no experience with Maven.
I was interested in NanoHTTPD as an embedded web server in my project, but upon downloading the source and testing it out, I get the following error:
Failed to execute goal on project nanohttpd-samples: Could not resolve dependencies for project fi.iki.elonen:nanohttpd-samples:jar:2.0.2: The following artifacts could not be resolved: fi.iki.elonen:nanohttpd:jar:2.0.2, fi.iki.elonen:nanohttpd-webserver:jar:2.0.2: Failure to find fi.iki.elonen:nanohttpd:jar:2.0.2 in http://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced -> [Help 1]
I tried the -e flag and netbeans spat out a tonne more errors related to Maven, which none made sense.
I also tried putting together one that did not involve Maven myself, which it didn't work.
I Googled for an hour and absolutely no answers are avail. Results are <10 and none are related to nanohttpd.
I know Maven is similar to Ant, but I have no idea how it works.
Anyway,
NanoHTTPD > https://github.com/NanoHttpd/nanohttpd
I am using netbeans, with JDK 7 downloaded today on this new linux box.
Help is appreciated. Below is the error reproduced on Fedora Netbeans, Stock JDK7 + NB bundle.
Full resolution : http://img10.imageshack.us/img10/2061/screenshot0608201310360.png
Thank you!
I notice that there are 2 failing tests in the main (core) package of NanoHttpd. I've fixed those and the build runs cleanly on a Ubuntu VM.
I would suggest pulling the latest from master and trying the build again, should all be fixed.
Oh, and thanks ... without you running into this issue, I might not have known about build errors when running on a a linux platform!
You can try multiple things:
1: Try deleting the corresponding failed to download artifact directory
in your local repo. Next time I run the maven command the artifact
download is triggered again. Therefore I'd say it's a client side
setting. Local repo path:
Unix/Mac OS X – ~/.m2
Windows – C:\Documents and Settings{your-username}.m2
2: As specified in the settings reference, I guess what you need is to
change the default value of updatePolicy in Maven Settings, which is
daily. I am not sure if this applies to a failed download though.
Also, always is ok for snapshots not for releases.
<profiles>
<profile>
...
<repositories>
<repository>
<id>myRepo</id>
<name>My Repository</name>
<releases>
<enabled>false</enabled>
<updatePolicy>always</updatePolicy>
<checksumPolicy>warn</checksumPolicy>
</releases>
</repository>
</repositories>
...
</profile>
</profiles>
...
</settings>
3: Use the -U in the build goal
4: Make sure you are using proper maven version Maven3/Maven2