Comments on: Maven artifacts need to be more discoverable

By: E. Sammer

E. Sammer — Tue, 18 May 2010 00:40:35 +0000

The issue with relying on URL structure is that not all institutions / projects serve their own artifacts / control their domain / control their infrastructure / can sacrifice carving out a particular URL namespace like this. The indirection - whether people like it not - serves a necessary purpose. As for the uber repository that supports redirection, that's what things like Nexus do.

For the record, the single best (as in complete, accurate, well maintained metadata) Maven / Ivy repo to date is the SpringSource repo, hands down. Try it. http://www.springsource.com/repository/app/

By: spullara

spullara — Mon, 17 May 2010 20:26:28 +0000

I guess my question is why can't we also introduce an automatic discovery mechanism that doesn't require the use of software beyond web servers and proxies. As for the central mechanism, I think that a crawl + search model would work that doesn't actually store any artifacts.

By: Jason van Zyl

Jason van Zyl — Mon, 17 May 2010 18:19:01 +0000

As I've always argued this is not a technical problem. Your argument is predicated on a supply of healthy Maven repositories which is simply not the current reality. What you're proposing is not lost of us, however. It starts with having healthy Maven repositories around the world and Sonatype has made a serious effort to get Nexus Pro instances in all of the major OSS forges around the world, and we also host a open instance (http://oss.sonatype.org) that any project can use. The system can be more distributed for certain, but there are certain things that need to be done first. We have people working on this effort full-time.

Organizations that use Maven effectively manage their own switchboard by using a repository manager like Nexus. There's just a lot of inertia and I would argue some some centralized form of store, switchboard, or discovery mechanism will always be desired to aggregate everything that exists into one manageable form.

By: jstrachan

jstrachan — Mon, 17 May 2010 13:00:42 +0000

Am liking the use of URLs instead of dependency group/artifact/version tuples (particularly as often projects change their group/artifact ids or moves stuff to different repos which causes pain in poms).

Then you could just run (on your local machine or on your WAN/LAN for your team) a regular caching http proxy to speed up mvn builds.

It is nice having a global mirrored repo as a cache in case sampullara.com is down for example - but central repos could just rsync known repos and act as a backup http proxy cache.

It'd be nice to be able to do imports using URIs too in code...

import http://cli-parser.sampullara.com/4.5

and the JVM could auto-download stuff on the fly...

By: Nagesh Susarla

Nagesh Susarla — Mon, 17 May 2010 08:31:25 +0000

I love this idea! It certainly solves the resolution problem implicitly when you point to a URL.

By: John Beatty

John Beatty — Mon, 17 May 2010 06:52:34 +0000

I think it would be far easier if dependencies were simply specified as URLs and there was standard resource names under a root path.

For example, http://junit.org/releases/4.8.2 would the base URL that you specify as a dependency, and the follow resources would exist:
http://junit.org/releases/4.8.2/junit-4.8.2.jar
http://junit.org/releases/4.8.2/junit-4.8.2-src...

By: Ryan Kennedy

Ryan Kennedy — Mon, 17 May 2010 06:49:56 +0000

It's a similar argument to dealing with Java packages. The "standard" was always reverse your domain (i.e. com.foo.bar.Baz), but there was no guarantee that going to bar.foo.com would help you find the JAR containing Baz.class. Ultimately, you don't search for artifacts by group name and artifact name. Often what you want is to find the artifact that contains a particular class, because you found some code that uses com.foo.bar.Baz but you have no idea what artifact that's even a part of. It would be excellent if an ad hoc system for locating classes existed. Let some compiler tooling trawl through my code, notice I have a dependency on com.foo.bar.Baz, make requests to http://bar.foo.com/artifacts/Baz.class and http://foo.com/artifacts/bar/Baz.class until it finds an artifact that contains that particular class. Maybe even have that resource issue a redirect to a JAR resource like http://foo.com/artifacts/bar.jar. Then the compiler can resolve all of the class dependencies to JAR redirects and download the uniques.

I don't know, maybe a tad too automated. But at the end of the day, I spend a lot of time searching in our artifact repository for classes, finding out what artifact it's in, adding the artifact to my ivy.xml file (we use Ivy, but it's a similar experience with Maven) and then letting the build system download the artifact. Why not just let me declare my dependency on particular classes and have the tools resolve those to JARs and download them?