I've read the archives (thanks infrastructure for that). If folks have the patience, I'd like to add a few more thoughts. I'll try to make this as brief as I can.
I came to developing OSS because running a growing demo centre of lots of machines running on top of lots of Apache/OSS software I use a lot of OSS, and manage a lot of installations. JAR Hell (version incompatibilities) was killing us, with lots of products in single containers & using each other, and manually dependency checking was just plain wasting my team's life. Our OSS benefit was being reduce by this. I wanted (want) to help solve this problem so I can stand firmly on the shoulders of a tall pyramid of folks developing. This remains my primary passion. Version is trying to (1) programmatically introspect environments and (2) allow 'documented' constraints be programmatically resolved. Developers often know what versions of dependencies they rely upon [and/or can't use], as do QA folks, as do operators. I wanted a way to express this, but also combine it & test the combination. Since operators have N products to bring together, they might not be able to satisfy each project's exact preferences. Maybe there are a range of choices. Combining the choices (via constraints) to see if an environment is within every projects comfort zone, and report if not, is what I'd like to see. IT is what Version tries to provide. Ruper became a passion partly 'cos I work over a modem. Because of JAR Hell, and because of network pain, I hate jars in CVS. I like what folks can do with Maven and/or Ant <get to Maven's repository -- to download a release, but I worry that expressly stating a given release, although robust, is stagnating [I typed it right this time ;-) ]. I fear that stagnant building/testing leads to more JAR hell (partly why I work on Gump). I know (from mailing lists w/ Ruper users) of folks who like the flexibility of Ruper, as I do. Developers get the latest to work on if they wish, but production gets what QA tested/allows. It isn't that simple in the real world, and Ruper2 came about in order to allow the flexibility of Version's constraints into what to download. I don't know Maven to use it, but I've read some about it. I like that it is creating metadata for much of a project's development process. I see that it adds significant value to the project through that metadata. Version and Ruper are hoping to add a benefit with 'dependency constraint' metadata, and a new benefit at that. I've long thought about proposing version and ruper to the Maven team, to see if these two products could add some value to Maven users, and one day hope to. That said, I'm hoping that the two can co-exist happily. Right now version and ruper can handle almost all of the jars that Maven has published (that is 1558 jars, all but roughly 35) and I hope to cope with all eventually. >From what I understand the repository layout that is used today is a "standard" (or at least a locally agreed upon defacto one). I don't know if a repository ought be a file/web system hierarchy alone, or one with metadata (like, I believe, JJar wanted), or even one more like viewcvs -- or CVS (it's own protocol). I have come to respect the "directory only flavour" since it is very simple for the publisher, there are no issues of a shared metadata file to update. I believe that the more that is published, the better. [As such, I have Gump starting to publish it's results, in case folks were nuts enough to want to work off them -- and/or for other Gumps to cascade off. Think of the cycles saved with cascading Gumps/builds, awesome...] As such, although this topic is "repository" I suspect that the topics could be split into: 1) Repository hierarchy/metadata [Maven/other publishers care about this] 2) Repository client tools/browsers [Version/Ruper care here, as is Maven download & ant get] 3) Repository contents (naming conventions e.g. for Jars or source or docs or other.) [I guess all of 2 care about this. I think this is a necessary evil, even if it is flexible.] 4) Repository Maintenance tools (cleaning old files, archiving, etc.) 5) Repository Security (I like Maven's MD5 for one, we need to ensure an "rm -r" doesn't get inserted into a repos JAR contents) 6) Private Repositories/Distributed Repositories/Cascading Repositories (Ruper search any number, but it is brute force) 7) Repository Protocols (Ruper uses VFS, but falls back to Http/File if not available) I could go on, and won't here unless asked. I believe that together we have a start on components for these things, but that the most important is a consensus to work together to solve these issue together, and continue to build upon the results. If this is the place to do it ([EMAIL PROTECTED]) then excellent. I don't know if this is just a random thought discussion, or the start of a new project, but I have a big itch in this area and would wish to contribute requirement/code/coding/experience (good and bad from Ruper) as folks see fit. I'm open minded on how the problems get solved, and I don't mind whose code folks start with, I just want to see the problems solved. regards, Adam -- Experience Sybase Technology... http://www.try.sybase.com