Add support for local JARs

[ckrailo]

@michaelklishin mentioned that supporting local JARs can be a lifesaver:

• Some project maintainers don't release artifacts on any schedule.
• Some project maintainers just publish JARs on their own site.
• Some project maintainers don't publish anything so you have a project from source.

@sam: Seems like we could add a config.local_jar command that takes a relative or absolute path to a JAR and it would handle this use case.

Thoughts?

[sam]

I don't care for config.local_jar personally. I think the cleanest user API would probably be to let config.jar accept a coordinate or a URI. That way you could:

config.jar "relative/path/to/my.jar"
config.jar "file://absolute/path/to/my.jar"
config.jar "http://example.com/unpublished.jar"
config.jar "http://example.com/path/to/project/source/where/pom/resides/"

etc. Basically, if it matches /^[a-z0-9\.\-]+(\:[a-z0-9\.\-]{2,})+$/ it's a coordinate, otherwise it's a URI. Pretty sure that covers the bases (no special characters allowed in a coordinate, must contain at-least two colons and three parts).

Keep in mind we're not trying to validate a potential coordinate, just determine which of the two it might be.

[sam]

Here's a shorter version of the coordinate-matching regexp:

/((^|\:)\w+[\w\.\-]*){3,}$/

Must be at-least three parts, separated by colons, a part must begin with a letter or number.

[ckrailo]

It makes the API cleaner, sure. But code would be more complex this way. Plus, we'd have to handle other aspects of it not being a standard coordinate dependency. A config.local_jar command could just ensure that the jar gets on the classpath and included in any distributions (gem/jar).

On the flip side, your API idea could enable JAR hosting without using Sonatype Nexus or another type of Maven repo. I think each JAR would require a pom.xml so we can make sure all dependencies are taken care of, right? Is that a reasonable expectation for local JARs or unpublished projects?

[michaelklishin]

@ckrailo usually if you have a project not publishing artifacts, it also makes it a pain to obtain pom.xml, unless you have the entire source repository. Fortunately, some such jars also don't have any dependencies (some virtualization technology clients is a good example).

To me it sounds like the resolution issue outweights the benefits of overloading config.jar. If you keep them separate, you can change your mind about how local JARs should be handled exactly without any major changes to the rest of the code. Local JARs are definitely a pathological case but at least some basic support for them is a good idea.

[sam]

It's actually fairly well factored (IMO). I think it would just be adding an if statement to JarDependencyList#fetch and using a LocalJarDependency < JarDependency if the regexp is matched.

Since JarDependency#path would already be filled out, all you'd really have to do at that point is make sure that the Aether resolution only gets passed JarDependency instances (since a LocalJarDependency wouldn't need to be resolved and would already have a populated path).

If we're talking about purely that I've downloaded something.jar locally and want to add it as a dependency, then using config.jar "../something.jar" is probably a one-hour task.