Maven用仓库外的jar进行编译

Question

Maven2 is driving me crazy during the experimentation/quick and dirty mock-up phase of development.

I have a pom.xml file that defines the dependencies for the web-app framework I want to use, and I can quickly generate starter projects from that file. However, sometimes I want to link to a 3rd party library that doesn't already have a pom.xml file defined, so rather than create the pom.xml file for the 3rd party lib by hand and install it, and add the dependency to my pom.xml, I would just like to tell maven: "In addition to my defined dependencies, include any jars that are in /lib too."

It seems like this ought to be simple, but if it is, I am missing something.

Any pointers on how to do this are greatly appreciated. Short of that, if there is a simple way to point maven to a /lib directory and easily create a pom.xml with all the enclosed jars mapped to a single dependency which I could then name/install and link to in one fell swoop would also suffice.

Thanks!

If you're using Netbeans just follow these steps : [How do I install modules into the maven repository using Netbeans embedded Maven?][1] [1]:stackoverflow.com/a/339874/530153

score 217 · Answer 1

up vote 217 down vote

set scope == system and just make up a groupId, artifactId, and version

<dependency>
    <groupId>org.swinglabs</groupId>
    <artifactId>swingx</artifactId>
    <version>0.9.2</version>
    <scope>system</scope>
    <systemPath>${project.basedir}/lib/swingx-0.9.3.jar</systemPath>
</dependency>

2

Thanks this is really close to what I want. Any way to add them all as a single entry? Say I have /lib with 10 jars, can I add them all somehow, for instance with /some/path/*.jar for the systemPath? or I still have to treat each as a known dependency? Still, really close to what I need, thanks! – purple Dec 12 '08 at 21:47

9

use a systemPath like this one: "<systemPath>${basedir}/lib/BrowserLauncher2-1_3.jar</systemPath>" ${basedir} is pointing to your project's root. – Frederic Morin Apr 19 '09 at 7:40

2

It is better to use the project. prefix in your path like so: <systemPath>${project.basedir}/lib/AwesomeLib.jar</systemPath> – Matthew McCullough Nov 25 '09 at 21:23

28

While I understand that this is what the OP was asking for, I still want to underline that using asystem scope is an horrible practice that is strongly discouraged. SeeDependency+Scopes. – Pascal Thivent Sep 18 '10 at 19:47

2

@marioosh remember the original intent of the question was for quick experimentation. If you want to do a mvn package, install the jar into the repo. – Pyrolistical Oct 22 '11 at 5:55

show6 more comments

feedback

score 133 · Answer 2

Problems of popular approaches

Most of the answers you'll find around the internet will suggest you to either install the dependency to your local repository or specify a "system" scope in thepom and distribute the dependency with the source of your project. But both of these solutions are actually flawed.

Why you shouldn't apply the "Install to Local Repo" approach

When you install a dependency to your local repository it remains there. Your distribution artifact will do fine as long as it has access to this repository. The problem is in most cases this repository will reside on your local machine, so there'll be no way to resolve this dependency on any other machine. Clearly making your artifact depend on a specific machine is not a way to handle things. Otherwise this dependency will have to be locally installed on every machine working with that project which is not any better.

Why you shouldn't apply the "System Scope" approach

The jars you depend on with the "System Scope" approach neither get installed to any repository or attached to your target packages. That's why your distribution package won't have a way to resolve that dependency when used. That I believe was the reason why the use of system scope even got deprecated. Anyway you don't want to rely on a deprecated feature.

The static in-project repository solution

After putting this in your pom:

<repository>
    <id>repo</id>
    <releases>
        <enabled>true</enabled>
        <checksumPolicy>ignore</checksumPolicy>
    </releases>
    <snapshots>
        <enabled>false</enabled>
    </snapshots>
    <url>file://${project.basedir}/repo</url>
</repository>

for each artifact with a group id of form x.y.z Maven will include the following location inside your project dir in its search for artifacts:

repo/
| - x/
|   | - y/
|   |   | - z/
|   |   |   | - ${artifactId}/
|   |   |   |   | - ${version}/
|   |   |   |   |   | - ${artifactId}-${version}.jar

To elaborate more on this you can read this blog post.

Use Maven to install to project repo

Instead of creating this structure by hand I recommend to use a Maven plugin to install your jars as artifacts. So, to install an artifact to an in-project repository underrepo folder execute:

mvn install:install-file -DlocalRepositoryPath=repo -DcreateChecksum=true -Dpackaging=jar -Dfile=[your-jar] -DgroupId=[...] -DartifactId=[...] -Dversion=[...]

If you'll choose this approach you'll be able to simplify the repository declaration inpom to:

<repository>
    <id>repo</id>
    <url>file://${project.basedir}/repo</url>
</repository>

A helper script

Since executing installation command for each lib is kinda annoying and definitely error prone, I've created autility script which automatically installs all the jars from alib folder to a project repository, while automatically resolving all metadata (groupId, artifactId and etc.) from names of files. The script also prints out the dependencies xml for you to copy-paste in yourpom.

Include the dependencies in your target package

When you'll have your in-project repository created you'll have solved a problem of distributing the dependencies of the project with its source, but since then your project's target artifact will depend on non-published jars, so when you'll install it to a repository it will have unresolvable dependencies.

To beat this problem I suggest to include these dependencies in your target package. This you can do with either theAssembly Plugin or better with theOneJar Plugin. The official documentaion on OneJar is easy to grasp.

I always assumed you could create a repository in the project, finally confirmed it, great!
This option can be coupled with a "provided" scope in the dependency to build against a library .jar that will be made available inside the container. We've done this to link to JNI libraries that are deployed inside of Tomcat's own /lib/ folder.
Two things to note: 1) I recommend using "${project.baseUri}repo" instead of "file://${project.basedir}/repo" to get an RFC-compliant url also on Windows. 2) If you structure your project into submodules, this approach seems to fail because ${project.baseUri} gets resolved to the module's subdirectory. Any idea how to resolve this problem?

score 24 · Answer 3

Note: When using the System scope (as mentioned on this page), Maven needs absolute paths.

If your jars are under your project's root, you'll want to prefix your systemPath values with ${basedir}.

score 9 · Answer 4

You really ought to get a framework in place via a repository and identifying your dependencies up front. Using the system scope is a common mistake people use, because they "don't care about the dependency management." The trouble is that doing this you end up with a perverted maven build that will not show maven in a normal condition. You would be better off following an approach likethis.

score 6 · Answer 5

up vote 6 down vote

Maven install plugin has command line usage to install a jar into the local repository, POM is optional but you will have to specify the GroupId, ArtifactId, Version and Packaging (all the POM stuff).

	actually, what he ment is that you dont have to create a pom for the library you are importing into your local repository – Frederic Morin Apr 19 '09 at 7:42
	-1, sometimes you just want to add a jar file without the trouble of installing it. – Leonel Sep 21 '09 at 14:49

feedback

score 5 · Answer 6

This is what I have done, it also works around the package issue and it works with checked out code.

I created a new folder in the project in my case I used repo, but feel free to usesrc/repo

In my POM I had a dependency that is not in any public maven repositories

<dependency>
    <groupId>com.dovetail</groupId>
    <artifactId>zoslog4j</artifactId>
    <version>1.0.1</version>
    <scope>runtime</scope>
</dependency>

I then created the following directories repo/com/dovetail/zoslog4j/1.0.1 and copied the JAR file into that folder.

I created the following POM file to represent the downloaded file (this step is optional, but it removes a WARNING) and helps the next guy figure out where I got the file to begin with.

<?xml version="1.0" encoding="UTF-8" ?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.dovetail</groupId>
    <artifactId>zoslog4j</artifactId>
    <packaging>jar</packaging>
    <version>1.0.1</version>
    <name>z/OS Log4J Appenders</name>
    <url>http://dovetail.com/downloads/misc/index.html</url>
    <description>Apache Log4j Appender for z/OS Logstreams, files, etc.</description>
</project>

Two optional files I create are the SHA1 checksums for the POM and the JAR to remove the missing checksum warnings.

shasum -b < repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.jar \
          > repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.jar.sha1

shasum -b < repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.pom \
          > repo/com/dovetail/zoslog4j/1.0.1/zoslog4j-1.0.1.pom.sha1

Finally I add the following fragment to my pom.xml that allows me to refer to the local repository

<repositories>
    <repository>
        <id>project</id>
        <url>file:///${basedir}/repo</url>
    </repository>
</repositories>

Hi, did you put the pom files in the local repository or next to your jar files?
In the above solution it was next to the JAR files. Mind you I don't like the solution above because it is too much work.
I still prefer the solution I posted here stackoverflow.com/questions/2229757/…

score 3 · Answer 7

The problem with systemPath is that the dependencies' jars won't get distributed along your artifacts as transitive dependencies. Try what I've posted here:Is it best to Mavenize your project jar files or put them in WEB-INF/lib?

Then declare dependencies as usual.

And please read the footer note.

score 3 · Answer 8

This is how we add or install a local jar

    <dependency>
        <groupId>org.example</groupId>
        <artifactId>iamajar</artifactId>
        <version>1.0</version>
        <scope>system</scope>
        <systemPath>${project.basedir}/lib/iamajar.jar</systemPath>
    </dependency>

i gave some default groupId and artifactId because they are mandatory :)

score 2 · Answer 9

If you want a quick and dirty solution, you can do the following (though I do not recommend this for anything except test projects, maven will complain in length that this is not proper).

Add a dependency entry for each jar file you need, preferably with a perl script or something similar and copy/paste that into your pom file.

#! /usr/bin/perl

foreach my $n (@ARGV) {

    $n=~s@.*/@@;

    print "<dependency>
    <groupId>local.dummy</groupId>
    <artifactId>$n</artifactId>
    <version>0.0.1</version>
    <scope>system</scope>
    <systemPath>\${project.basedir}/lib/$n</systemPath>
</dependency>
";

score 2 · Answer 10

You may create local repository on your project

For example if you have libs folder in project structure

In libs folder you should create directory structure like: /groupId/artifactId/version/artifactId-verion.jar
In your pom.xml you should register repository

<repository>

  <id>ProjectRepo</id>
  <name>ProjectRepo</name>
  <url>file://${project.basedir}/libs</url>

</repository>

and add dependency as usual

<dependency>

   <groupId>groupId</groupId>
   <artifactId>artifactId</artifactId>
   <version>version</version>

</dependency>

That is all.

For detailed information: How to add external libraries in Maven

score 1 · Answer 11

Even though it does not exactly fit to your problem, I'll drop this here. My requirements were:

Jars that can not be found in an online maven repository should be in the SVN.
If one developer adds another library, the other developers should not be bothered with manually installing them.
The IDE (NetBeans in my case) should be able find the sources and javadocs to provide autocompletion and help.

Let's talk about (3) first: Just having the jars in a folder and somehow merging them into the final jar will not work for here, since the IDE will not understand this. This means all libraries have to be installed properly. However, I dont want to have everyone installing it using "mvn install-file".

In my project I needed metawidget. Here we go:

Create a new maven project (name it "shared-libs" or something like that).
Download metawidget and extract the zip into src/main/lib.
The folder doc/api contains the javadocs. Create a zip of the content (doc/api/api.zip).
Modify the pom like this
Build the project and the library will be installed.
Add the library as a dependency to your project, or (if you added the dependency in the shared-libs project) add shared-libs as dependency to get all libraries at once.

Every time you have a new library, just add a new execution and tell everyone to build the project again (you can improve this process with project hierachies).

You might want to check Maven: add a dependency to a jar by relative path (which is IMHO a better alternative).
It is better if you can ensure that the local repository always has the same relative path to the project. If I have many projects (or different branches) in different locations this will not work.
My answer has a way to tell pom.xml about a jar inside your project. Why not just do that, and point it to jars in ${basedir}/lib?
@Ed Because that's absolutely not what the system scope is for, system scoped dependencies have lots of side effects. This is an horrible practice that should be totally banned.

score 1 · Answer 12

After having really long discussion with CloudBees guys about properly maven packaging of such kind of JARs, they made an interesting good proposal for a solution:

Creation of a fake Maven project which attaches a pre-existing JAR as a primary artifact, running into belonged POM install:install-file execution. Here is an example of such kinf of POM:

 <build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-install-plugin</artifactId>
            <version>2.3.1</version>
            <executions>
                <execution>
                    <id>image-util-id</id>
                    <phase>install</phase>
                    <goals>
                        <goal>install-file</goal>
                    </goals>
                    <configuration>
                        <file>${basedir}/file-you-want-to-include.jar</file>
                        <groupId>${project.groupId}</groupId>
                        <artifactId>${project.artifactId}</artifactId>
                        <version>${project.version}</version>
                        <packaging>jar</packaging>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

But in order to implement it, existing project structure should be changed. First, you should have in mind that for each such kind of JAR there should be created different fake Maven project (module). And there should be created a parent Maven project including all sub-modules which are : all JAR wrappers and existing main project. The structure could be :

root project (this contains the parent POM file includes all sub-modules with module XML element) (POM packaging)

JAR 1 wrapper Maven child project (POM packaging)

JAR 2 wrapper Maven child project (POM packaging)

main existing Maven child project (WAR, JAR, EAR .... packaging)

When parent running via mvn:install or mvn:packaging is forced and sub-modules will be executed. That could be concerned as a minus here, since project structure should be changed, but offers a non static solution at the end

score 0 · Answer 13

This doesn't answer how to add them to your POM, and may be a no brainer, but would just adding the lib dir to your classpath work? I know that is what I do when I need an external jar that I don't want to add to my Maven repos.

Hope this helps.

This is what I was doing, and it works, but it also pollutes the global class path, and I'm trying to get away from it. Thanks!

score 0 · Answer 14

A strange solution I found:

using Eclipse

create simple (non-maven) java project
add a Main class
add all the jars to the classpath
export Runnable JAR (it's important, because no other way here to do it)
select Extract required libraries into generated JAR
decide the licence issues
tadammm...install the generated jar to your m2repo
add this single dependency to your other projects.

cheers, Balint

score 0 · Answer 15

What works in our project is what Archimedes Trajano wrote, but we had in our .m2/settings.xml something like this:

 <mirror>
  <id>nexus</id>
  <mirrorOf>*</mirrorOf>
  <url>http://url_to_our_repository</url>
 </mirror>

and the * should be changed to central. So if his answer doesn't work for you, you should check your settings.xml

Maven用仓库外的jar进行编译

Can I add jars to maven 2 build classpath without installing them?

15 Answers