Also install the .pom file alongside the .jar file #3

wants to merge 4 commits into

4 participants



If there is a ".pom" file right next to the ".jar" file being installed, localrepo install will also install the ".pom" file into the local repository.

Some details

Prior to this change, localrepo would merely install the specified jar file without a way to also install the coresponding .pom file. Such "pom-less" installs worked but caused warnings from lein whenever it resolved dependencies (e.g. during deps or classpath tasks).

Here's the example of warnings I got when I had elasticsearch installed locally but without its pom file:

$ lein deps 
Could not find artifact org.elasticsearch:elasticsearch:pom:0.19.8 in central (
Could not find artifact org.elasticsearch:elasticsearch:pom:0.19.8 in clojars (
Could not find artifact org.elasticsearch:elasticsearch:jar:0.19.8 in central (
Could not find artifact org.elasticsearch:elasticsearch:jar:0.19.8 in clojars (
@paxan paxan referenced this pull request Aug 4, 2012

pom file not installed in repo #1


@paxan I was planning to work on it next week, but I am glad you chipped in. Automatic pickup of pom.xml has a disadvantage, wherein it forces me to remove the pom.xml if it exists beside the JAR in case I don't want the POM file to be installed as well. Hence, this may look like surprising behavior to some.

Could you please update the pull request to include the POM only when somebody specifies -p </path/to/pom.xml> switch as in the following example? (The idea is to make it easy and predictable for those who know nothing about POM files.)

$ lein localrepo install -p /tmp/pom.xml /tmp/foo-1.0.0.jar foo/foo 1.0.0

If you insist on auto-pickup of pom.xml, I would advise to introduce -a flag to indicate that the user wants the pom.xml to be automatically picked up. If no pom.xml exists, it should probably generate a temporary minimal one and install that together with the JAR.

Other points I wanted to mention after looking at paxan@7edb0e9

  • oftentimes people install ZIP files (or whatever) instead of JAR files
  • file extensions may be upper-case (on Windows)

@kumarshantanu, I am amenable to your -p /path/to/pom/file proposal.

Aside from that, I'd like to understand the local repository structure better. Is there some sort of definitive guide about what's allowed and what is not?

For instance, I found that if you have foo/bar/1.2.3/bar-1.2.3.jar installed without a matching POM file, every time aether library is used to resolve dependencies, you get warnings about this artifact not being found in various repositories that Leiningen checks. So from this I infer that a POM file must always be installed to mollify the dependency resolution logic. Was that a wrong conclusion?

When people install ZIP files, do they get renamed by aether into JAR files during installation?


@paxan The POM files originated from Maven -- I guess the following Maven references may help:

Maven by example
Maven complete reference

Copying artifacts to the local repo without corresponding POM file has worked when using Maven or Lein 1, and when using Lein 2 (actually Aether) with warning messages. However, I am not entirely sure what's the official Maven info on this.

The ZIP files are independent artifacts and should be copied as-it-is to the repo. From looking at Aether sources, it did not appear to me that they would be renamed as .JAR. I have used ZIP artifacts earlier and found them to be named .ZIP in the local repo.


@kumarshantanu here's some more intel on Maven local repository installation.

According to Maven FAQ, Maven's install plugin (after downloading the dependencies for each atom in the Universe) will generate a basic POM file automatically. This file will have no dependencies which is a reasonable assumption, given the use case.

$ mvn install:install-file -Dfile=artifacts/jericho-html/3.2/jericho-html-3.2.jar -DgroupId=jericho-html -DartifactId=jericho-html -Dversion=3.2 -Dpackaging=jar
[INFO] --- maven-install-plugin:2.3.1:install-file (default-cli) @ standalone-pom ---
[INFO] Installing /Users/pavel/Documents/src/cafebabe/artifacts/jericho-html/3.2/jericho-html-3.2.jar to /Users/pavel/.m2/repository/jericho-html/jericho-html/3.2/jericho-html-3.2.jar
[INFO] Installing /var/folders/tr/569jy8tn0p1cdl38h1k0ygnh0000gn/T/mvninstall4985200864546258510.pom to /Users/pavel/.m2/repository/jericho-html/jericho-html/3.2/jericho-html-3.2.pom

Note that the pom file was generated in the mvn output above.

If you insist on providing your own version of POM file (e.g. when the JAR in question, in fact, has some dependencies), you will have to perform the installation in two steps:

  1. Install the JAR file using the command above with additional argument: -DgeneratePom=false
  2. Install the POM file (e.g. pom.xml) using the command below. Note the use of -Dpackaging=pom
$ mvn install:install-file -Dfile=artifacts/jericho-html/3.2/pom.xml -DgroupId=jericho-html -DartifactId=jericho-html -Dversion=3.2 -Dpackaging=pom -DgeneratePom=false
[INFO] --- maven-install-plugin:2.3.1:install-file (default-cli) @ standalone-pom ---
[INFO] Installing /Users/pavel/Documents/src/cafebabe/artifacts/jericho-html/3.2/pom.xml to /Users/pavel/.m2/repository/jericho-html/jericho-html/3.2/jericho-html-3.2.pom

My sense is that a well-installed JAR in the local repo MUST have the associated POM file present.


@kumarshantanu, how about:

  • -p :auto would look for a POM file nearby or generate it:
    1. If the file is foo-1.2.3.jar it will try foo-1.2.3.pom in the same directory; or
    2. It will try simply pom.xml in the same directory as the installed file; or
    3. It will generate a dummy POM based on group/artifact IDs and version with no dependencies.
  • -p POM-FILE would explicitly use the specified POM file
  • when -p is absent, it would install without a POM, but users should know that this will result in malformed local repo structure that results in nasty warnings any time lein resolves dependencies using aether. Perhaps, in this case localrepo should print an admonition about this situation.

Perhaps the functionality of :auto should be split into :gen (simple POM generation as outlined above) and :auto (like above but minus what :gen does).

After users get accustomed to -p option, -p :gen may become the default option, since POM-less installs are the cause of incessant warnings. But then -p :none may be still allowed for esoteric situations.

What do you think?


@paxan +1 Good idea, and the keyword-style argument would avoid introducing an additional switch.


Was this ever completed?


@MHOOO None that I know if.


+1 - This would be great. I might look into implementing it, but don't hold me to it...


Sorry all. I was away from any sort of hacking on lein.

Let's sum up. Let's add -p switch with the following behaviors:

  • -p :gen will generate dependency-less POM file. The default option.
  • -p :none results in no POM file in the local repo. Perhaps, a warning should be issued that this is an unusual situation.
  • -p path/to/pom will use the specified POM file.

@paxan Sounds good to me


I came around to working on it after a long break. I think the point @paxan raised (an artifact being accompanied by a POM) is correct -- I am considering to auto-generate POM unless the user specifies one. This pull request can no more be applied due to the other changes that have gone in, but I am almost done with a fix that addresses the POM file issue. A push is forthcoming.


Closed via 27b43c9

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment