Removing dependencies

Internal Dependencies

ClassLib has been split out of the trunk and seems to really help the build process. I'd like to see a few more splits like that. I think these 4 groups would be ideal...

1) ClassLib - contains all generic Java API
Some JNode specific parts may exist, but ideally as little as possible or with a clean and defined JNode <-> Java API to reduce porting issues.

2) Kernel - contains all boot, and VM; also contains JNode API
This is required to build/run JNode and would be akin to the Linux kernel; the difference between this section and the next section is security, drivers exist here to be compiled into the kernel such as input and video (not sound, network, etc).

3) Drivers/Support - contains all JNode specific code, drivers and apps
This is extra drivers and support to be loaded at run time (sound, network, etc) and JNode only commands like fdisk, mount as they have little or no use outside JNode. All this would be compiled with but not in the kernel image.

4) Distro - contains (pure java) all non-JNode code
This should follow "write once, run anywhere" ideals and extra JNode projects or 3rd party code, (Sun JDK, JNAsm, tomcat, derby, netbeans, etc)

Kernel and Drivers/Support are very close and the idea behind splitting them is to help maintain the API and security (kernel space/user space). I know those are far off goals but stating them now helps us plan to reach them. Chosing to combine them may be a better idea, I'm not sure myself.

Part of the redesign is to allow the directory structures to be copied over each other so a person can either work on one part, or put them all over each other and build. This also makes the project more IDE and 3rd party developer(JNode drivers or services) friendly. This would allow ant to use 5 build files, one in each ClassLib, Kernel, Drivers/Support and Distro and a 5th which just calls each target on each of these 4, I'd like to get to the point we can remove the .bat and .sh scripts and just use ant to build JNode.

External Dependencies

We will always require a JVM and GRUB to build JNode, but if we include Ant, Javac(precompiled with source), jiic-iso, JNasm, and all other java tools(most already are), we will have no other dependencies. We are very close to reaching this goal and it will allow us to compile JNode in JNode. Currently yasm is used for x86_64 builds, nasm is used for x86 builds, and a few linux/MS scripts, which should be replaceable with ant scripts.

Remember this is just an idea.

my comments

ClassLib :
    I think we are close to that goal (and we have already a separate project in trunk\classlib) and levente is working very hard on that.

Kernel :
    If your intent is to put the only things that we always need, then input and video should be in Drivers/Support because a computer might not have a keyboard, a mouse and a video card (for example a server)

Distro :
    Why did you put JDK (aka openjdk + icedtea + Classpath) here ?

    Shouldn't that be in ClassLib ? At least (even if it's pure Java, Non-Jnode specific), it shouldn't be in that same places as tomcat, derby, ... :
    That's a big part (that is already in it own project, in trunk\classlib) and the typical application integrator will never have to do anything in that big part : (s)he will only take third party applications/libraries and package them to be integrated in JNode distro.

About the build.bat & scripts, as I already said to you, I don't think we should remove them (at least not until we can build JNode inside JNode) but let don't focus on that : it's really a very small detail. The more important is studying and improving your proposal for splitting in 4 groups.


my blog : en fran├žais, in english or both

I guess I was vague

Kernel your right, the idea is drivers which are always required. GC, VM (native, mixed mode or interpreted), class to native compiler, etc. I wasn't thinking input/video device drivers such as Logitech G15 USB keyboard, but rather the driver interfaces such as USB HID.

Distro I called it JDK, you thought Java API classes (ClassLib), I meant another development environment such as J2ME, I renamed JDK to SunJDK.

I hope this clears up some details.