[dsdp-mtj-dev] Support for flexible build process

["Max Gilead" <max.gilead@xxxxxxxxx>]

Hello!

I'm an author of a BitCruncher J2ME build system (http://sourceforge.net/projects/bitcruncher). When I was starting it I was aware of other efforts in this area but none of them appeared to be flexible or mature enough for porting needs so I decided to start a new project. That turned out to be a good decision since the tool became functional quickly and does exactly what needs to be done. In its current state BitCruncher is basically feature-complete for what I had planned for version 
1.0 but still there are a number of future goals to achieve :) Most (or all) of them seems to be compatible with MTJ goals so I'd like to discuss with you features we need before volunteering for a project.

Let me describe what BitCruncher is. It's is a build system for J2ME applications. It supports CLDC with MIDP and DoJa profiles. Project goal is to be a flexible, easy to customize and easy to work with.

Its directory structure is as below:
build/ - files from each build step are kept here easier debugging.
dist/ - final builds
profiles/ - device profiles. Each profile contains device descriptor (CLDC/MIDP/DoJa version, used resources, deployment data etc), preprocessor directives, additional Manifest/Jad/Jam entries, device-specific source code and resource files.
res/ - base resources. Res/ directory is split into user-defined groups (by default: base, gfx, lang and sound). Inside each group there are directories with actual files (eg. res/gfx/128x, res/gfx/176x etc).
src/ - base source code (with optional parts present in device- and resource part-specific directories)

A short list of features:
- J2ME projects have to deal with device incompatibilities. For this reason BitCruncher supports three basic ways of configuring source code: interfaces (each device profile and resource part may contain its own Java files; strongly preferred approach), Java preprocessor (J2MEPolish, compatible with Antenna/NetBeans), C preprocessor (GNU CPP); preprocessors can process a build-time copy or, at user request, an editable copy of source code
- can deploy built applications over SSH, IrDA and Bluetooth (standard and Nokia); FTP with WML/HTML generation is planned
- supported compilers: javac and ecj; configurable character encoding
- contains custom ZIP optimization tool
- each device profile can define its own external libraries (JSRs and vendor-specific)
- can run applications in MIDP and DoJa emulators
- experimental Eclipse plugin featuring Java preprocessor
- each device profile can be built in a number of language versions
- can build all device profiles in all language versions in one step
- multiple applications can be present in one midlet
- custom jar naming
- each device profile can have a separate version number
- runs on Linux and Windows (some features unavailable on Windows yet, like IrDA and Bluetooth deployment)
- can generate Manifest, JAD and JAM files with custom entries
- can generate DoJa scratchpad files with Java class describing its contents
- can build/run applications in normal and remote debugging mode
- each device profile can use an own obfuscator configuration
- fast-fail system -- execution is terminated immediately after encountering an error (that may sound obvious but is not ;) )

BitCruncher is very flexible system. It's been used while porting a number of commercial titles with wildly different styles of coding and resource organization so I'm fairly confident it can handle (as I'm writing in README) all reasonable and most unreasonably structured projects :)

I don't want to reinvent the wheel and would be happy to join MTJ project (of course if you all think I could be useful :) ) but I believe first thing is to check if we're going in the same direction. BitCruncher is a tool written to address real-life needs of a porting company. Features I described above are proven while working with titles from major game developers and publishers. As such it doesn't contain any (known ;) ) useless bells and whistles. Do you think that what I wrote above is what MTJ can and should support? Of course I'm ready to do the coding to make it happen -- question is about compatibility of our visions :)

Regards,
Max Gilead