I have some local jar files in my 'projectBaseDir/lib' location and i have added the directory with the following maven command
<repositories>
<repository>
<id>mylibid</id>
<url>file://${project.basedir}/lib</url>
</repository>
</repositories>
still, the following command shows that it doesn't find any library / showing errors.
mvn clean install
Here is a screenshot -
Create a new folder, let's say local-maven-repo at the root of your Maven project.
Just add a local repo inside your of your pom.xml:
<repositories>
<repository>
<id>local-maven-repo</id>
<url>file:///${project.basedir}/local-maven-repo</url>
</repository>
</repositories>
Then for each external jar you want to install, go at the root of your project and execute:
mvn deploy:deploy-file -DgroupId=[GROUP] -DartifactId=[ARTIFACT] -Dversion=[VERS] -Durl=file:./local-maven-repo/ -DrepositoryId=local-maven-repo -DupdateReleaseInfo=true -Dfile=[FILE_PATH]
I have web project which I am going to deploy to nexus repository after successful build on jenkins. Currently in project in pom.xml I have following configuration as below where host and port to nexus repository is hardcoded:
<profiles>
<profile>
<id>deploy-snapshot</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<distributionManagement>
<snapshotRepository>
<id>snapshots</id>
<name>Repository for snapshots</name>
<url>http://ip1:port1/nexus/content/repositories/snapshots</url>
</snapshotRepository>
</distributionManagement>
</profile>
</profiles>
My goal is override nexus url from jenkins without any changes in pom.xml, because currently that configuration in pom.xml is used on another environment which cannot be reconfigured.
It would be good to know in which way it can be done on jenkins taking into account that in future I am going to make similar for other job which will be in charge of deploying npm packages.
I've looked into following jenkins plugin https://wiki.jenkins.io/display/JENKINS/Nexus+Artifact+Uploader, but not sure that this one is actual one, also not sure that plugin will be good for zip archives for npm build.
That was requested in 2008(!) with Make the issue 295: "distributionManagement.site.url configurable from the command line"
In your case, check if passing the property altDeploymentRepository would help:
-DaltDeploymentRepository=...
More precisely, as in "Maven deploy:deploy using -DaltDeploymentRepository"
-DaltDeploymentRepository=releaseRepository::default::http://your.repo.url
"defaut" is the maven2 layout ("legacy" is for maven 1)
In order to overwrite it, you can set it in settings.xml file
In the version of Jenkins I'm using, which is ver. 1.602, if you configure your project as a Maven project, you can specify a "Deploy artifacts to Maven repostitory" post build action for which you can indicate the destination repository.
My versions:
Maven 3.0.4
Jenkins 1.499
Nexus 2.2
maven-release-plugin 3.2
jdk 1.6
AIX 6.1
settings.xml
<server>
<id>snapshots</id>
<username>deploy</username>
<password>pass123</password>
</server>
<server>
<id>releases</id>
<username>deploy</username>
<password>pass123</password>
</server>
I have a lot of builds running in Jenkins which use the maven deploy plugin and upload artifacts to the Nexus repo. Since the same user is able to deploy snapshots we can eliminate user roles/permissions issue in Nexus. (I still gave admin role to this user for testing)
Company parent POM
<distributionManagement>
<repository>
<id>releases</id>
<url>http://myserver/repositories/releases</url>
<layout>default</layout>
</repository>
<snapshotRepository>
<id>snapshots</id>
<url>http://myserver/repositories/snapshots</url>
<layout>default</layout>
</snapshotRepository>
</distributionManagement>
Project POM
<scm>
<connection>scm:svn:http://svnserver/tags/1.2.3</connection>
<developerConnection>scm:svn:http://svnserver/tags/1.2.3</developerConnection>
</scm>
I have confirmed the /target/checkout/ in the Jenkins workspace contains the latest POM. Also added <distributionManagement> inside the project POM
Now when I run maven release plugin from within Jenkins using mvn release:perform I am still getting this:
Deployment failed: repository element was not specified in the POM inside
distributionManagement element or in -DaltDeploymentRepository=id::layout
::url parameter
release:prepare shows no errors
The SVN tag gets created as expected
Then during deploy, it fails with the above error
Like I mentioned, snapshot deployment happens frequently and without error, so settings.xml, distributionManagement and Nexus permissions all seem to be in order.
I am able to access http://myserver/repositories/releases manually
I have checked with mvn help:effective-pom and mvn help:effective-settings and things seem to be in order
Any ideas ?
The error message is very explicit. There is NO distributionManagement in your POM. So you potentially are no inherting from the parent pom.
Run
mvn help:effective-pom
in the project you are trying to deploy and check. Or alternatively look at the effective POM in your IDE (Eclipse or whatever).
Then figure out the correct parent pom to use or potentially insert the distribtionManagement segment as desired.
I have a fork of a small open sourced library that I'm working on github. I'd like to make it available to other developers via maven, but I don't want to run my own Nexus server, and because it's a fork I can't easily deploy it to oss.sonatype.org.
What I'd like to do is to deploy it to github so that others can access it using maven. What's the best way to do this?
The best solution I've been able to find consists of these steps:
Create a branch called mvn-repo to host your maven artifacts.
Use the github site-maven-plugin to push your artifacts to github.
Configure maven to use your remote mvn-repo as a maven repository.
There are several benefits to using this approach:
Maven artifacts are kept separate from your source in a separate branch called mvn-repo, much like github pages are kept in a separate branch called gh-pages (if you use github pages)
Unlike some other proposed solutions, it doesn't conflict with your gh-pages if you're using them.
Ties in naturally with the deploy target so there are no new maven commands to learn. Just use mvn deploy as you normally would
The typical way you deploy artifacts to a remote maven repo is to use mvn deploy, so let's patch into that mechanism for this solution.
First, tell maven to deploy artifacts to a temporary staging location inside your target directory. Add this to your pom.xml:
<distributionManagement>
<repository>
<id>internal.repo</id>
<name>Temporary Staging Repository</name>
<url>file://${project.build.directory}/mvn-repo</url>
</repository>
</distributionManagement>
<plugins>
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.8.1</version>
<configuration>
<altDeploymentRepository>internal.repo::default::file://${project.build.directory}/mvn-repo</altDeploymentRepository>
</configuration>
</plugin>
</plugins>
Now try running mvn clean deploy. You'll see that it deployed your maven repository to target/mvn-repo. The next step is to get it to upload that directory to GitHub.
Add your authentication information to ~/.m2/settings.xml so that the github site-maven-plugin can push to GitHub:
<!-- NOTE: MAKE SURE THAT settings.xml IS NOT WORLD READABLE! -->
<settings>
<servers>
<server>
<id>github</id>
<username>YOUR-USERNAME</username>
<password>YOUR-PASSWORD</password>
</server>
</servers>
</settings>
(As noted, please make sure to chmod 700 settings.xml to ensure no one can read your password in the file. If someone knows how to make site-maven-plugin prompt for a password instead of requiring it in a config file, let me know.)
Then tell the GitHub site-maven-plugin about the new server you just configured by adding the following to your pom:
<properties>
<!-- github server corresponds to entry in ~/.m2/settings.xml -->
<github.global.server>github</github.global.server>
</properties>
Finally, configure the site-maven-plugin to upload from your temporary staging repo to your mvn-repo branch on Github:
<build>
<plugins>
<plugin>
<groupId>com.github.github</groupId>
<artifactId>site-maven-plugin</artifactId>
<version>0.11</version>
<configuration>
<message>Maven artifacts for ${project.version}</message> <!-- git commit message -->
<noJekyll>true</noJekyll> <!-- disable webpage processing -->
<outputDirectory>${project.build.directory}/mvn-repo</outputDirectory> <!-- matches distribution management repository url above -->
<branch>refs/heads/mvn-repo</branch> <!-- remote branch name -->
<includes><include>**/*</include></includes>
<repositoryName>YOUR-REPOSITORY-NAME</repositoryName> <!-- github repo name -->
<repositoryOwner>YOUR-GITHUB-USERNAME</repositoryOwner> <!-- github username -->
</configuration>
<executions>
<!-- run site-maven-plugin's 'site' target as part of the build's normal 'deploy' phase -->
<execution>
<goals>
<goal>site</goal>
</goals>
<phase>deploy</phase>
</execution>
</executions>
</plugin>
</plugins>
</build>
The mvn-repo branch does not need to exist, it will be created for you.
Now run mvn clean deploy again. You should see maven-deploy-plugin "upload" the files to your local staging repository in the target directory, then site-maven-plugin committing those files and pushing them to the server.
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building DaoCore 1.3-SNAPSHOT
[INFO] ------------------------------------------------------------------------
...
[INFO] --- maven-deploy-plugin:2.5:deploy (default-deploy) # greendao ---
Uploaded: file:///Users/mike/Projects/greendao-emmby/DaoCore/target/mvn-repo/com/greendao-orm/greendao/1.3-SNAPSHOT/greendao-1.3-20121223.182256-3.jar (77 KB at 2936.9 KB/sec)
Uploaded: file:///Users/mike/Projects/greendao-emmby/DaoCore/target/mvn-repo/com/greendao-orm/greendao/1.3-SNAPSHOT/greendao-1.3-20121223.182256-3.pom (3 KB at 1402.3 KB/sec)
Uploaded: file:///Users/mike/Projects/greendao-emmby/DaoCore/target/mvn-repo/com/greendao-orm/greendao/1.3-SNAPSHOT/maven-metadata.xml (768 B at 150.0 KB/sec)
Uploaded: file:///Users/mike/Projects/greendao-emmby/DaoCore/target/mvn-repo/com/greendao-orm/greendao/maven-metadata.xml (282 B at 91.8 KB/sec)
[INFO]
[INFO] --- site-maven-plugin:0.7:site (default) # greendao ---
[INFO] Creating 24 blobs
[INFO] Creating tree with 25 blob entries
[INFO] Creating commit with SHA-1: 0b8444e487a8acf9caabe7ec18a4e9cff4964809
[INFO] Updating reference refs/heads/mvn-repo from ab7afb9a228bf33d9e04db39d178f96a7a225593 to 0b8444e487a8acf9caabe7ec18a4e9cff4964809
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 8.595s
[INFO] Finished at: Sun Dec 23 11:23:03 MST 2012
[INFO] Final Memory: 9M/81M
[INFO] ------------------------------------------------------------------------
Visit github.com in your browser, select the mvn-repo branch, and verify that all your binaries are now there.
Congratulations!
You can now deploy your maven artifacts to a poor man's public repo simply by running mvn clean deploy.
There's one more step you'll want to take, which is to configure any poms that depend on your pom to know where your repository is. Add the following snippet to any project's pom that depends on your project:
<repositories>
<repository>
<id>YOUR-PROJECT-NAME-mvn-repo</id>
<url>https://github.com/YOUR-USERNAME/YOUR-PROJECT-NAME/raw/mvn-repo/</url>
<snapshots>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
</snapshots>
</repository>
</repositories>
Now any project that requires your jar files will automatically download them from your github maven repository.
Edit: to avoid the problem mentioned in the comments ('Error creating commit: Invalid request. For 'properties/name', nil is not a string.'), make sure you state a name in your profile on github.
Don't use GitHub as a Maven Repository.
Edit: This option gets a lot of down votes, but no comments as to why. This is the correct option regardless of the technical capabilities to actually host on GitHub. Hosting on GitHub is wrong for all the reasons outlined below and without comments I can't improve the answer to clarify your issues.
Best Option - Collaborate with the Original Project
The best option is to convince the original project to include your changes and stick with the original.
Alternative - Maintain your own Fork
Since you have forked an open source library, and your fork is also open source, you can upload your fork to Maven Central (read Guide to uploading artifacts to the Central Repository) by giving it a new groupId and maybe a new artifactId.
Only consider this option if you are willing to maintain this fork until the changes are incorporated into the original project and then you should abandon this one.
Really consider hard whether a fork is the right option. Read the myriad Google results for 'why not to fork'
Reasoning
Bloating your repository with jars increases download size for no benefit
A jar is an output of your project, it can be regenerated at any time from its inputs, and your GitHub repo should contain only inputs.
Don't believe me? Then check Google results for 'dont store binaries in git'.
GitHub's help Working with large files will tell you the same thing. Admittedly jar's aren't large but they are larger than the source code and once a jar has been created by a release they have no reason to be versioned - that is what a new release is for.
Defining multiple repos in your pom.xml slows your build down by Number of Repositories times Number of Artifacts
Stephen Connolly says:
If anyone adds your repo they impact their build performance
as they now have another repo to check artifacts against... It's not a big
problem if you only have to add one repo... But the problem grows and the next
thing you know your maven build is checking 50 repos for every artifact and
build time is a dog.
That's right! Maven needs to check every artifact (and its dependencies) defined in your pom.xml against every Repository you have defined, as a newer version might be available in any of those repositories.
Try it out for yourself and you will feel the pain of a slow build.
The best place for artifacts is in Maven Central, as its the central place for jars, and this means your build will only ever check one place.
You can read some more about repositories at Maven's documentation on Introduction to Repositories
You can use JitPack (free for public Git repositories) to expose your GitHub repository as a Maven artifact. Its very easy. Your users would need to add this to their pom.xml:
Add repository:
<repository>
<id>jitpack.io</id>
<url>https://jitpack.io</url>
</repository>
Add dependency:
<dependency>
<groupId>com.github.User</groupId>
<artifactId>Repo name</artifactId>
<version>Release tag</version>
</dependency>
As answered elsewhere the idea is that JitPack will build your GitHub repo and will serve the jars. The requirement is that you have a build file and a GitHub release.
The nice thing is that you don't have to handle deployment and uploads. Since you didn't want to maintain your own artifact repository its a good match for your needs.
Since 2019 you can now use the new functionality called Github package registry.
Basically the process is:
generate a new personal access token from the github settings
add repository and token info in your settings.xml
deploy using
mvn deploy -Dregistry=https://maven.pkg.github.com/yourusername -Dtoken=yor_token
Another alternative is to use any web hosting with webdav support. You will need some space for this somewhere of course but it is straightforward to set up and a good alternative to running a full blown nexus server.
add this to your build section
<extensions>
<extension>
<artifactId>wagon-webdav-jackrabbit</artifactId>
<groupId>org.apache.maven.wagon</groupId>
<version>2.2</version>
</extension>
</extensions>
Add something like this to your distributionManagement section
<repository>
<id>release.repo</id>
<url>dav:http://repo.jillesvangurp.com/releases/</url>
</repository>
Finally make sure to setup the repository access in your settings.xml
add this to your servers section
<server>
<id>release.repo</id>
<username>xxxx</username>
<password>xxxx</password>
</server>
and a definition to your repositories section
<repository>
<id>release.repo</id>
<url>http://repo.jillesvangurp.com/releases</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
Finally, if you have any standard php hosting, you can use something like sabredav to add webdav capabilities.
Advantages: you have your own maven repository
Downsides: you don't have any of the management capabilities in nexus; you need some webdav setup somewhere
As an alternative, Bintray provides free hosting of maven repositories. That's probably a good alternative to Sonatype OSS and Maven Central if you absolutely don't want to rename the groupId. But please, at least make an effort to get your changes integrated upstream or rename and publish to Central. It makes it much easier for others to use your fork.
If you have only aar or jar file itself, or just don't want to use plugins - I've created a simple shell script. You can achieve the same with it - publishing your artifacts to Github and use it as public Maven repo.
I'd like to add another alternative, a Gradle plugin I've been working on lately: magik.
Basically it allows to publish directly on a github repository acting as a maven repository.
I came here looking to do the same thing, unlitmately host my Maven repository for free, but after more research I ended up here:
https://jfrog.com/start-free/
The setup was quite strightforward, has a good free tier which will serve me for the forseeable future, and has additional (paid for) upgrades which may well come in handy in the future.
So far I am very pleased indeed !
I am working on project which has multiple dependencies. Most of the dependencies are available at our centralized maven repository. My project includes some JARs which only specific to my application and unavailable at our Maven repo. Due to some policy/restriction i cant deploy that jars to our maven repository.
When i install these jars in my local repository(i.e.UserHome/.m2/repository) and compile the code its working fine.
Now i want these dependencies in SVN so that we can build the application package using Continuum.(We cant refer local dependency from Continuum server.)
Just to achieve these i copied the locally installed dependency from .m2/repository and committed it in SVN. Then i declared repository in pom.xml like..
<repositories>
<repository>
<id>repo.pu</id>
<name>repo.pu</name>
<url>https://URL/migration2/APP1/src/main/lib/</url>
<layout>default</layout>
</repository>
</repositories>
Now to use dependency from above repo i added code like...
<dependencies>
<dependency>
<groupId>repo.pu</groupId>
<artifactId>Ptestval</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
When i type mvn verify i am getting the below error..
[ERROR] Failed to execute goal on project APP1: Could not resolve dependencies f
or project fileservices.migration2:APP1:jar:1.0: Failed to collect dependencies
for [repo.pu:Ptestval:jar:1.0 (compile)]: Failed to read artifact descriptor for
repo.pu:Ptestval:jar:1.0: Could not transfer artifact repo.pu:Ptestval:pom:1.0
from/to repo.pu (https://URL/migration2/APP1/src/main/lib/): Access denied to:
https://URL/migration2/APP1/src/main/lib/repo/pu/Ptestv
al/1.0/Ptestval-1.0.pom -> [Help 1]
Could you please someone help me to resolve these issue?
EDIT: I created a repository like ..
<repositories>
<repository>
<id>repo.pu</id>
<name>repo.pu</name>
<url>https://SVNUserName:SVNPassword#SVN_URL/BaseProj/ProjA/src/main/lib</url>
<layout>default</layout>
</repository>
</repositories>
This technique works perfectly at my Personal laptop. Maven downloads the listed dependency from repo.
But when tries to use the same in my project on company network it is not working .. It gives the same error which i was getting before using this approach.
Can anyone help me please? What would be problem? Is it a network issue?
Set up a repository manager like Nexus and don't abuse Subversion for something it was not designed for. This is unfortunately done in Google Code.
You must configure your project to use wagon-scm.
See http://maven.apache.org/wagon/wagon-providers/wagon-scm/usage.html