Geir Magnusson Jr. wrote:
> Really? I thought that would mean that it was added to the PATH, and
> ANT_HOME was setup.
>
Doh ;-( Actually forgot that I did that...
> *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...
>
> Sure - the conventional approach many people take is to put everything
> under the sun (no pun intended) into the classpath, and run that way.
> Kinda the 'Hail Mary' of late binding...
>
> I don't like working this way - I prefer the determinism of specifically
> specifying a particular package (and that means you can work with
> different versions of things at the same time if you want...).
Agreed. CLASSPATH is bad.
>
> By adding the classloader functionality, or private classpath
> functionality for a JVM instance, then each app/project is indep and
> partitioned.
>
[SNIP]
>> Collaboration, man. Come on. Let's get it in and work together on this.
>> I am not against any of the ideas that you have put forth, although I
>> am pro-xml ;-) If I can't see what you've done, and I agree with what
>> you are doing, I have two choices: 1) wait for you to show the code, and
>> 2) write more of it myself. I hate duplication. Let's get the code
>> together!
>
>
> 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.
[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 ;-)
[SNIP]
>> The alternative philosophy is certainly welcome. I will eventually try
>> and convince to you go the xml way, and I don't see you rejecting Ant,
>> merely putting it in its place, as a layer on top of the core API.
>
>
> I am not worried about the XML, if it's small and we glop it into the
> jjan.jar. I would prefer XML as long as it kept the memory and
> performance footprint small. I don't know what small means, but I think
> this has usage beyond jakarta developers with big memory quick-boxen.
> Would be cool to boot an app via a wireless handheld..
In the end you could have an http server that served the data one string
at a time, that is *very* small, no parsing at all.
>> 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 ;-)
> I am going to do a few things more to it, and then I can drop it into
> the sandbox so people can play with it. It's pretty ugly right now :)
Existent code is NOT ugly code...
Scott
