At 03:26 6/5/01 -0400, Geir Magnusson Jr. wrote:
>I have a working example of something I call JJAR - 'Jakarta Java
>Archive Repository' ('CJAN' as a name was taken a little while into my
>journey... ;) and CJAN requires some heavy lifting to propertly emulate
>CPAN...).
;)
>Some of the things I thought important are :
>
> * minimal dependencies - shouldn't rely on any
> other jars to get things because one of the
> design goals is to be able to be used to help
> new users get started, to help avoid much of
> the easter-egg hunting for jars that we currently
> require
+1
> * 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.
> * 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.
> * ANT support : once the basic API is in place, Ant
> tasks are simply wrappers on top of the core
> functionality
+1
> * 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).
> * 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 ???
> * command line tool can verify package and version information
yea !!!
>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).
>The version and package information is kept in the manifest, in what is
>probably the wrong way :
>
>Implementation-Title: <packagename>
>Implementation-Version: <version>
+1
>Dependencies : The dependencies are 'hardwired' into the repository
>index information - we can easily generate this from information in the
>jars themselves when added - I think it's important that we don't
>have to haul the jar bits over the wire just to check dependencies -
>just stick to the lightweight repository index and make sure it's
>right. This way we also can have human control - I am including
>non-Jakarta packages like JUnit and JDOM, and there is no reason to
>expect that they would conform to either our versioning markings or
>correct dependency listing.
>
>Examples : I have two examples
>
>The first is the [required] ant task test - it is able to go and get
>from the repository a package and it's dependencies. There are lots of
>things to work out there wrt ant, which I expect will come from use.
>
>The second is a small shell script that uses the command line tool to
>fetch ant and dependencies into a local repository, and uses it to start
>the build script. The idea is that you can make a small installer to
>get ant's jars, and then invoke ant to do something more complicated
>like get things from CVS, compile, all the wonderful thing ant does...
sounds good.
>Anyhow, it's late and I'm beat. If there is positive interest to see
>this in detail, I can put it into sandbox, but would want to do a bit of
>refactoring and cleanup...
>
>I hope to do some real ant use-testing in a project jason is working on
>- a riff on the Gump idea - I think it will be important to see what to
>see what ant integration really requires, and garner some use-practice
>with it.
kewl. Hopefully the best of breed ideas from cjan + jjan + jnlp will be
integrated together ;) Look forward to seeing it ...
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
