Peter Donald wrote:
>
> At 03:26 6/5/01 -0400, Geir Magnusson Jr. wrote:
>
> > * small size : given the heart-rending stories of
> > Craig and his analog modem travails...
>
> I am indifferent to this as initial bootstrap loader only has to be
> downloaded once.
Consider it then a carryover from my C++ and embedded days. :)
However, some multi-megabyte monstrosity won't cut the mustard here - if
for whatever reason you want to make a small installer / loader (think
embedded Java here...)
And there always is Craig there huddled over his acuoustic coupler...
> > * embeddable in applications : as just another API,
> > it allows a developer to embed the API in apps. For
> > example, one thing I want to do (not done yet )
> > is to provide a smart classloader that can
> > fetch what is needed, and therefore let a programmer
> > do things like specify dependencies in code, which
> > will be resolved at runtime, all in memory if you
> > wish.
>
> +100000
>
> One of my big wishes - I currently implement a cut down crappy version in
> Avalon/Phoenix to download applications but I was waiting till Ant2 till I
> fix it ...
>
> I would actually separate it into three modules - a checker, a fetcher and
> a loader/launcher. The checker checks current filesystem. Fetcher fetches
> it from wherever. Loader will inject it into current apps classloader. When
> I first played with java2 I had a "launcher" style app. You could run it
> either like
>
> jlaunch -jar app.jar
> or
> jlaunch -classpath app.jar com.biz.MyApp
>
> It first loaded up a raw JVM and then built a URLClassloader and injected
> the seed jars (ie app.jar). It then did a search for META-INF/ld.conf
> resource. If found it would try to inject the specified resources into
> classpath.
That split is the idea in the API - there are parts which can separately
analyze the classpath, check the pkg/version of a jar, locally or
elsewhere, etc. I do want to inject into the classloader, but didn't
get there yet.
> > * ANT support : once the basic API is in place, Ant
> > tasks are simply wrappers on top of the core
> > functionality
>
> +1
Of course. We love ant.
> > * this repository index is a properties file - processing
> > this information can't require XML - one design goal is
> > no external dependencies, and XML support is a heavy one
>
> If you go a minimalist route (ie crimson.jar) you are only looking at
> another 300 kb - which is only a few seconds to download - so I don't think
> that should be an issue. (Though there is smaller xml parsers about that
> weigh in at 15-30 kb uncompressed).
I was thinking about this going to bed last night, and as long as it
could be crunched down, we could do it that way. All repository
interaction is contained in one class, so it would be easy to switch to
whatever.
> > * command line tool can fetch packages by request, and supports
> >dependency trees,
> > fetching all dependencies connected to the requested package
>
> can you check dependency tree before you start downloading ???
Yes. That's why I want the repository.index (my name for the 'catalog')
to have the dependency info - its a quick slurp of the index from the
repository server, and then you can check. So no jar bits have to ever
move.
> > * command line tool can verify package and version information
>
> yea !!!
of course. Since the 'local repository', whether global to a developers
machine or local to a specific project (say, Tomcat), it's nice to be
able to query all or one to see whats there. I am going to add an
update command to automatically synch your local to the remote, either
in entierity or just a subset. There could be a jjar.index file which
lists what you want by package or something in the local repository. I
am trying to limit the decisions and dependencies on local
infrastructure until we get some real use experience.
> >Versioning : Currently, the version scheme is this :
> >
> ><major>.<minor>-<modifier>
>
> I would still go with
> <name>-<flavour>.<major>.<minor>.<pathlevel>
>
> as was discussed a few days back re commons component versioning. "flavour"
> basically allows you to do things like have "nodebug" or "opt" versions (or
> jdk1_2 vs jdk1_1 for collections packages).
that's cool, I suppose. Currently it's a duple : <package> +
<major>.<minor>-<modifier> so doing it your way would make it clearer
that things are associated.
What is <pathlevel>?
One of the current repository info warts is handling something like
jaxp, where there are three parts, jaxp.jar, crimson.jar, and
parser.jar. So right now, it's listed as three packages, with
dependency information :
packages = jaxp, jaxp-parser, jaxp-crimson
...
jaxp.dependencies = jaxp-parser, jaxp-crimson
...
and the dependency generator figures it out. I was going to take a
swipe at adding the multi-jar package support today, cuz I don't like
this.
>
> >The version and package information is kept in the manifest, in what is
> >probably the wrong way :
> >
> >Implementation-Title: <packagename>
> >Implementation-Version: <version>
>
> +1
Really? I wasn't sure if it was cool. The documentation in this area
seems a bit spare.
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..."
