On 02/09/2007, at 2:44 PM, Jason van Zyl wrote:
On 1 Sep 07, at 7:04 PM 1 Sep 07, Brett Porter wrote:
On 02/09/2007, at 1:33 AM, Jason van Zyl wrote:
For this proposal I think it boils down to the ephemeral versus
non. I think there is an easier way to do what is proposed.
Are you talking about my proposal, or the settings zeroconf stuff?
I'm talking about your proposal being too complicated.
I believe this would actually simplify the current artifact handling
code since there are dodgy bits related to dealing with local
metadata. It has no effect on the user in terms of their Maven
usage. The only affect is "finding something" if they go digging
around in the local repository - which you pointed out at the end so
I'll come back to it.
An option to use a separate local repository goes a long way and
with a cached remote using Proximity this is not loathsome.
My local repository is currently 2.5Gb.
For every one you create, you duplicate a significant portion of that
data on the local disk, even if you avoid the network traffic by
using a proxy.
I don't think using a shared local repository is a particularly
bright idea.
This wasn't a proposal to facilitate sharing a local repository other
than on the same machine. It's not unheard of this even in a normal
dev machine setup. I've burned myself trying to build Maven and some
plugin at the same time.
But creating any layered structure should be reduced for the need
at hand. It seems to be people want to just separate between what
their projects produce and what is fixed. Trying to break things
down into the repository they came from isn't going to help anyone.
Is this the only part you are really objecting to, or the whole
proposal? I don't want to throw the baby out with the bathwater.
I started out with just the locking and the separation of a single
local repository, as came up on the list.
I then split the remote repositories out because I saw the
opportunity to simplify the code, make it more accurately reflect a
remote repository (they would now be identical and you could just
sync them straight down), and because it would correct some other
related bugs I saw.
I then split the local repository into workspaces as I anticipated
that was easier to deal with than swapping the entire local
repository path and having to have separate configuration for where
the cache is to share (to address a spiraling disk space usage if you
start switching local repos).
which parts do you like, and which don't you like?
Something like telling Maven to cache by a groupId is one approach.
Could be a project within an organization or an entire organization
and this is probably only in the context of a build server. The
complexity added for developers being able to shared a single local
repository is just not worth it.
Sorry, I could really parse this. What would maven cache by group id,
and where? Do you view this as complexity in the code (which I don't
think will be the case) or for the user?
To go from one place for the local cache to N where N is the number
of repositories would be overwhelmingly confusing.
This seems to be the only user complexity issue you are highlighting.
I don't think users digging in their local repository is a
particularly common case, but I would rule this out as an issue on
releases downloaded by maven (they are in the cache directory) and
stuff they install (it's in the workspace they used). I can see why
it might be an issue for finding snapshots from a remote repository.
But that change is totally negotiable in the proposal, I just felt
that under the current set up the ability to use a remote repository
as a local repository and simplify the handling was worth it.
I know its another directory, but the following might be more
straightforward:
.
|-- metadata
| |-- apache.snapshots
| |-- central
| |-- codehaus.snapshots
| `-- ...
|-- release-cache
|-- snapshot-cache
`-- workspace
|-- default
|-- workspace1
`-- ...
So you have one place that caches releases, one that caches snapshots
(that can be nuked more easily), workspaces for your local
installation, and optionally the metadata separated out to make it
possible to rsync full remote repositories (since Maven could honour
jars in here, but by default just store in the cache instead).
- Brett
--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
