I wanted to respond to the rest of this - heavy family interrupt
processing today...
Scott Sanders wrote:
>
> Geir Magnusson Jr. wrote:
>
> > *If* you need to download a jar - I think that an important use-case is
> > the working developer, and having a local repository means that all jars
> > are available in a way that lets that developer use them in whatever way
> > they choose, w/o worrying about dorking with the classpath.
>
> Agreed. I meant that if you didn't have a net connection, AND you
> didn't have the jar, you were in trouble...
Oh sure. dead in the water...
> >
> > I am very pro XML myself. I think think that since the API takes care
> > of all details though, putting everything behind a Repository class, it
> > could be implemented via gerbils...
>
> An API on top of a DTD is the proper way to go. Then the Ant task and
> the command line tool and any other app share the same 'view' of the data.
The only thing I have to add is that to the client, the fact that it's
based on a DTD is really irrelevant. If this grew, and the repository
was an online system, say a dedicated CJAN/JJAR/FOOBAR server that
returned package information, that might come from a RDBMS...
> [SNIP]
> >> Agreed. Let time tell if these things are needed. My only concern was
> >> the maintenance of the index based upon the amount of information and
> >> the rate of change of that information. The repo index is the most
> >> crucial part of this, as it has to stay fresh to keep all of the users
> >> happy. If that index is large, the maintenance will go down ;-(
> >
> >
> > The master index can be kept in XML, and then transformed into a
> > properties when pushed onto the repository server for digestion by the
> > client API if we stay this way, and if we use jjar. You could even get
> > XSLT involved, to be even more buzzword compliant.
> >
>
> I was referring to the amount of data, not the duplication ;-)
>
> If we need that buzzword compliant feel, I could handle the XSLT piece
> of it ;-)
Hopefully we can get ".NET" in there somewhere as well :)
> >> Again, I started with Ant to get the ball rolling. I see a need for a
> >> CJAN type system *now*, not next year, so I went with what I knew, Ant
> >> and XML.
> >
> >
> > My approach isn't a criticism. Just something different - I was
> > thinking about this subject for a while, before commons, and some of the
> > things we debated when starting commons fed it. I have no belief that
> > jjar is the final solution either, but I see in myself and my clients
> > lots of wasted time screwing with the classpath, downloading and
> > building jars, etc. My dream, described fuzzily, is a lightweight tool
> > that can do things like boostrap a project install, incorporate into a
> > developers build process to manage versioned packages and their
> > inclusion, a runtime classloader that also suppots the same thing, etc -
> > and a pile of trusted jars accessable to all as a resource... It's a
> > common dream I suppose.
> >
> >
> >> If the xml size is a concern, we could get you to write a JavaCC parser
> >> for a specific DTD, no? That parser would be very small ;-)
> >
> >
> > Actually, that's not a bad idea :) But I am fundamentally lazy, and if
> > the XML parser is small enought, problem solved...
>
> It just depends on how small the requirement really is ;-)
maybe. but as long as it doesn't contrain the functionality you wish to
express, the smaller the better :)
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
"still climbing up to the shoulders..."
