I wrote a long reply on this when the topic started, but it got lost in a PC crash
So, a more concise reponse this time
From long personal experience with java libraries (writing, maintaining, distributing, upgrading, and managing different partial releases for different customers), my 2 cents is this:
1. Make everything as modular as possible, where "modular == separate JAR files". JAR files are good; people *really* like having the different components in different JAR's because *it's so damned easy to manage!*.
When someone wants to upgrade, downgrade, or recompile just one part of the library at once, the fact that they only need to produce the JAR they need is beautiful (especially if it needs no native code whereas others do - no worries about having LWJGL available at compile time, etc). Even better is that they can do rapid testing by swapping just one file in and out of a directory.
2. DO reference stuff like this in the core; in the long-run, it's a false economy not to. It's a good practice in C not to, but in Java...no. In Java, with runtime-only lazy-linking and dynamic classloading it's a good and sensible thing to have a core that references other packages.
Yes, it might cause some pain if your build tools aren't good enough to understand mutually dependent packages (one of my few gripes with vesta: it's written by C developers, who didn't expect that you can have two packages that have to be compiled simultaneously the first time, but thereafter only need the binaries of each other in order to be re-compiled).
There are, of course, neat standard OOP solutions to this: SPI's and abstraction layers. SPI's *can* be done, I think, by people other than Sun? but with hassle...as for abstraction layers, well - that's what you've just done! It is precisely what you would expect that the "core" references an "abstraction layer".
You're not going to reference it in every class just for the heck of it, but only in the classes where you need to.
3. Dump the whole xith-tk thing. I've co-written a Xith game and never even realised the xith-tk thing existed (I did see it mentioned, but it went in one ear and out the other).
Make the main xith.org etc refer to "Xith" as everyting you currenlty have, and always display the packages that are now in the toolkit side-by-side with the xith core packages, like this:
Xith core; this is the minimal amount needed to run Xith (plus you need the native libraries for your platform):
Xith native libraries:
* LWJGL: lwjgl.jar (needed by all platforms) , lwjgl-windows.jar (needed by windows) , lwjgl-linux.jar (needed by linux)
Xith additional modules:
* ...each of the xith-tk things (download-link, file-size, version)
* ...each of the xith-tk things ...
* ...each of the xith-tk things
* ...each of the xith-tk things
Xith external modules (untested, unsupported, might not work at all)
* ...each of the xith-tk things which you're uncomfortable/uncertain about. Probably worth keeping all new things in this area for a while until you're a bit more confident about them...
(nb: show ALL the xith modules on the same page, all listed - this is a VERY good way of giving the surfer a good idea of what they need to download, and is a VERY convenient place for them to visit periodically one single page to see what's available, what version it's at, etc)Why?
Because, although in your minds (as developers) the current layout makes sense, it does NOT make sense to uneducated potential users. What it looks like is to many viewers is that xith-tk is something random that's not supported and probably doesn't work and hey - it links to a completely different website with a horrible GUI that runs in a different window.
Plenty of people view the site and understand the relationship between xith-tk and xith. But plenty of others do not.