There are a lot of questions about this, but the answers seem to contradict each other. So I wanted to ask it for my version of Maven (3.0.4).
I have a JAR file that's not part of any maven repository. It's a local dependency. I understand there are two ways to add it to my Maven project.
Add it as a dependency and specify the file path in the <systemPath> property. (No other work needed.)
Create a local repository <my-project>/repo and install the JAR in this repository. Then, add the new repository in my pom.xml file and add the new dependency.
I'm curious which way is better practice? I've heard some negative things about the <systemPath> property, although that way looks faster.
The answer is, it depends...
If you add it as a system dependency it is likely to become path dependent which makes it more difficult to share among other developers. Sure you can also distribute the 3rd party jar relative to your POM via your SCM but the intention of systemPath is more for dependencies that are provided by the JDK or the VM. From the docs about systemPath:
They are usually used to tell Maven about dependencies which are provided by the JDK or the VM. Thus, system dependencies are especially useful for resolving dependencies on artifacts which are now provided by the JDK, but where available as separate downloads earlier.
To install the jar in the local repo is also not friendly for sharing. It requires all developers to "upload" the jar to their local repo before building. You can of course add a script that handles this for you but it is always easy to forget to upload and IMO a better solution is point 3 below. The local install process is described here.
If you are working in an organization where the developers share the POM you should upload the 3rd party jar to a local repository manager. That way you can easily work with the 3rd party jar as if using any other maven enabled jar. Check this link for a comprehensive list on repository managers.
To summarize, if you are sharing the POM with others I would suggest that you upload it to a local repository manager. Otherwise the second option can work for you. As a last option, I would fall back to option number 1.
Also note that this has nothing to do with which version of Maven you are running.
You can add jar to your local maven repository. Usually it located at:
$home_directory/.m2/repository
For example you have expample.jar and you want to add it to your pom as:
<dependency>
<groupId>com.example</groupId>
<artifactId>example</artifactId>
<version>1.0</version>
</dependency>
Then you must add example.jar to:
$home_directory/.m2/repository/com/example/1.0/example.jar
In my case NetBeans do it for me.
The best way I see so far is to use install:install-file goal with maven. You can use the mvn command line to execute it directly with appropriate parameters, or if you are using eclipse EE, you can do so by leveraging the embedded maven and creating a Run Configuration as follows:
Then, you include the jar as follows:
<dependency>
<groupId>mylocal.weka</groupId>
<artifactId>weka</artifactId>
<version>1.0</version>
</dependency>
Of course adjust the parameters as per your needs.
Best,
Haytham
Related
We have a git project that has some 3rd party jars which are not available in any Maven repo and are in a "lib" folder in the project. I need to include them for compiling, building and then package them into the WAR in WEB-INF/lib.
I cannot add them as a local maven repo from the command line because this projects needs to be buildable for anyone cloning the repo without requiring them to run extra commands (I have no way around this requirement).
I saw some people suggesting System scope but that then Maven won't package them into your WAR:
<dependency>
<groupId>com.roufid.tutorials</groupId>
<artifactId>example-app</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${basedir}/lib/yourJar.jar</systemPath>
</dependency>
How do I get these jars to be used for compiling/inspection, building and then packaged into the WAR?
You can use :
System scope but make the packaging yourself via assembly plugin
A maven repo along with your project (i.e. maven repo on-the-fly, basically same as local repo but without having a extra moving part to worry about because this repo follows your project).
For Maven repo on-the-fly option, you can do as described here (which is, take any already existing Maven repo, which already contains your needed jars, such as your local one, put it in your project, and then reference this repo from your project using relative paths).
I'll assume you've verified that whatever mechanism you might use to distribute these jars would be in compliance with the relevant licenses. If it would, then it seems there would be little reason for the jars' creators not to provide for official Maven distribution, so your best option might be to lobby for them to do that. But if not, and yet for some reason they'll allow for you distributing the jar (either through cloning of your repo, or via a separate Maven repo you maintain):
There are several ways. I give preference to approaches that don't put the jars in the git repo.
Publish a Maven Repo
So it's possible to host a public-facing repo and serve the artifacts that way. The pom can add your public-facing repo to the build, so that those who clone can build without having to run any special commands.
Running your own repo isn't terribly difficult. The OSS versions of Nexus or Artifactory jFrog would probably be perfectly capable.
But, if we're assuming the authors' refusal to publish their own jars via Maven means they don't want them distributed that way, then there's no reason to spend much time on the details of this option. So moving on...
Distribution in the Git Repo
I guess this is what you're doing, though again if Maven distribution violates the license I'd make sure you're splitting hairs the right way in thinking that this doesn't.
So the question would be how to get Maven to deal with the artifacts distributed in this way, and again there are some options.
Your objection to putting the jars in the local repo is that it would require extra commands of the user; but actually this could be automated in the "validate" phase of the build. Binding install:install-file to the validate phase should work.
Alternately, your objection to using system scope is that the file isn't copied into the final war. You might be able to use the dependency plugin to force the issue, but I'm not sure of that. What I am sure of is you could treat the directory containing the jars as a web resource with suitable configuration in the war plugin. (You'd want it to be treated as unfiltered and to map to the WEB-INF/lib folder.)
In any case, if you distribute jars (or other large binaries) in the git repo, I strongly recommend you look at git lfs. This will require one-time configuration by each of your users, but it will prevent your repo from gradually becoming bloated and unusable.
Use forward slash (/) to backslash () in the systemPath.
<dependency>
<groupId>com.roufid.tutorials</groupId>`enter code here`
<artifactId>example-app</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${basedir}\lib\yourJar.jar</systemPath>
I have been trying to use the vget library/api to make my own youtube video downloader. The vget library can be found here: https://github.com/axet/vget
I have downloaded the zip on github and I imported the project into eclipse. However, I am confused to how I am supposed to properly use this API. Should I make a completely new project, and import the classes that I need or do I put my own source files in the project of the api?
I have read other threads concerning this problem. However, they all mention how a api is typically packaged in a JAR file, but in my case it is just files and classes. So I am confused to how I should properly use this api.
The vget project is a maven project. You can see that because it has a pom.xml file in the root folder of the project.
To use it, you don't even need to download the source, because the compiled jar files are already stored in the central maven repository. You can find more information about this here:
http://mvnrepository.com/artifact/com.github.axet/vget/1.1.23
(in general, you can use the http://mvnrepository.com/ site to search whether your library is available on the maven central repository. If it's even a mildly popular library, then chances are that it is)
What you need to do is to make your own project a maven project.
Here's a "5 minutes" starter guide that describes how to do that.
When you've done that, you just add the dependency on vget to your pom.xml file in the <dependencies> section:
<dependency>
<groupId>com.github.axet</groupId>
<artifactId>vget</artifactId>
<version>1.1.23</version>
</dependency>
Since you are making use of a 3rd party software, and not extending it with your own logic, the way to go is to create a new project, which references the 3rd party software.
You then construct your application and make it do whatever you need it to do. When it comes to using logic which is available within the 3rd party logic, you would then simply delegate that call to the 3rd party library.
I have seen on the link you have provided, that this is a maven project. You have to execute a maven package command, or maven install, so that the jar file will be generated.
With this jar follow the Bill's instructions, and add it as external library to your claspath.
When you do this, you will be able to invoke methods of that api.
Let us know if you need some help doing this in eclipse.
If your project is a maven project, you can solve dependencies problems just adding the dependency written on Readme file to your pom file.
The easiest and most automatic way is to use something like maven, ant, or gradle, that will automatically download and put the jars in to your classpath if they are in the central repositories. For example, in the maven configuration file(pom.xml) you can add this to the dependency list:
VGet Maven Repository
These build tools also allow you to add external jars if needed.
If
I would suggest you get familiar with Maven. At the bottom there is a Maven dependency you just have to include into your pom.xml, and then you can use the extension immediately.
Maven is a build platform which organizes your project in a technical way (convention over configuration, e.g. code is in /src/main/java, tests are in /src/test/java). The proper way is it to create a Maven project in Eclipse (you have to install the plugin and download Maven as well) and put the dependency
<dependency>
<groupId>com.github.axet</groupId>
<artifactId>vget</artifactId>
<version>1.1.23</version>
</dependency>
into your <dependencies> inside your pom.xml. After adding it, you project recognizes the additional package automatically.
Nobody tinkers by adding libraries manually. It's actually not professional to work without a build platform like Maven or Gradle.
Here's the problem: I love using Maven, as it completely simplifies development and dependency management. However, I'm working with a server which isn't Mavenized, so I can't just add it as a provided dependency. Is there a way to simply specify an additional library folder and add it to the Java compiler classpath, or would I need to actually create an entire local Maven repository for this? I know it completely limits my portability, but I'm okay with that. Thoughts? Also, after compiling, I'll need to copy all of my non-provided dependencies to the local server lib directory, I assume I can use the copy-dependencies plugin to move everything over.
Download Nexus for free from Sonatype, or Artifactory, or any of the other repository managers.
The alternative is to learn about install:install-file to shove jars into your personal local repo. However, having a full repo as above has so many advantages (not the least speed via caching) that it's easier to just install one.
You can use a Maven2 repository implementation such as Nexus, Artifactory, or Archiva.
You can create a simple POM for the non-maven dependency you are working with and use the deploy:deploy-file goal to deploy it to the repository.
If you just need the dependency locally you can use the install:install-file to install the dependency in your local repository. This approach requires nothing more than maven be installed on your machine.
If you just want to add libraries to the path of your build without worrying about repositories you can declare them as system dependencies. I do not recommend this approach but it should work fine.
I am developing a web-app and use maven for dependency management (duh). Some of the needed jars are already available in the server lib folder, but do not match the "maven naming scheme", ie missing the version suffix.
I would like to use them for development and deployment, but..
1. i cant point maven to them because maven seem to need a version suffix. I cant omit it in the pom.
2. If i define the dependency outside maven then maven is obviously unable to build.
3. Renaming the files inside the server distribution sounds like a kludge.
What would Brian Boitano do? I mean, there sure is an elegant solution that im not aware of, or at least a good argument for one of the three solutions above.
Thank you
PS. i am using jboss 5.1 and maven 2.2.1 atm, but its subject to change
You can provide those jars as a dependency with a system scope if you want explicitly to identify where they live. For more info have a look here
IF those are not proprietary libs you are using, I'd recommend you use official versions of those from maven repository.
If they are proprietary you can manually install jar to your local repository using maven(you can use your version, suffixes, group names, artifactid etc) and then use them in your pom.
I am getting tired of manually installing javax jar files in Maven and would like to know what is the best solution to include a dependency on javax.cache, javax.transaction, or other JSRs that are not easy to find in Maven repositories.
Have you seen https://people.apache.org/~ltheussl/maven-stage-site/guides/mini/guide-coping-with-sun-jars.html ?
This link suggests groupID and artifactID's to use, as well as a java.net repository.
It looks to me like almost all of these exist in the central Maven repository under this naming scheme.
I'm not aware of one, but adding the java.net repository may help you with some of these dependencies:
<repositories>
<repository>
<id>java.net repository</id>
<url>http://download.java.net/maven/2</url>
</repository>
</repositories>
If building on more than one box and/or for team development, a local (intranet) maven repository manager can help with these "missing" jars. This centralizes the configuration and management of not only 3rd party jars that are not in a public repository, but also all external repositories in general. It could also help automate your builds, creating more 'reproducable' builds (e.g., if you have a pool of continuous integration servers).
install a mvn repo mgr (see list -- imo, nexus is really simple to start with);
use a custom settings.xml that includes a "mirrors" section pointing to your intranet mvn repo mgr. Either update your ~/.m2/settings.xml, or run maven with "mvn -s etc/settings.xml"-- useful for hudson builds, where you don't want a custom per-user settings.xml;
manually upload your 'problem' jars to your internal repo (again, super-simple w/ Nexus via a web-interface);
set up the internal mvn repo mgr as a "mirror" of repo1.maven.org/maven2, codehaus, java.net, ... (etc).
Now, you can centrally define all 3rd party repositories & 3rd party jars -- rather than requiring each person, each box and/or each project define them individually in their pom or settings.xml. Each project / person / box would ONLY define your central, internal maven repo as the single repo for all maven projects.
This also really speeds up your artifact re-download time for fresh builds, or for those times when you need to (or would like to) delete your local ~/.m2/repository cache.
Repo managers: nexus, archiva, artifactory... e.g.,: maven.apache.org/repository-management.html
- http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix
javax.cache are in jcache:jcache:1.0-XXX artifact (in Maven's central repo)
<dependency>
<groupId>jcache</groupId>
<artifactId>jcache</artifactId>
<version>1.0-dev-2</version>
</dependency>
javax.transaction.* classes are in javax.transaction:jta:1.1 artifact, JTA jar can’t be inserted in the Maven repository because the Sun’s Binary License (I know, this sucks). To use it you need to download manually the JAR (it's free) and put it into a local repo or use 1.0.1B version which is contained in java.net.
NOTE: I've read in some place JTA will be integrated in future versions of the JDK
I know is really a pain to find these artifacts in Maven's repositories but you can make a search of a class in www.mvnrepository.com and it will show you the correct groupId and artifactId for mostly all the packages.
In the particular case of JTA, I hit this post:
http://www.jugpadova.it/articles/2005/11/26/maven-2-spring-and-jta-depencies
.. which makes sense, if I didn't have to spend a lot of time in Oracle's horrible site to get the forementioned JAR file. (I was an Oracle's enthusiast myself but that site could use a lot of UX rework here and there).
I decided to replace the dependency with what Hibernate provides, via Geronimo, as per this post (worked perfectly):
https://forum.hibernate.org/viewtopic.php?p=2420836
The deal with Java licensing and Maven is currently being worked on by the Hibernate team, or so it seems here:
https://hibernate.onjira.com/browse/HHH-4548
Thanks to everyone for sharing!