version and ruper2

["Adam R. B. Jack" <aj...@trysybase.com>]

> 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