From: <[EMAIL PROTECTED]> > 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, http://www.ibiblio.org/maven/eclipse/jars/), 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 jars. > 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 http://www.ibiblio.com/maven repository is clearly already a success, even if it is manually managed/maintained [my assumption, not knowledge]. Creating Gump repositories (e.g. http://gump.dotnot.org/repository) 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 code. 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. regards, Adam
