> So, a quick question. A 'repository effort' is not just about code, it's
> mainly about keeping the repository up to date and accessible, and this
> (from what I can tell) isn't covered by Ruper or Version, is it?

Agreed, however with sufficient automation tools around a simple concept,
surely the 'effort' barrier is reduced.

Yes, there is critical need for management/maintenance/monitoring, and that
requires some tools and some human determination/investment. If the
resources aren't the issue (and that isn't for me to say, although I feel
this'd save overall resources) and if the repository is open (open to any
publishing tools [securely], open to any clients, open to any management
tools) then isn't the load distributed over the community (and no doubt a
small group of infrastructure types?).

> Other Repository Questions:
> 1) Should there be metadata or is none required to host, access and manage
> the repository?

Ruper 'copes' with limited metadata, in the main because it relies upon a
pretty standard (if informal, at least to 'repository') set of naming
conventions. I feel that aspects of a single repository, and aspects of a
group (e.g. the eclipse group within a repository,, could seriously benefit from
metadata for the more obscure cases.

I can see arguments for avoiding metadata in terms of an 'index of contents'
because of the repository simplicity. I lean towards those arguments. It
seems compelling to be say 'create a filesystem hierarchy, point your WWW
server at it, publish files to it however you want/can, and you have a
repository'. I assume this is good for mirroring, and such. I see repository
as being (per resource) "write once, read many", so I tend to favour
simplicity of the later.

> 2) Repository format?

Are we discussing file system hierarchy? I have no idea where the
{URL}/{group}/jars/*.jar format came from, but I can live with it (despite
some reservations). Ruper copes with hierarchical and/or flat, and allows
implementation extension. This is where I'd suggest we start with a
standard, and then allow metadata to be used to describe deviations from
that standard.

What I really like about this standard is that it is focused on jars --- and
that (to me) is the key objective here. Sure repositories could hold
documentation, installations, so forth -- but I think the big first win is

> 3) Are there lessons to learn from Perl's Package Manager or other similar
> tools? If so, what?

First, I love this tool, it is invaluable in the Perl world, same for
Python's equivalent. Second, I worry that it is much more than we should
start with. Since installation and registration mechanisms are integral to
PPM, I really fear scope creep. I think that solving the problems of
automatically downloading JAR files is a valid first step, and tools like
PPM should be attempted only once the solid foundation is given. I believe
that downloads are achievable, but that installation/registration is a
separate beast altogether.

That said, I don't know the internals of how PPM is
implemented/managed/maintain, I agree it is worth digging into.

> 4) Is this an ASF only repository?

I'd like to see distributed mechanism, with any content. That said, I'd like
to see this group start with a single (if mirrored) Apache-only repository.

> 5) Repository content - is it up to each project to determine it, or is
> there some standard / structure

I think the layout of the repository ought have some order, because I
believe that automation is key to making this fly. Again, metadata for
deviations, for those tools that care to cope with such.


It seems to me (and forgive me if I have second hand/incomplete information)
that "phase 1" of  'repository effort' was the simple agreement on
.../{group}/jars/*.jar and "phase 2" was (is) compliant repositories. The repository is clearly already a success, even
if it is manually managed/maintained [my assumption, not knowledge].
Creating Gump repositories (e.g. was just
a few lines of Python based upon the layout agreement, and I like an open
standard that any/many implementations can leverage w/o having to share

I'd like to see the 'repository effort' start with a simple documentation of
what is already available, so folks can build/rely upon this
knowledge/agreement. I like to see this group work towards, and present, a
simple phased roadmap with descriptions of roles/interfaces, and with code
only as necessary. Keeping this simple ought help keep it open, and allow it
to succeed.



Reply via email to