> Dion wrote: > > My question is do they fit our needs?
Sadly, I've not had chance to locate/read the archives, but I'll try to answer the question of what they do. > > "Krysalis-Ruper2 is a resource updater, meaning it automatically keeps > > local resources up-to-date with versions of the resource found in > > repositories. " > > > > I didn't think we needed something to keep a repository automatically > > up to date, and that mirroring would take care of that. Ruper is more client side, it is a "intelligent" repository client. Ruper reads a populated repository and makes determinations on what is 'best' (i.e. latest junit, latest junit "release", or nightly of ant, or any junit after 3.8) and such. The user gets to specify the constraints. Ruper queries remote repositories, it queries the user system, and [based upon user constraints] it determines if an update is needed for the user. If needed, it downloads/replaces. I see Ruper as in the middle between Gump (latest from CVS ever) and Maven/Ant <get (HTTP to a file). My view is that Gump is beautifully chaotic & not what normal developers/users ought daily try to work on. That said, statically linking to a release is regretably stangating. Ought N project Xs know that project Y has released a new jar and all update their links? What if it could be handled automatically, yet allow control (for if/when Gump didn't spot a gotcha) i.e. the users can impose constraints. I see this as an assist against JAR Hell. See: http://krysalis.org/ruper/index.html#Why+Ruper+was+created... BTW: Ruper2 can help to manage a server side repository, with the same queries. I'm hoping to add ruper (or whatever you guys come up with) to Gump. Gump (http://gump.dotnot.org)is already creating a repository of nightly Jar (http://gump.dotnot.org/repository) but it needs a cascading client to allow distributed repositories. I am considering using Ruper to clean up older version of files. > > and version ensures the jar and the runtime are available. Do we need > > that for a repository? Version is about versions -- including string format -- it is trying to bring some order to the world of version disorder. A primary goal is attacking JAR Hell, by (1) knowing what versions you have in an environment and (2) allowing developers/testers to specify what versions their project X can or can NOT deal with. Stating "I used junit but not 1.5.1". To do this it needs to be able to parse/understand and semi-normalize versions strings. Version is intended for the real-world cases where major/minor compatibility rules break down, and they do... The intended beauty of version is that it is automated. I deploy a *lot* of OSS software into containers, and I have operations staff that do it also. There is too much work to try to check "are all these jars consistent"? The goal is to allow software to check that against what the developers say, against what the QA folks say, combine that "documented knowledge" with what the operators say, and programmatically verify that the environment is consistent. See: http://krysalis.org/version/ and http://krysalis.org/version/jar-hell.html ------------------------------------------------------------------------ -------------- Are Ruper and Version appropriate for working with JARS and things in a repository? Yes, I believe so. Now, I'll try to locate the archive to get the whole thread. BTW: I respect/appreciate open discussion, and though I feel passionately about these two, I'm more than game to discuss the any role in this area you are working on. Tell me frankly any concerns you have, or questions, and I'll reply here. regards Adam