Hi,
I've read the whole thread (so far), and I'm just going to give a
summary response here, rather than replying to each relevant email...
I think this proposal is a fantastic starting point. We've been
wrestling with issues of non-reproducibility and mistakenly broken
builds for a long time now, not to mention all the trouble we've had
with interrupted artifact/metadata files etc. and I think this is
getting us back on track to address one of the cruftiest parts of
Maven - the local repository. It requires a high degree of knowledge
about the inner workings of Maven to know which files to check in the
local repository in the event something weird happens. Most often, it
doesn't even look like a problem with the local repository itself,
but rather of the remote repository or the network (did you configure
a proxy? did you do it correctly?). However, this proposal also goes
a long way toward enabling beneficial practices in plugin development
and the like, with the introduction of workspaces in the local repo.
Here are some comments I had as I read through this thread:
1. We should put a piece of repository metadata at the root that
gives the repository id, to help eliminate/reduce the proliferation
of new and creative repository ids. Then, use of the repository in
the POM/Settings can be limited to its base URL, and Maven can
retrieve the repository's id from there. This also opens up the use
of such a metadata file for defining the layout, etc. of the
repository, and possibly the default update intervals, presence of
snapshots, etc. to drastically reduce the size of the repository
declaration in the pom.xml. (Similar to Stephen Connolly's suggestions)
1.A. Would true mirrors (not aggregators or proxies) of a
repository share the same repository id/GUID?
1.B. What about storing a list of known mirror URLs in this
metadata file as well? This could aid mirror detection/selection for
clients.
Understandably, much of this gets us off-topic pretty quickly, but
it's worth noting that this sort of advanced organization becomes a
lot more approachable when we can track the effects of a remote
repository right down to our own hard disks.
2. Workspaces should be something you have to set consciously, not
automatically created. This allows an integration-testing run (for
example) to run in isolation by using a different workspace id, and
clean up after itself when finished.
This proposal improves the maintainability of the local repository
immensely, by allowing pruning of all information from a given
repository and separation of snapshot/transient information from rock-
solid immutable information. It also gives a built-in way of
isolating one build/set of builds from the rest of the environment,
eliminating the need for the contortions currently performed by
things like the assembly plugin to ensure it's not polluting the
local repository while performing integration tests. Best of all,
when the integration-testing run is finished, you can just blow away
the integration-testing workspace location in the local repository.
IMO, that's a brilliant feature to have baked into Maven.
3. As noted before, this proposal really seems to be less about
sharing a local repository and more about organizing the local
repository for more efficient usage. However, in cases where the
immutable cache/ dir can be shared between processes on the localhost
(maybe two builds by two users, maybe CI, who knows?) there should be
an ability to configure the location of this cache/ dir in the local
repository root or something, to allow multiple local repositories to
point at one cache/ dir. This is more about reducing latency from the
network and hard disk usage (which not insignificant when it grow to
multiple gigs) than it is about creating an isolated de facto remote
repository on some localhost. I also think each artifact in the cache
dir should be tagged with its originating repository, fwiw, so we
have a little more of an audit trail to work with (in case one
repository is corrupted or compromised).
4. I would tend to move more toward total separation by repository,
rather than away from it, for the purposes of tracking, pruning, etc.
but it's still a good idea to have snapshots broken out from
immutable artifacts.
Thanks,
-john
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
