1

I've inherited a Maven project. I'm just using it as a build tool and I'd like to disturb things as little as possible. I have to make a slight addition to one of the Java files and that addition requires that I include a new jar on the build path. How do I say: here a jar, just use it. It doesn't have to be versioned or depended or downloaded or anything, just use it. Any help would be appreciated.

EDIT: I found this, which actually works (!). If someone who knows about such things could read this answer and if it seems reasonably correct, please close this question as a dup.

EDIT: Nope, I misinterpreted my results. It doesn't seem to work.

Community
  • 1
  • 1
Michael Lorton
  • 43,060
  • 26
  • 103
  • 144

3 Answers3

3

By far the best way to manage your dependencies with maven is to get them from a repository, but four total options spring to mind, in order from most desirable to least:

  1. If the jar is a common third-party library, you'll almost certainly find it in some repository somewhere. You just have to add a <dependency> element and possibly a <repository> as well so it knows where to get the dependency from.
  2. A home-grown jar not available in any repo should be deployed to a local repository, like Nexus, which is available to your whole team/company. Then add the dependency to your project just like in option 1. This way it only has to be dealt with once, and everyone else can get the jar via the normal Maven mechanism.
  3. To only deal with the problem locally and not give any reusability of the artifact, you can install it into your local repo (meaning your local cache at ~/.m2/repository) using the install:install-file goal.
  4. Finally, and least desirably, you can use a system-scoped dependency. This means you have the jar file available somewhere in your file system, set the <scope> element of your <dependency> to the value "system", and add a <systemPath> element that contains the full path to the jar in question.

Edit: Since option 4 seems right for you, just put the jar into your project and commit it to your version control. Then, assuming the jar is at lib/foo.jar in your project, add this to your POM's dependencies:

<dependency>
    <groupId>some-group</groupId>
    <artifactId>some-artifact</artifactId>
    <version>1.2.3.4</version>
    <scope>system</scope>
    <systemPath>${project.basedir}/lib/foo.jar</systemPath>
</dependency>

That's all from memory, but it sounds right.

Ryan Stewart
  • 126,015
  • 21
  • 180
  • 199
  • It is a proprietary jar, and I'm the only person on my team/company. intall:intall-file was my first idea, but I wasn't able to get it to work (got a very vague error message). What I like about the solution from @JVerstry is that I can check it all in, so if my machine goes kerboey I can rebuilt pretty easily. – Michael Lorton Aug 16 '11 at 02:58
  • 1
    Actually his solution is just a super long way around my option 4. It does what his config does in about 1/10th the lines of XML. Just check in the jar and the POM change, and you're in exactly the same place without all the clutter. – Ryan Stewart Aug 16 '11 at 03:07
  • Added an example to my answer. – Ryan Stewart Aug 16 '11 at 03:10
  • 1
    Huh, that seemed to work. 7 versus 48 lines of XML. I guess there's a reason to not drink the Kool-Aid. Or at least not to finish off the whole pitcher... – Michael Lorton Aug 16 '11 at 03:18
  • lol +1. I love Maven, but it can get a little crazy sometimes. – Ryan Stewart Aug 16 '11 at 03:19
  • For the records, the above method is faster than the one I provide, since it only requires one step. However, there is a drawback if the same jar used in multiple projects: it is copied redundantly in all projects. – Jérôme Verstrynge Aug 23 '11 at 20:32
  • @JVerstry: That's just the nature of dependencies in Maven. It could be a problem, but you can get deduplication of dependencies through [POM inheritance](http://maven.apache.org/pom.html#Inheritance). – Ryan Stewart Aug 23 '11 at 20:47
1

Here are some related answers: Maven: keeping dependent jars in project version control

I would not recommend using install:install-file from a POM - if it's a once off requirement you're better using that from the command line and documenting it as a preparation step. However, making the build self-contained or providing a repository with the required artifacts are certainly better options.

Community
  • 1
  • 1
Brett Porter
  • 5,827
  • 27
  • 25
-1

Here is how to proceed. Create a separate maven project inspired from the following pom.xml.

<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>net.dwst</groupId>
    <artifactId>MavenMissingJars</artifactId>
    <version>1.0</version>
    <packaging>jar</packaging>

    <name>Maven Missing Jars</name>

    <build>

        <plugins>

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-install-plugin</artifactId>
                <version>2.3</version>
                <executions>
                    <execution>
                        <id>dProguard-4.6</id>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>install-file</goal>
                        </goals>
                        <inherited>false</inherited>
                        <configuration>
                            <file>toinstall/4.6/proguard.jar</file>
                            <groupId>net.sf.proguard</groupId>
                            <artifactId>proguard</artifactId>
                            <version>4.6</version>
                            <packaging>jar</packaging>
                            <generatePom>true</generatePom>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

        </plugins>

    </build>

</project>

Assuming there is a /toinstall/4.6/ directory relative to your pom.xml and that a jar called proguard.jar is in there, calling this plugin will copy the jar from your local directory to your maven local repository.

This has to be executed once, that's why it is preferable to have a separate small maven project for injecting missing jars.

Then, add a dependency in your project using the coordinates (artifactid, version and packaging) you have defined in the above pom.xml.

Jérôme Verstrynge
  • 57,710
  • 92
  • 283
  • 453
  • Oh God. Somebody please tell me this is not right. I don't really need this monstrosity, do I? (No criticism of you, JVerstry, I appreciate the help but I can't believe that this is really "disturbing things as little as possible" in Maven. – Michael Lorton Aug 16 '11 at 02:12
  • @Malvolio lol, yes, you will need that 'monstrosity'. If you have several jars to add, then you can call the plugin multiple times in the above example to install many jars. Just copy the plugin multiple times in the pom.xml and modify the configurations. – Jérôme Verstrynge Aug 16 '11 at 02:19
  • In the 80s, I worked (very briefly) in an IBM environment. Every action (like printing or compiling a file) was accomplished by producing a lengthy [JCL](http://en.wikipedia.org/wiki/Job_Control_Language) file describing what you wanted done and submitting it. Kinda reminds me of that. – Michael Lorton Aug 16 '11 at 02:24
  • 1
    @Malvolio Glad it worked. I did not like the verbosity of Maven at the beginning, but now I don't care anymore. Maven is such a great tool. Once properly configured it does the job. – Jérôme Verstrynge Aug 16 '11 at 02:39
  • That's called "drinking the Kool-Aid". – Michael Lorton Aug 16 '11 at 02:59