PaxURL2Draft

General

Decouple URL Handler from Service implementation

The Java URL Handler mechanism can be a petty when using Pax URL in non OSGi environments.
To go around that, we need to think about separating handler logic from the actual URL Handler "Connection".

Currently the only way to communicate with Pax URL is using

new URL("<scheme>:other")

Now, this is extremely useful, but introduces some kind of hidden global singleton (the URL Handler registry) into any system using it.
I think we should provide an alternative, API driven way of using Pax URL. I propose a Pax URL Service interface mapping Strings (hence, the URL) to InputStream. This should be standard for all Pax URL Handlers.
It needs to be clear that this is not about re-implementing aether (using all its abstractions for dependency management). Its about a simple mapping that is easily usable to acquire artifacts at runtime.
Handlers can implement a user friendly api to encode URLs similar to what is done in Pax Exam.

// Generic way:
@Inject ArtifactSource<GenericTrait> source;
InputStream s = source.get("mvn:bar/foo")


// "Typesafe" maven example:
@Inject ArtifactSource<MavenTrait> source;
..
InputStream s = source.get().groupId("bar").artifact("foo");
or
InputStream s = source.get("bar/foo") // where mvn:bar/foo would also be valid.

Notice that we did not specify any version.
For sure one can also add version parameters to complete the GAV.
But what i think would be nice to have some concept to centralize version information.
I am still looking into that - but having property substitution like we have in Pax Exam:

InputStream s = source.get().groupId("bar").artifact("foo").version("$version");

Instead this could be an implicit default:

InputStream s = source.get().groupId("bar").artifact("foo").versionAsInProject();
// same as
InputStream s = source.get().groupId("bar").artifact("foo");

This would be a compile time dependency.
Additionally one can provide a runtime dependency solely providing URL Handler "Connection" implementations that add the magic URL resolver like we are used to in Pax URL 1.x.

Default way to re-route URLs

Sometimes its useful to re-reoute URLs that are not available (say, an artifact is not resolvable in classpath). One could think of an alternative routing mechanism to catch those misses. (say, go to mvn).
This would be a simpler alternative to a common pattern used with Pax URL Link:

• add link Urls
• provide (usually) 2 alternative runtime dependency projects, where the user actually needs to have exactly one in classpath

One solution would be to allow multiple URLS in Pax URL Link, where each line is tried once.
But one could really drop that extra Link File for each URL target. Instead one can think of a URL like so:

route:classpath:foo.jar:::mvn:foo/bar/1.0

Actually encoding multiple URLs in one request.

MVN Handler

Based on Eclipse Aether Project

The last available version of Sonatype Aether is 1.13.1 from september 2011.
Since then, Aether has been contributed to the Eclipse Foundation.

• Smaller Footprint
• State of the art version
• Guice

Link Handler