Repository

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

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
(repository@apache.org) 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

Re: Repository

[Nick Chalko <ni...@chalko.com>]

Adam R. B. Jack wrote:

>
>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.
>

Excelent. 
I don't think I will have the cycles to directly contribute,  but I will 
ensure that centipede suppports both publishing to and retrieving from 
the Apache Repository.