separate .zip for some 'external' packages (was: Re: Next release criteria)

[Arnaud Vandyck]

Brian Jones <address@hidden> wrote:
> Outstanding tasks before releasing Classpath 0.06.
[...]
> * Update classpathx jaxp, potentially create a separate .zip for
> these classes as suggested on the classpathx list
[...]

Hi Brian, Hi all classpath developpers (and users),

Yes, I suggested classpath to split some packages so I can package
them for Debian, but I don't know if it's a good thing and I want to
explain my ideas.

My first intention was to package gnujaxp for Debian because on my G3,
I only have a 1.3 version of the jdk and I'd like to try
gnujaxp. After that, I noticed that there is no jdbc extension nor jta
in jdk1.3. So, I'd like to have these packages in Debian so I can use
free reference api.

These api are in classpath, but they are 'embeded' (except gnujaxp) in
classpath and not available as separate parts. It's the same problem
with 'swing'.

There are different propositions regarding this situation:

1° Leave this as it is now. Because maybe it's not a good idea to have
   to deal with jar files as (I mean 'alors que' in french, sorry!) we
   can have the whole classes in one single zip and do not carre about
   'CLASSPATH' (the environment variable :-) )!

2° Separate the classpath project with classpath (core), and
   classpath-x (extensions) (jta, jdbc extension, xml, servlet and
   jsp, swing, etc.). And each new release of classpath is a
   combinaison of the core and the extensions (as in the jdk/jre). In
   that case, if someone only want free-swing, he can just pick the
   'free-swing.jar' file and that's all. So extensions can have a
   different release cycle than THE classpath project.

I'm sorry to respond with this delay and with this poor english. I
hope everyone understand what I meant. I do not know if a split of the
project is desirable? possible? technically complicated? enoy people?
or else. Let me know.

Thank you for your time and attention,

-- Arnaud Vandyck @ ste-fi, ULg