Geir Magnusson Jr wrote:
I agree. How about "classlibadapter/trunk" -> "adapter/gnu/trunk"?
I'd keep it specific to classlib yet simple and mimic the classlib
structure with
classlibadapter/trunk/module/gnu
or something.
OK... although I'm not sure what purpose the "module" part serves.
We can of course always insert it later.
Now next questions... let's talk about how we want to build and
package this. It looks like basically we need to build two things,
(a) a ZIP/JAR file containing the adapter classes, and (b) a native
libarary for java.io.File.
#1. It's possible to get rid of (b) because Classpath already contains
native libraries that implement java.io.File functionality.
Classpath? The assumption here is that you don't need to have GNU
Classpath, right?
Argh, my apologies, for some reason I was thinking completely backwards.
Ignore most of what I said :-)
We don't need Classpath to build and it won't be available at runtime
of course. We could do that, but then that kindof defeats the whole
purpose... I think I was imagining this on my laptop which has Classpath
but that would be a special case...
We will be providing VMFoo classes that define the same API to the
VM that Classpath does. Essentially we'll have replacements for all of
Classpath's vm/reference classes, plus the glue that goes on top of
that to hook it all up to classlib.
Hope that makes more sense...
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
