Shared Library organisation and dependancies

Engines, Libraries and Tools Tools Discussion
#1

I’m toying with the idea of taking a bunch of common library-esque code I use (including a whole bunch of SPGL stuff), refactoring it a little and making it availble as a proper library (complete with tests, docs, etc. etc.).

The idea would not be a single big library, but a range of smaller modules which can be used independantly so people could pick and choose which bits they liked and which they could do their own thing. Currently the whole lot of code clocks in at about 0.6Mb, which I think is a little big if you only want one or two of the smaller chunks.

So I’m trying to figure out a way of dividing up the modules in a nice way. For bigger libraries I find sepearate projects in Eclipse work just fine - things stay separate, and dependancies are strictly enforeced. However the modules I’m thinking of would be too small for separate projects to make sense, and would make development a right pain to be switching back and forth between projects all the time.

Once alternative would be to have ant scripts which produce a collection of jars rather than one big one. However that wouldn’t enforce dependancies like different projects would. Does anyone know of a way of testing that an individual jar has all the classes and dependancies it needs? Or is there anothe way to organise this kind of structure without needing that?

Cheers

#2

you could just use something like ProGuard to create a new jar, from the big jar leaving only the bits needed in the new jar.
ProGuard can automatically check which files your project is using from a jar and remove the unneeded ones.

#3

GenJar may be another choice. If you make a test class that fully exercises the functionality of the library, GenJar will analyse the dependencies and only pull in the classes that it needs

#4

+1, see my post here :
http://www.java-gaming.org/forums/index.php?topic=14938.45

#5

What would be really nice is if you distributed the library as one big jar, but the user could only include the parts they used with their games.

Within the jar file, the code would be seperated into packages normally. It would only be during the final release that the used classes would be seperated out for inclusion.

Unfortunately, this seems like something that should really be part of an IDE because checking for dependencies is pretty complex. If you miss one file, your program won’t work. And there’s also the issue of files for things like SPIs that have to be included but aren’t actually referenced by your code.

It would be nice for this to all be automatic, but I don’t see how that could work.

#6

ProGuard does exactly what you’re asking for. You indicate the entry points for your application, and the tool does the rest.

#7

ProGuard is more of a whole program optimiser really - for use by the person actually creating the game, not the library creator.

I think I’ve come up with a good solution now - I’ll have an ant script which packages up individual modules into their own jars, ready for release. If I keep my test cases alongside the code they test then these smaller jars can have the unit tests run on each one in turn, which should fail if any of the dependancies are screwed. For the final releases another ant task can strip out all the unit test classes from all the jars.

For convinience I’ll probably still have an ‘uber’ jar with everything in it, and if the user finds it easier to just use that and run their whole game through ProGuard then that would work too.

#8

Hmm, yes and no.

The whole point of this set of code is that it’s all tried-and-tested stuff, code thats already been running in Cas’ or my games for quite a while now. This isn’t going to be a generic code dumping ground for classes that look vaugely useful - if the code hasn’t been used in a proper game yet it’s not going in. This way I think I can keep it practical and focused.

#9

Yeah, seems great. Now to see is the definition of a “proper game”… is that one you have played ? ;D 8)