I'm having an error while listing the Mavaen Repository Artifacts in my Jenkins server configuration. Error is given below.
No versions could be resolved for groupid.artifactid rtis.rtis_2.11
But my Nexus server contains the available rtis versions correctly. My point is how I can retrieve those versions available in Nexus server to my Jenkins server?
Available versions in Nexus server
Any help would be greatly appreciated.
Thank You.
As I figured out, automatically upadating mavan-metadata.xml file is the solution. In order to update the file, create a task sheduler for rebuild metadata with a cron job.
Go to Administration -> Scheduled Tasks in Nexus Repo. For more info, please refer to the image given below.
Jenkins is not finding nexus repository to resolve the artifact.
Verify these settings are correct in Maven POM:
<repositories>
<repository>
<id>project</id>
<url>https://yourreposerver/nexus/content/groups/public/</url>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>project</id>
<url>https://yourreposerver/nexus/content/groups/public/</url>
</pluginRepository>
</pluginRepositories>
Also, Jenkins plugin help page, will give you more information on what kind of settings you might be missing while setting up your job.
You have to specify the type in the dependency to be downloaded. By default in Maven it is 'jar'. However in your case it it 'tgz' so you have to specify that provided that is possible in the Jenkins user interface. I can not see that option but it should be there.
The other potential problem is that is was flagged as not found in the local repository Jenkins is using. Then you would have to either delete the metadata or force an update of it. On the Maven commandline this would be done with -U however in your UI I am not sure.
Related
I have a GitHub repo with a library published to its own GitHub packages maven repository. And I also have another project where I want to reference this library as a dependency.
When I add the following configuration to the POM file of my project it just doesn't work.
<repositories>
<repository>
<id>github</id>
<name>GitHub Packages</name>
<url>https://maven.pkg.github.com/test-account/test-lib</url>
</repository>
</repositories>
It requires me to authenticate. I understand that this is pretty logical as it is basically not a sources repo but an underlying maven repo. But is there a way to have normal maven access to this dependency? My library is in the public repo.
P.S. Please, do not suggest using Jitpack as I would like to have clean solution without any additional resources.
The answer seems to be "you can't". See this comment from a GitHub staff member:
Our Maven service doesn’t allow for unauthorized access right now. We plan to offer this in the future but need to improve the service a bit before that.
For now the simplest option seems to be to create a personal access token with read access and include it in the URL of the <repository> section in your pom.xml, like this:
<repository>
<id>github</id>
<name>GitHub Packages</name>
<url>https://my-user:b96e7de7514e45c5#maven.pkg.github.com/my-user/my-repo</url>
</repository>
Otherwise, options are probably:
Create a personal access token with read access and just share it with the whole world.
Use the workaround described here
Publish to Maven Central (but that's a whole world of pain)
Currently, you cannot. There is an ongoing discussion here with this feature request. You can find multiple workarounds in that discussion thread and also voice your opinion.
The accepted answer no longer works.
Currently GitGuardian automatically revokes the Personal Access Token (PAT) if that method is applied in public repositories. As recommended by GitHub staff, the work-around solution is the following:
Create a PAT with just the read:packages scope
Execute docker run ghcr.io/jcansdale/gpr encode
This will output the following:
$ docker run ghcr.io/jcansdale/gpr encode 0123456789abcsef
An encoded token can be included in a public repository without being automatically deleted by GitHub.
These can be used in various package ecosystems like this:
A NuGet `nuget.config` file:
<packageSourceCredentials>
<github>
<add key="Username" value="PublicToken" />
<add key="ClearTextPassword" value="0123456789abcsef" />
</github>
</packageSourceCredentials>
A Maven `pom.xml` file:
<repositories>
<repository>
<id>github-public</id>
<url>https://public:0123456789abcsef#maven.pkg.github.com/<OWNER>/*</url>
</repository>
</repositories>
An npm `.npmrc` file:
#OWNER:registry=https://npm.pkg.github.com
//npm.pkg.github.com/:_authToken="\u0030123456789abcsef"
You can use this snippet in you project’s configuration file.
Note, you shouldn’t include your own read:packages PAT if you have access to any private packages you need to protect. In this case it is best to create a machine-user.
If you don't consider as additional resource a Gradle plugin, then I'd suggest you mine
I was exactly in your shoes, you can either:
have a Github repository acting as a Maven repository
or publish on Github Packages and easier the consumption for Gradle
clients
When I try to to install maven project in local repository, I notice that pom and jar files have .lastUpdated extension. Because of this issue I cannot build my project which depends on it.
Could you please explain why it happens?
I've found the answer here :
When an artifact is unable to be downloaded, Maven 3 caches this result for future reference in the "~/.m2/repo/.../.lastUpdated" file. For "not found" situations, it seems that the HTTP code could be used to more granularly re-attempt retrieval rather than just cache the failure.
For example, for any 404, I agree, the result should cache the failure and require a -U to attempt to retrieve it again. However, for 400, 500, 501, 502, 503, 301, 302 (what's the Maven behavior for 3xx today?) I think the resolution engine should try to re-retrieve the artifact each time. With those error codes, it seems more likely a config issue or brief network hiccup, not one of the file being absent from that repo. However, that brief network hiccup has longstanding cache implications in that the file is never attempted to be retrieved again.
It also can happen when you refer to the artifact which is listed under Maven Repository but is not there physically. E.g., the following Exasol artifact is listed under Maven Repository, but there's a small side note which tells that:
Note: this artifact i[s] located at Exasol repository
(https://maven.exasol.com/artifactory/exasol-releases/)
This means that you need to separately add another repository (in this case Exasol) as a source in your pom.xml file:
<!-- add the dependency as mentioned in maven website -->
<dependencies>
<dependency>
<groupId>com.exasol</groupId>
<artifactId>exasol-jdbc</artifactId>
<version>6.2.1</version>
</dependency>
</dependencies>
<!-- add the actual repository which unfortunately isn't mentioned in maven website -->
<repositories>
<repository>
<id>maven.exasol.com</id>
<url>https://maven.exasol.com/artifactory/exasol-releases</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>
I have several projects which use Maven and I would like to run an internal repository on my work network. I have several libraries which are from third parties and cannot be released into the wild, as well as a few libraries of our own which need to be available within the network (including to our TeamCity CI Server) but cannot be deployed outside the network. After a bit of research, I found three main recommendations on how to accomplish this: Archiva, Artifactory, and Nexus. I have tried each, and have failed to achieve a successful build of any of my projects using the internal repositories created by any of them.
This leads me to believe that I am misunderstanding something or doing something wrong. Does anyone know of a tutorial that will walk me through setting up and internal Maven repository and integrate it with my project?
I have only worked with Nexus, but I found it very easy to install:
Go to http://www.sonatype.org/nexus/go to download the OSS version
Get the 'WAR' distribution
Install the servlet in my installation of Tomcat, via the Web Application Manager
At that point, I can visit http://myserver:8080/nexus to see everything working.
For a superficial setup, I add the default password to my settings.xml:
<servers>
<server>
<id>my-snapshots</id>
<username>admin</username>
<password>admin123</password>
</server>
<server>
<id>my-releases</id>
<username>admin</username>
<password>admin123</password>
</server>
</servers>
and in my POM file:
<distributionManagement>
<snapshotRepository>
<id>my-snapshots</id>
<name>My internal repository</name>
<url>http://myserver:8080/nexus/content/repositories/snapshots</url>
</snapshotRepository>
<repository>
<id>my-releases</id>
<name>My internal repository</name>
<url>http://myserver:8080/nexus/content/repositories/releases</url>
</repository>
</distributionManagement>
To go beyond this, the learning curve jumps up quite a bit, but I found Sonatype's online books to be pretty good. Repository Management with Nexus is the one for understanding what you can do with the repository server. The only thing I found tricky is that some of the info applies only to their commercial software and they don't work too hard to advertise the difference.
Repository managers like Archiva and Nexus are more than just an internal repository. They serve as proxies that obviate reaching out to Maven central or other external repository.
For just an internal repository all you need is a network or HTTP accessible location that has the structure of a Maven repository. Then you refer to it as another repository in your settings file.
<repository>
<id>my-internal-repo</id>
<url>http://myrepo.mycompany.com/</url>
</repository>
See more in Maven's documentation at http://maven.apache.org/guides/introduction/introduction-to-repositories.html.
I would suggest to use the Nexus evaluation guide (latest available version is 2.13 now) that comes with the Nexus Pro Installer, but also works with Nexus Open Source for the simple use cases of proxying and deploying components.
The examples are also available on github and include setups for Maven, Ant/Ivy and Gradle. Once you have a look at the examples and read the guide you will be able to set up your projects in the same way easily.
And of course if there is any problems you can always ask on the mailing list or chat with the developers on hipchat
I've been looking at google and nothing really points to this problem. When I run "mvn clean install" it returns the following error.
[ERROR] Unresolveable build extension: Plugin
org.sonatype.flexmojos:flexmojos-maven-plugin:3.8 or one of its
dependencies could not be resolved: Failed to collect dependencies for
org.sonatype.flexmojos:flexmojos-maven-plugin:jar:3.8 ()
I'm trying to figure out how to import the maven plugin flexmojos but there are no clear directions on how to do this.
How would I import this plugin into my project?
The dependency you are looking for does exist.
To troubleshoot this problem further we'd need to see your POM and the rest of your build output.
Taking a stab in the dark:
Is this the first time you're running this build on this machine? If so, a very common "gotcha" is a corporate firewall preventing access to Maven Central. The solution in this case is setup a Maven repository manager like Nexus, or configure Maven to use a HTTP proxy.
I had a similar problem. I set up the proxy in Eclipse then I discovered I also set up the proxy in my settings.xml. I deleted the proxy from settings.xml and all worked out.
I hope my situation will help!
I solved this by adding another profile parameter from my pom.xml to my mvn command, e.g. "-Pprofile-name" pointing to a non-Maven repo definition embedded inside that profile, since Maven might be looking for repo definitions to be standing alone in a settings.xml, which isn't always the case.
I resolved this by adding a settings.xml file in the ~\.m2 directory, with the appropriate configuration pointing to our internal libraries.
If this Problem is displayed in the Eclipse Environment, this is because the m2e Connector tries to download the Plugins in to your ~\.m2\ repository
to solve this, open your Eclipse Settings: Window->Preferences and go to the ->Maven->User Settings Section.
Check if either Global Settings or User Settings is connected to the settings.xml File that your Maven uses.
Generally: Maven or your m2e connector tries to download these plugins via the plugin-repositories configured in your settings.xml it's can't find them because the repository is unknown or not reachable because you are behind a proxy or so:
08.11.18, 15:54:47 MEZ: [WARN] Failed to build parent project for com.xxx.xxx.xxx:eclipse-plugin:1.0.0-SNAPSHOT
08.11.18, 15:54:47 MEZ: [WARN] Failure to transfer org.apache.maven.plugins:maven-site-plugin/maven-metadata.xml from http://repository.sonatype.org/content/groups/sonatype-public-grid was cached in the local repository, resolution will not be reattempted until the update interval of tycho has elapsed or updates are forced. Original error: Could not transfer metadata org.apache.maven.plugins:maven-site-plugin/maven-metadata.xml from/to tycho (http://repository.sonatype.org/content/groups/sonatype-public-grid): repository.sonatype.org
go to your settings.xml file and add:
Mirrors (in this example: central repository. Do so for any other repos accordingly e.g. tycho):
<mirror>
<id>central</id>
<name>Our mirror for central repo</name>
<url>http://<your host to>/nexus/content/repositories/central/</url>
<mirrorOf>central</mirrorOf>
</mirror>
Repository:
<repository>
<id>central</id>
<url>http://<your host to>/nexus/content/groups/public/</url>
<layout>default</layout>
<releases>
<enabled>true</enabled>
<updatePolicy>daily</updatePolicy>
<checksumPolicy>warn</checksumPolicy>
</releases>
</repository>
this should fix your problems:
Eclipse Specific: if Errors prevails (e.g. unknown packaging) add lifecycle mappings via Window->Preferences->Maven->Discovery->Open Catalog and add Tycho Connector
Further you can add the lifecycle-mapping plugin that handles these lifecycle mappings in the eclipse environment: eclipse m2e lifecycle mappings
Maybe you end up here because you are running nexus for a long time.
I finally found the error Summary tab in the Repositories page.
At some point Maven Central decided to require https: and the URL listed in my configuration still was using http:.
Update the URL to use https:, Save and everything worked smoothly again!
I'm hosting ojdbc14.jar on my network nexus instance, but only local builds seem to pass.
I have this in my pom:
<repositories>
<repository>
<releases>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
<checksumPolicy>warn</checksumPolicy>
</releases>
<id>thirdparty</id>
<url>http://server/nexus/content/repositories/thirdparty</url>
</repository>
</repositories>
After completing removing ~/.m2/, a local mvn package will find ojdbc14.jar on nexus. My jenkins builds, conversely, consistently fail on this:
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.csodehaus.mojo:sql-maven-plugin:1.3:execute (sql-ddl) on project mongo-dbunit: Execution
sql-ddl of goal org.codehaus.mojo:sql-maven-plugin:1.3:execute failed: Plugin
org.codehaus.mojo:sql-maven-plugin:1.3 or one of its dependencies could not be resolved: Could not find artifact com.oracle:ojdbc14:jar:10.2.0.4.0 in central
Why?
(http://repo1.maven.org/maven2)
Before you do anything, install Config File Provider Plugin
Then,
Go to Jenkins root page
Choose 'Manage Jenkins'
Choose 'Configuration files'
Choose type 'Maven settings.xml file'
Name it 'custom-maven-settings' and cut and paste contents of your ~/.m2/settings.xml file
Now back to your Maven2/3 job.
In the Build section click Advanced button
In the Maven Settings Configs drop down box choose custom-maven-settings
This setup works with our custom repository.
You have a <repositories> section in your POM, but not a <pluginRepositories>. Maven used to be a lot more sloppy about the difference between compile-time artifact dependencies and plugin dependencies, but in newer versions of Maven they're completely separate.
As others have pointed out, it might be easier to troubleshoot this by running Maven from the command line, outside of Jenkins. Just doing a build on a different machine than the one you are typically developing on will usually bring a lot issues to light.
Here's some documentation on the POM that may or may not be helpful.
I'd check and make sure that the Maven settings are the same on both machines.
Jenkins by default uses the file in $HOME/.m2/settings.xml. It's also possible for a Jenkins job to override this default.